Software Testing Process

Testing is the verification and validation activity for the software product. It involves checking processes, such as inspections and revise, at each stage of the software process from user requirements definition to program development. Except for small programs, system should not be tested as a single, monolithic unit. Large systems are built out of sub-systems which are built out of modules which are composed of procedures and functions. The testing process should therefore proceed in stages where testing is carried out incrementally in conjunctions with system implementation.

Testing is a four stage process where system components are tested, then the integrated system is tested and, finally, the system is tested with the customer’s data. During the testing process, the program components are combined into the overall software code and testing is performed according to a developed test (software verification and validation) plan. As defects are discovered the program must be debugged and this may require other stages in the testing process to be repeated. Errors in program components may come to light during integration testing. The process is therefore an iterative one with information being feedback from later stages to earlier parts of the process.

The Testing Process

Testing should begin only when certain activities are complete and the foundation is laid.

Preparing for Testing

The following items are indicators of testing readiness
•    Requirements (SRS), functional design (SDD), and internal design (Chapin charts flow graphs) specifications are complete, approved, and available.

•    Budged and schedule requirements are published; schedule estimates, timelines, and milestones have been set.

•    The test plan has been written, reviewed, and approved.

•    Standards and processes (Such as release and chance processes) are documented.

•    The project team has been assembled, had their responsibilities assigned, and been trained on standards and processes.

•    The high-risk aspects of the system have been identified,

•    Priorities and the scope and limitations of tests have been determined.

•    Test approaches and methods have been identified-how will the test be conducted, by whom, and when, for unit (white box), integration (black box), functional, system, usability, and so on.

•    Test environment requirements have been satisfied (hardware, operating systems, configuration management, communications, etc.).

•    Supporting software requirements (i.e., coverage analyzers, problem tracking record/playback jack tools) have been determined.

•    Test input data requirements have been determined; test input data has been obtained,

•    Input equivalence classes, boundary value analysis, and error classes have been determined.

•    Test cases have been written, reviewed, and approved.

Testing Teams

In selecting a testing organizational model, there is a skills-based approach, which a tester with specific skills works for a test managers who assigns the tester to one or more projects in a matrix organization. This has advantages in that the tester has the opportunity to become a true specialist in one area and make that expertise available across projects. The disadvantages are that the tester may be uncertain about where to spend time, and project managers may be wary about getting “their share” of the resources.

Another organizational model is the project-based model, which assigns a testing team to each project. This approach allows the testing team to share in the project vision and become dedicated to its success. In terms of team building, this is a better choice. A potential risk with project-based model is that the testers may become too close to the developers and succumb to compromising stringent testing principles.

There is an anecdote about a testing team at IBM that become known as “the Black Team” because they wore black capes, grew moustaches (which they twisted), and reveled in their reputation as evil destroyers of software. Not only did they have a lot of fun, but the competition between them and the developers was a boon to project quality. Developers strove to product a product that the Black Team could not break, and the team was intent on preserving its standing. It would be great if all teams could develop into such “performing” groups. Doubtless, having a shared vision of the mission ia a cornerstone of team building.

Test Documentation

IEEE offers standards for software test documentation and suggests that basic documents include these:

A test plan to prescribe the scope, approach, resources, and schedule of the testing activities to identify the items being tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with this plan.

•    A test design specification to specify refinements of the test approach and to identify the features to be tested by its design and is associated tests.

•    A test case specification to define a test case identified by a test-design specification.

•    A test procedure specification to specify the steps for executing a set of test cases or, more generally, the steps used to analyze a software item to evaluate a set of features

•    A test item transmittal report to identify the test items beign transmitted for testing

•    A test log to provide a chronological record of relevant details about the execution of tests

•    A test incident report to document any event that occurs during the testing process that requires investigation

•    A test summary report to summarize the results of the designated testing activities and to provide evaluations based on these results.

For more help in Software Testing Process click the button below to submit your homework assignment