Software Testing: Adapting to the Changes

Member Submitted

you are really going to test it.

It is important to note that this phase becomes more important in case of testing projects as compared to testing phase because of the following two reasons:

  1. As a different company is carrying out software testing, testers may find that query resolution, and requirement understanding takes comparatively more time than if testing is being carried out by the same company who developed the software.
  2. All of us, who have worked on development projects, know the importance of "Requirement Analysis" in SDLC. If a requirement is analyzed incorrectly, and is detected while development/testing, the cost to be paid is enormous. Similarly, while testing, if a requirement is understood incorrectly, the tester may create incorrect test cases, execute them, and may even end up reporting incorrect defects, resulting in wastage of efforts.

The bottom line is that, this sub-phase is one of the major difference between a testing phase, and a testing project, and from tester's perspective, it is the most important phase of STPLC.

2. Test case creation
The phase
Once the testers have a clear understanding of requirements, they can start creating test cases, specifying test steps, and relevant expected results.

Adapting to the changes:
After the test cases /test scripts /test data are created, they should be verified for quality, and adequacy. Test cases should also be created for covering random flows for unexpected end-user behavior. Although it is nearly impossible to cover each and every aspect in test cases, an attempt should be made that the test cases/test scripts /test data cover most of the flows.

This phase may also require some communication with client and /or development vendor if the requirement/specification documents are missing or not up-to-date. If possible, a sign-off can also be taken from client for quality, adequacy, and completeness of the test cases /test data/test scripts.

3. Test execution, and defect reporting
The phase
After completion of test case creation, the task of running the test scripts and executing the test cases can be performed.

Adapting to the changes:
The defects found during test execution have to be reported to the client/development vendor. Here, the format/tool used for reporting defects becomes important because testing, and development vendors are different. The defects need to be precise, and clear to avoid any sort of disconnects, and to minimize average defect lifetime.

One more issue to be taken care of while executing test cases is setting of test environment. Setting up the test environment can be an issue, as testing-vendor may be testing from a different geographical location. It should be ensured that test environment is properly set before the actual execution begins.

It should also be ensured that test environment is different from the development environment, and any code push to the test environment by the development-vendor is reported to the client. If test environment, and development environment is same, developers may fix any reported defect, and reject it saying that the defect never existed.

4. Defect fixing by development-vendor
The phase
Once the defects are detected, and reported, they will be fixed by the development-vendor(s).

Adapting to the changes:
Development-vendor /client may even reject some of the defects, or even ask for clarification on some of the defects. The efficiency, and effectiveness of the communication depends on the format /tool used for reporting defects.

Note: This phase is not an action item on testing-vendor's part, and the time take by development-vendor during this phase is the major factor for average defect lifetime.

5. Retesting fixed defects, and reporting
The phase
The fixed defects have to be retested to

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.