5 typical defects of new test managers

Anyone who hires a test manager naturally wants to improve their test process. Often, companies lack professional preparation and supervision of the tests. This is where external test managers come in handy, taking over the planning and management and thus improving and constantly monitoring the effectiveness of the processes. An external test manager also brings new perspectives - which pays off.

Anyone who hires a test manager naturally wants to improve their test process. Often, companies lack professional preparation and supervision of the tests. This is where external test managers come in handy, taking over the planning and management and thus improving and constantly monitoring the effectiveness of the processes. An external test manager also brings new perspectives - which pays off. As an external professional, however, it's often not easy to directly oversee IT projects and ask the right questions. We've collected the five most common defects that ultimately lead to testing defects from new test managers here:

1. Wrong prioritization of requirements.

When testing the software, the testing process should check whether or how well the specified requirements are met. An important task, which holds a high bug potential, is the prioritization of the requirements. For this a comprehensive knowledge of the product is inevitable, therefore a good test manager should be at the beginning in particular a good listener and become well acquainted with the product. When prioritizing the requirements, the probability of occurrence and the impact are relevant for the overall risk: If the described use case occurs quite frequently, but the impact of a resulting Testing Defect is low, then this requirement may need to be prioritized lower than a use case that occurs less frequently, but has a massive impact on the product if a defect occurs.

2 Defects not properly factored into effort estimates

One question that will be particularly pressing for the controlling and finance department is an estimation of the effort: How much time (and thus money) does testing cost? When estimating the testing effort, it is therefore particularly important to always reckon with the fact that bugs will also occur during the execution of the testing cases and that these will have to be readjusted, documented and also retested after a fix. And don't forget: If there is at least one testing defect, the corresponding testing case must be repeated. Estimating the effort required is a very difficult task. Good test managers obtain empirical values from the specialist department for existing IT systems and can also draw on their own empirical values for unknown or new systems. However, they are well advised to tend to allow more time. This may not please everyone in the company, but it provides a valuable buffer in the testing process: If fewer defects occur, all the better!

3. processes in the defect workflow are not clearly defined

It is clear that it will come. But what exactly happens when a so-called defect is found had better be clearly defined before the test runs begin. Here, the test manager is in a mediating and planning role: He must talk to the development department and develop a workflow. It must be clarified which status transitions there are and how the developer is notified of the defect. The exact procedure for retesting must also be defined in the defect workflow. Good tools support the testers here by recording bugs and linking them directly to the test runs, as well as clearly defining the status transitions.

4. requesting test data and environments too late

The requirements have been prioritized, the testing cases written, and the testers guided: We are ready to go. But only almost, because test environments, access data and test data are still needed for the software test. A quick request to the IT department - and depending on the size of the company, testing can begin just three to four weeks later. To prevent this from happening, the test manager should take care of test data and test environments at an early stage and discuss his wishes with the specialist departments in the company. This is the only way to ensure that adjustments to the firewall, the activation of access for the testers and also important test data (e.g., address and credit card data that can be used for test purchases of a shopping app) are available at the start of testing. Therefore, a good test manager takes care of the test data and environment while writing the testing cases.

5. Do not schedule test automation.

Many people shy away from test automation: the high initial effort and sometimes lack of resources in the company often lead to automation being pushed aside at an early stage. A good test manager takes a closer look: Especially testing cases that are repeated for each release, e.g. due to high requirement prioritization, are an optimal use case for test automation. A major advantage is often a cost saving: After the one-time creation, an automated test can be repeated as often as desired without or at significantly lower costs. At the same time, automated tests are significantly faster and thus reduce the turnaround time. The earlier the importance of the corresponding test cases is recognized, the more worthwhile automation becomes: A good test manager suggests corresponding test cases early on and does not only recognize after the fourth release that the regression tests are in many cases good automation candidates.

In some companies, there is simply not enough staff to handle the initial effort of test automation. In such cases, it is the task of a good test manager to propose automation to the project management, clearly demonstrating the use case, defect workflow and cost savings. The test manager should request external support for the implementation.

No master has yet fallen from the sky: As a new test manager, the support of the test process does not always run one hundred percent smoothly at the beginning. But with our expert tips on the five most common defects, aspiring test managers get good advice on the right way to handle requirements prioritization, defect workflow, effort estimation, planning automation and contacting business departments to have test data and environment set up.

You are a tester yourself and know other typical sources of errors? Feel free to contact us and we will publish new tips and tricks for error prevention! Just write to welcome@andagon.com.