Software is indispensable in today's life. One cannot live without it. But where there is software, there are software errors. To keep the risks as low as possible, structured testing is important. Digital transformation and an agile way of working mean that more testing is needed than ever. During testing defects is registered. It is very important to properly record test findings. Below are a top five of important principles for recording test findings.
It can save a lot of time when test findings are reproducible. During testing, for example, a function turns out not to work as described, expected or predicted. Before this "error" is recorded only as defect, it is first important to check whether the defect is reproducible. If it is possible to obtain the same result every time the same steps are taken, the defect is reproducible. If this is properly recorded in the defect , the person who must solve the defect can reproduce the defect in one go by following the recorded steps. This saves a lot of extra (throughput) time. In many cases the defect comes back to the tester a few days later, unsolved and with a request to provide more information. The question is then whether the tester can still find out the exact steps to reproduce the error.
When an error is found, it is therefore important to reproduce the test finding immediately and to take the exact steps in defect . When using the test management tool Testersuite this happens automatically. When registering a defect during the execution of a test case, the test steps are copied in the defect. It is also indicated to which test step the defect refers and what the result of the previous steps was. In addition, it is advisable to attach screen prints to a defect. All this extra context information increases the reproducibility on the side of the (often external) resolving party.
Work can be done much more efficiently if test findings are provided with a clear description. But where can these descriptions be placed in an orderly fashion? There are often emails back and forth between the people involved in test cycle. As a result, it is often unclear what status the test cycle has. The test management tool Testersuite makes it possible to record everything in one environment. It is also advisable to make a distinction between a short and a long description of a defect. The test management tool Testersuite already makes this distinction.
The short description consists of one sentence and is shown in the general findings list. It is important to name both the problem and the context in which this problem occurs. The short description "Error 1423 when opening search screen Debtors" is much more meaningful than the (too) short description "Error in search screen".
The long description contains more detailed information about the defect and how it can be reproduced. This description contains at least the following information:
As indicated earlier, it is of great value if the test script and/or screen prints that have been carried out are recorded in the defect.
If a major change takes place, where a lot of testing is required, it is not unusual for several hundred defects to be recorded. At the start of the test phase, new test findings are recorded faster than test findings are resolved. Experience has shown that persistent errors sometimes remain unresolved for a long time, because they are often the most complex. It is therefore essential to set priorities, with the highest priority test findings being picked up first. It is also very important that clear agreements are made about determining priorities. Often, the first priority is determined by the person who registers the defect and is reviewed by the coordinator of test cycle. In addition, the meaning of the various priorities must be clear to all parties involved.
Some example priorities with a possible meaning:
After a test finding has been reproduced with a clear description and the correct priority, it should be assigned to a "handler". This can be a colleague for further analysis, a supplier/implementation partner or an official from the business. If it is a large test phase with many defects, it may be recommended to appoint a test coordinator. This person has the task of assessing the new test findings for completeness (see points 1, 2 and 3). He/she then assigns the test finding to the practitioner. This is also called dispatching of test findings.
Finding and solving defects generally improves the quality of the system for the Go Live. With every solved defect the system contains less errors. However, the test results also say something about the quality in a more general sense.
Parts of the system with many errors - be it customised transactions, interfaces or reports - may be of a lower quality than parts with none or few defects. When many urgent test findings are found within an important system component, it makes sense to take a closer look at this component. For this reason, it is important to 'link' defects to the system part (requirement, SAP transaction, interface, reporting, etc) to which it applies. This gives you more insight into the overall quality. This insight is needed to give a positive advice to the Go Live.
When it comes to collaborating with different departments or even external parties, most "lists" no longer suffice. Testersuite is an example of a user-friendly tool for recording test results, among other things. Such a tool adds a lot in the field of traceability and handling via workflows. Testersuite FREE is a free product with which you can get to work within two minutes with all those involved in the test process. With this, lists with defects in Excel, Sharepoint or even by mail are no longer of this time.