Entries Tagged 'Test strategy' ↓

This article is a part of software testing questions and answers series. You can see all previous articles under this Q&A series on this page – Software Testing Questions & Answers. If you want to ask a question, just write a comment below.

Mallik asks:

What type of database (SQL) questions asked in interviews for test engineer position (not for database tester)?

This depends on many factors whether these questions are for testing positions at entry level or for experienced testing professionals. The depth of database interview questions depend on the experience of the candidate.
Continue reading →

This is a guest article by Author “N. Sandhya Rani”.

For success of any project test estimation and proper execution is equally important as the development cycle. Sticking to the estimation is very important to build good reputation with the client.

Experience play major role in estimating “software testing efforts”. Working on varied projects helps to prepare an accurate estimation for the testing cycle. Obviously one cannot just blindly put some number of days for any testing task. Test estimation should be realistic and accurate.

Continue reading →

Are you developing any Test plan or test strategy for your project? Have you addressed all risks properly in your test plan or test strategy?

As testing is the last part of the project, it’s always under pressure and time constraint. To save time and money you should be able to prioritize your testing work. How will prioritize testing work? For this you should be able to judge more important and less important testing work. How will you decide which work is more or less important? Here comes need of risk-based testing.

What is Risk?
“Risk are future uncertain events with a probability of occurrence and a potential for loss”

Risk identification and management are the main concerns in every software project. Effective analysis of software risks will help to effective planning and assignments of work.

In this article I will cover what are the “types of risks”. In next articles I will try to focus on risk identification, risk management and mitigation.

Risks are identified, classified and managed before actual execution of program. These risks are classified in different categories.

Categories of risks:

Schedule Risk:
Project schedule get slip when project tasks and schedule release risks are not addressed properly.
Schedule risks mainly affect on project and finally on company economy and may lead to project failure.
Schedules often slip due to following reasons:

• Wrong time estimation
•  Resources are not tracked properly. All resources like staff, systems, skills of individuals etc.
•  Failure to identify complex functionalities and time required to develop those functionalities.
•  Unexpected project scope expansions.

Budget Risk:

•  Wrong budget estimation.
•  Cost overruns
•  Project scope expansion

Operational Risks:
Risks of loss due to improper process implementation, failed system or some external events risks.
Causes of Operational risks:

•  Failure to address priority conflicts
•  Failure to resolve the responsibilities
•  Insufficient resources
•  No proper subject training
•  No resource planning
•  No communication in team.

Technical risks:
Technical risks generally leads to failure of functionality and performance.
Causes of technical risks are:

•  Continuous changing requirements
•  No advanced technology available or the existing technology is in initial stages.
•  Product is complex to implement.
•  Difficult project modules integration.

Programmatic Risks:
These are the external risks beyond the operational limits. These are all uncertain risks are outside the control of the program.
These external events can be:

•   Running out of fund.
•   Market development
•   Changing customer product strategy and priority
•   Government rule changes.

These are all common categories in which software project risks can be classified. I will cover in detail “How to identify and manage risks” in next article.

Are you going to start on a new project for testing? Don’t forget to check this Testing Checklist in each and every step of your Project life cycle. List is mostly equivalent to Test plan, it will cover all quality assurance and testing standards.

Testing Checklist:
1 Create System and Acceptance Tests [ ]
2 Start Acceptance test Creation [ ]
3 Identify test team [ ]
Continue reading →

Today I got  interesting question from reader, How testing is carried out in company i.e in practical environment? Those who get just out of college and start for searching the jobs have this curiosity,  How would be the actual working environment in the companies?

Here I focus on software Testing actual working process in the companies. As of now I got good experience of software testing career and day to day testing activities.  So I will try to share more practically rather than theoretically.

Whenever we get any new project there is initial project familiarity meeting. In this meeting we basically discuss on who is client? what is project duration and when is delivery? Who is involved in project i.e manager, Tech leads, QA leads, developers, testers etc etc..?

From the SRS (software requirement specification) project plan is developed. The responsibility of testers is to create software test plan from this SRS and project plan. Developers start coding from the design. The project work is devided into different modules and these project modules are distributed among the developers. In meantime testers responsibility is to create test scenario and write test cases according to assigned modules. We try to cover almost all the functional test cases from SRS.  The data can be maintained manually in some excel test case templates or bug tracking tools.

When developers finish individual modules, those modules are assigned to testers.  Smoke testing is performed on these modules and if they fail this test, modules are reassigned to respective developers for fix. For passed modules manual testing is carried out from the written test cases. If any bug is found that get assigned to module developer and  get logged in bug tracking tool. On bug fix tester do bug verification and regression testing of all related modules. If bug passes the verification it is marked as verified and marked as closed. Otherwise above mentioned bug cycle gets repeated.(I will cover bug life cycle in other post)

Different tests are performed on individual modules and integration testing on module integration. These tests includes Compatibility testing i.e testing application on different hardware, OS versions,  software platform, different browsers etc. Load and stress testing is also carried out according to SRS. Finally system testing is performed by creating virtual client environment. On passing all the test cases test report is prepared and decision is taken to release the product!

So this was a brief outline of process of project life cycle.

Here is detail of each step what testing exactly carried out in each software quality and testing life cycle specified by IEEE and ISO standards:

Review of the software requirement specifications

Objectives is set for the Major releases

Target Date planned for the Releases

Detailed Project Plan is build. This includes the decision on Design Specifications

Develop Test Plan based on Design Specifications

Test Plan : This includes Objectives, Methodology adopted while testing, Features to
be tested and not to be tested, risk criteria, testing schedule, multi-
platform support and the resource allocation for testing.

Test Specifications
This document includes technical details ( Software requirements )
required prior to the testing.

Writing of Test Cases
Smoke(BVT) test cases
Sanity Test cases
Regression Test Cases
Negative Test Cases
Extended Test Cases

Development – Modules developed one by one

Installers Binding: Installers are build around the individual product.

Build procedure :
A build includes Installers of the available products – multiple platforms.

Testing
Smoke Test (BVT)  Basic application test to take decision on further testing

Testing of new features
Cross-platform testing
Stress testing and memory leakage testing.

Bug Reporting
Bug report is created

Development – Code freezing
No more new features are added at this point.

Testing
Builds and regression testing.

Decision to release the product
Post-release Scenario for further objectives.

Sometimes Tester need common sense to test a application!!!

I am saying this because most of the times it is not possible to test the whole application within the specified time. In such situations it’s better to find out the risk factors in the projects and concentrate on them.

Here are some points to be considered when you are in such a situation:
1) Find out Important functionality is your project?
2) Find out High-risk module of the project?
3) Which functionality is most visible to the user?
4) Which functionality has the largest safety impact?
5) Which functionality has the largest financial impact on users?
6) Which aspects of the application are most important to the customer?
7) Which parts of the code are most complex, and thus most subject to errors?
Which parts of the application were developed in rush or panic mode?
9) What do the developers think are the highest-risk aspects of the application?
10) What kinds of problems would cause the worst publicity?
11) What kinds of problems would cause the most customer service complaints?
12) What kinds of tests could easily cover multiple functionalities?

Considering these points you can greatly reduce the risk of project releasing under less time constraint.

Feel free to ask me any testing query, resume tips or job help.