Test management in projects

Checking project results in a structured way

What is test management?

Test management involves the planning, execution, monitoring and documentation of tests to help ensure that the final product is error-free, user-friendly and meets the requirements placed on the product.

The objectives of test management thus include:

1. The early detection of errors or deficiencies in the end product so that they can be rectified.
2. Identifying potential for improvement with regard to the user-friendliness of the product.
3. Verification that all requirements placed on the product have been met.
4. Reduction of risks that could arise from a defective product.
5. Approval of the finished product.

The process of test management

1. Planning

First, a test plan is created that defines the scope, duration, dates and resources of the tests. This test plan also contains the selected test strategy. The appropriate strategy depends on the particular requirements of the project and the product to be tested. Some examples are:

• Bottom-up: Here, the various components of the product to be developed are tested first before they are combined into larger units. The larger units are then also tested before they are assembled into the overall product, which is then tested as well. This approach is very suitable for complex products.
• Top-down: In contrast to the previous strategy, here the whole product is tested first before it is divided into smaller and smaller units that are then being tested individually. This makes this strategy well suited for less complex products.
• Hybrid: This strategy combines elements of different test strategies, for example bottom-up and top-down. In this way, this strategy can be used particularly flexibly and is suitable for products with medium complexity.
• Black-Box: In this strategy, the product is viewed like a black box, where the testers have no knowledge of the inner workings. They therefore test the product exclusively on the basis of the functions visible from the outside.
• White-Box: In contrast to the black-box strategy, the testers have knowledge about the inner workings of the product. This means that they test the individual components and functions in detail.

2. Specification and preparation

The next step is to specify the requirements for the tests and prepare the test environment as well as the test data:

• Specify goals: What is to be achieved with the tests? For example, are bugs to be found or usability to be checked? What are the acceptance criteria?
• Determine requirements for the product: What specifications should the final product meet? For example, what are the requirements in terms of functions, security or usability?
• Create test cases: Based on the goals and requirements, specific test cases can now be created that define which tests should be carried out and how they should be carried out.
• Determine test environment: In which environment should the tests take place? Large projects sometimes have their own test labs, but often testers also work at their own workstations or in meeting rooms where they have everything they need for the tests. In the case of a software product, for example, you specify under this point which operating system or browser should be used.
• Test duration: How long should the tests take?
  To ensure that all relevant aspects are considered in the tests, the requirements for the tests should be defined as detailed and specific as possible. At the same time, however, also consider the time available as well as the necessary resources in order to keep the scope and duration of the tests within a realistic framework.

3. Execution and documentation

Now the actual tests are carried out. The test cases are executed according to the test plan. Detailed documentation is important here so that the tests can be reproduced and possible errors can be traced more easily. The results of the tests should also be recorded so that conclusions can be drawn about the product quality.

4. Evaluation

The next step is to evaluate the results of the tests so that errors and defects can be analysed and corrected. Once they are corrected, testing can then be repeated.

5. Completion

In this step, the testing activities are completed and the test result is presented to the project team. The test documentation is kept and used as a reference for future projects as well as for lessons learned.

How do you determine the right test period for projects?

The optimal test period for a project should be carefully planned. This is because a too short test period could lead to a faulty end product, but a very long test period does not guarantee 100 per cent flawlessness and is at the same time uneconomical. You should consider the following factors when determining the test period:

• Project size:: Large projects usually require a longer test period, while smaller projects can have shorter test periods.
• Extent of the tests: If the required tests are very extensive, for example, because a lot of different functions are to be tested in a newly developed software, a longer test period is also required.
• Complexity: The same applies to complexity. If very complex functions need to be tested, the test period should be longer than for less complex functions.
• Available resources: The test period should also be adapted to the available resources. If, for example, only a few employees are available, the test period should be longer so that all necessary tests can be carried out. Conversely, if more staff are available, the period can be shortened. The same applies to other resources such as technical equipment needed for the tests.
• Availability of test data: If special test data is needed, for example due to long-term testing of a product, or if special test data is only available at special times because it depends on other factors, such as the completion of other functions, sufficient time should also be planned for its creation or procurement.

Our tip: You should carefully weigh up the various factors in order to determine an optimal time frame for your project. Take advantage of the experience you have gained from previous projects. In this way, you can ensure that you have enough time to thoroughly test all functions and discover any errors. At the same time, the test period remains realistic and does not delay the project because it was chosen too long.

Who is responsible for the tests?

There are usually different roles in test management:

• Test manager: The test manager coordinates all activities in the area of testing. He creates the test plan, organises the resources and monitors the progress.
• Test designer: Test designers are responsible for creating test cases and test documentation. They analyse requirements and design test scenarios.
• Testers: Testers carry out the tests and document the results. The tests themselves are usually carried out by specialised testers who are familiar with the respective test methods or procedures, or have extensive knowledge in the area to be tested. This ensures that all relevant aspects are taken into account and that the tests are meaningful.
  In addition, however, it can be useful to have other people participate. These can be developers or department experts, for example, but also those who will use the product after its completion.
  Testers should always be independent. This means that the creator of a product should not be responsible for its testing. Although the creator will regularly test the product during development, independent testing prevents errors from being overlooked due to “operational blindness”.
• Test controller: A test controller monitors the progress of the tests and ensures that all tests are carried out according to plan. He is also responsible for ensuring that all documents are complete and up-to-date.
• Test reporters: In some companies there are also test reporters who prepare test reports and present the results as well as recommend improvements.

The roles you need for test management in your company depend on the size of the company and the project, but also on the resources and skills available. Since testers should be independent, it may be sufficient to have a test manager in addition to the tester, who also takes on the role of test designer and controller.

Differences in classic, hybrid and agile projects

Depending on which project management approach is followed, test management also differs.

• Classic projects are structured into individual project phases that are processed in a fixed order. Therefore, a test phase is already defined during project planning, as well as a comprehensive test plan that specifies all tests that are to be carried out.
• Hybrid projects are less rigidly defined than classic projects because they combine classic and agile methods. Depending on the combination chosen, these projects therefore also allow more flexibility in test management.
• Agile projects use an iterative approach in which requirements are implemented in small sprints. Tests are an important part of these sprints, as the focus in agile approaches is on continuous review and improvement of the product. Therefore, short test cycles are often used here, which allow for quick feedback and early bug fixing.

Difficulties in test management

Test management can be associated with various difficulties. Some examples are:

• Lack of time: there is often little time for testing, which can lead to tests not being carried out thoroughly or even being omitted altogether. Especially when there is a threat of delay in a project, the temptation for the latter is great. In such cases, however, bear in mind that in the worst case scenario, a faulty product will be delivered, which is likely to lead not only to some unpleasant rework, but may also damage your reputation and customer relations.
• Lack of resources: Similar to lack of time, lack of resources can lead to tests not being carried out or not being carried out thoroughly. Finding good testers is difficult in times of skill and staff shortages. Keep this in mind during the planning phase so that tests can be carried out appropriately even when staff is low.
• Lack of documentation: Without sufficient documentation, it can be difficult to reproduce tests or track errors. At the same time, this makes it harder to draw lessons learned for future projects from the current project.
• Changes during the project: In the course of a project, the requirements for the product may change. New functions may be added, their characteristics may change or planned functions may be dropped. In such cases, the planned test management no longer fits the current specifications and must be adapted. Tests have to be changed, test cases have to be created anew and maybe even the test period has to be extended or additional resources have to be found. Only in this way can you ensure that the tests are relevant and sufficient.
• Difficulties in merging individual components: If different components, such as functions of a software, were developed by different developers or teams, it can be difficult to integrate them and test them together. In this case, make sure that there is clear communication and good cooperation between the different developers to prevent difficulties.

Conclusion

Good test management supports you in quality assurance and in improving the project results. Therefore, you should by no means dispense with sufficient tests.
Modern project management software can help you integrate test management into your projects. For example, the software helps you to schedule a test phase in classic projects or to keep the test phase in the respective sprints in agile projects. The documentation of the tests can also be stored within the software and measures can be derived from it immediately. In this way, you can control the implementation of improvements in the same system.

Would you like to get to know myPARM in a demo presentation? Then make an appointment with us right away!