Pseudo-debugging (bebugging), which is one of the methods for modifying a program, is a way to determine the effectiveness of test strategies used in a project. Before proceeding to a pseudo-debugging, it is necessary to garner the support of both testers and developers. How would you answer the question often asked by the development manager: “When can you expect to detect the majority of errors in this version?” The test manager usually asks the counter question: “And how many minor errors do we need to find?” The main indicator of the test progress should be the ratio of number of errors found during the analysis to the number of hidden errors that need to be found, it is expressed as a percentage. The problem with the calculation of the above indicator is that both the numerator and the denominator of this ratio are unknown.
Quality control companies look forward to monitoring the development process from start to finish with intent to detect and prevent errors that may occur in the software being built.
Pseudo-debugging is a process of introducing pseudo-errors in the program deliberately. Further, the received version is tested, and then the testing efficiency is determined by comparing the detected and artificially created errors. The ratio of the number of artificially created errors to the number of errors created must be equal to the ratio of the number of errors found to the number of hidden errors. This method allows you to define the role of the indicator measuring the test progress, determined just above.
Organizations that use rapid testing find that pseudo-debugging can speed up testing by determining the conditions for terminating it. In fact, the process by which errors are deliberately introduced in the code requires a creative approach. If artificially created errors are classified into groups according to a historical model of errors in similar developments using the same programming language, and if the detected errors are likewise divided into types, then analysis of the test progress can be conducted for each type. In this case, we cannot only answer with certainty to the question: “When can we expect to detect the vast majority of errors in this version?”, but also to say: “We found most of the logical errors in the program, and now are busy developing additional test cases for checking the reliability of the error handling modules”. Similarly, all artificially created errors can be divided into levels of severity.
Comments are closed.
