Test Planning and Test Management

If you imagine that testing a large system involves writing, running and verifying tens of thousands of tests, maintaining thousands of modules, correcting thousands of errors while requiring efforts, perhaps, of hundreds of people at different time periods for a year or more, then it becomes clear how challenging it is to manage a project, in particular, to plan, control and monitor the testing process. You could devote a whole book to such an activity as test management.

The main miscalculation in test planning is that no errors are assumed to be present in the software during scheduling. This miscalculation may lead to underestimation of the necessary resources (people, calendar and computer time). This is a known problem in computer technology. It is complicated by the fact that the testing process takes place in the final stage of the development, when it is already difficult to maneuver resources. The second and probably more significant problem is related to the incorrect definition of testing. Since the experience of using the correct test definition (the purpose of testing is to find errors) is not sufficient yet, the analysis is planned assuming that errors will not be detected.

Do you want to know whether your e-commerce site is compatible with multiple browsers? Website testing service is used to check the software for functional, usability and security issues.

Test planning is the main part of the testing process. The test plan includes the following components:

1. Objectives. This section of test plan contains the objectives of each testing phase.
2. Completion criterion. This criterion indicates that each testing phase is completed.
3. Work schedules. Work schedules are compiled for each testing phase. They should include design time, coding time and test execution time.
4. Responsible people. This section contains the names of persons who will design, code, execute tests and check the results, as well as those who will correct the errors found at each phase. There is also a name of the arbitrator, since in large projects, unfortunately, disputes often arise at the time of discussion of the test results (for example, due to ambiguities or incorrect definitions in the specifications).
5. Test libraries and standards. In large projects, systematic methods of identifying, writing and storing tests are needed.