One type of test case that must be present in the evidence of dirty systems is the regression test case. It seems that dirty systems are most at risk of regression, which is when a change in a piece of software causes further validated defect that occurs. Regression defects are a fact of life in the software, especially software maintenance, which forces people to test more than just changes.
The key issue in regression testing is how test cases are needed to test a new version. The answer to this question depends on:
The relative risk of the system being tested-
If the potential impact of the flaws are minimal, then to test a large number of cases every time you make a change may be excessive. However, if the property or safety is at risk, a large number of regression test cases would be appropriate.
The level of system integration-
This is a two-edged sword, because on one hand, highly integrated systems seem to be prone to defects regression due to the complex nature of many interfaces. A change in one module might show a defect in another module behind the processing flow. Moreover, highly integrated systems are difficult to regression test due to the large number of possible test cases required to adequately cover the paths of integration. If one could predict where the defects may be, we would not need regression testing. However, this is not the case of systems dirtier.
The scope of change-
This is also a difficult criterion to define precisely. It is a temptation to reduce the level of regression testing, because a change can be very small. However, experience tells us that some major software failures can be traced back to a simple change of a single pole.
Of course, these are highly visible examples of notable failures, and this measure will not happen every day, thank God. The point we are making my presentation of them is that a small defect can have a huge impact. You can find a list of many other classical problems of software.
0 comments:
Post a Comment