In this article, we will review seven Software Testing Principles that have been observed over the last 40+ years. These principles, while not always under stood or noticed, are in action on most if not all projects. Knowing how to spot these principles, and how to take advantage of them, will make you a better tester.
In addition to the descriptions of each principle below, you can refer to Table
for a quick reference of the principles.
Principle 1. Testing shows the presence of defects, not their absence
- No test team, test technique or test strategy can guarantee to achieve 100% defect-detection percentage (DDP) – or even 95%, which is considered excellent.
- Thus, it is important to understand that, while testing can show that defects are present, it cannot prove that there are no defects left undiscovered.
|Principle 1||Testing shows the presence of defects, not their absence||Testing can show that defects are present, but cannot prove that there are no defects. Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, testing is not a proof of correctness.|
|Principle 2||Exhaustive testing is impossible||Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Rather than attempting to test|
exhaustively, risk analysis, test techniques and priorities should be used to focus test efforts.
|Principle 3||Early testing saves time and money||To find defects early, both static and dynamic test activities should be started as early as possible in the software development life cycle.|
Early testing is sometimes referred to as ‘shift left’. Testing early in the software development life cycle helps reduce or eliminate costly changes
|Principle 4||Defects cluster|
|A small number of modules usually contains most of the defects discovered during pre-release testing, or they are responsible for|
most of the operational failures. Predicted defect clusters, and the actual observed defect clusters in test or operation, are an important input into a risk analysis used to focus the test effort (as mentioned in Principle 2).
|Principle 5||Beware of the|
|If the same tests are repeated over and over again, eventually these tests no longer find any new defects. To detect new defects, existing tests and test data are changed and new tests need to be written. (Tests are no longer effective at finding defects, just as pesticides are no longer effective at killing insects after a while.) In some cases, such as automated regression testing, the pesticide|
paradox has a beneficial outcome, which is the relatively low number of regression defects
|Principle 6||Testing is context|
|Testing is done differently in different contexts. For example, safety-critical software is tested differently from an e-commerce mobile app. As another example, testing in an Agile project is|
done differently to testing in a sequential life cycle project
is a fallacy
|Some organizations expect that testers can run all possible tests and find all possible defects, but Principles 2 and 1, respectively, tell us that this is impossible. Further, it is a fallacy to expect that just finding and fixing a large number of defects will ensure the success of a system. For example, thoroughly testing all specified requirements|
and fixing all defects found could still produce a system that is difficult to use, that does not fulfil the users’ needs and expectations or that is inferior compared to other competing systems.
Principle 2. Exhaustive testing is impossible
- This principle is closely related to the previous principle. For any real-sized system (anything beyond the trivial software constructed in first-year software engineering courses), the number of possible test cases is either infinite or so close to infinite as to be practically innumerable.
- Strategy for selecting tests is requirement s- based testing. In requirement s-based testing, testers analyze the requirements specification (which would be user stories in Agile projects) to identify test conditions. These test conditions inherit the priority of the requirement or user story they derive from.
- We focus the test effort based on the priority to determine the appropriate number of test cases for each aspect, and also to sequence the test cases.
Principle 3. Early testing saves time and money
- This principle tells us that we should start testing as early as possible in order to find as many defects as possible. In addition, since the cost of finding and removing a defect increases the longer that defect is in the system, early testing also means we are likely to minimize the cost of removing defects.
- The first principle tell s us that we cannot find all the bugs, but rather can only find some percentage of them. The second principle tells us that we cannot run every possible test. The third principle tells us to start testing early.
Principle 4. Defects cluster together
- Defect clustering is helpful to us as testers, because it provides a useful guide. If we focus our test effort (at least in part) based on the expected (and ultimately observed) likelihood of finding a defect in a certain area, we can make our testing more effective and efficient, at least in terms of our objective of finding defects
Principle 5. Beware of the pesticide paradox
- The pesticide paradox is impo1tant when implementing the multilevel testing discussed previously in regards to the principle of early testing. Simply repeating our tests of the same conditions over and over will not result in good cumulative defect detection.
- However, when used properly, each type and level of testing has its own strengths and weaknesses in terms of defect detection, and collectively we can assemble a very effective sequence of defect filters from them.
- After such a sequence of complementary test activities, we can be confident that the coverage is adequate, and that the remaining level of risk is acceptable.
Principle 6. Testing is context dependent
- Our safety-critical clients test with a great deal of care – and cost. When lives are at stake, we must be extremely careful to minimize the risk of undetected defects.
- Our clients who release software on the web, such as e-commerce sites, or who develop mobile apps, can take advantage of the possibility to quickly change the software when necessary, leading to a different set of testing cha1Jenges – and opportunities.
Also, check Selenium Interview Questions and Answers
Principle 7. Absence-of-errors is a fallacy
- Throughout this section we have expounded the idea that a sequence of test activities, started early and targeting specific and diverse objectives and areas of the system, can effectively and efficiently find – and help a project team to remove – a large percentage of the defects. Surely that is all that is required to achieve project success?
- Sadly, it is not. Many systems have been built that failed in user acceptance testing or in the marketplace, such as the initial launch of the US healthcare.gov website, which suffered from serious pe1formance and web access problems.
Software Testing – FAQs
Q. What is software testing definition?
Ans: Software testing is the process of evaluating and verifying that a software product or application does what it is supposed to do. The benefits of testing include preventing bugs, reducing development costs and improving performance.[Resource]
Q. What is basic of software testing?
Ans: Software testing is the process of finding errors in the developed product. It also checks whether the real outcomes can match expected results, as well as aids in the identification of defects, missing requirements, or gaps. Testing is the penultimate step before the launch of the product to the market.
Q. What is the role of software testing?
Ans: Basically, a software testing helps not only to discover defects in software, but also its configuration. Through testing, developers are able to determine the reliability of the software. Any product can be turned into a strong and consistent product with the help of testing in software development
Q. What is QA in testing?
Ans: Quality Assurance (QA) refers to the meta process that ensures continuous and consistent improvement and maintenance of processes that enables a QC job
Q. Why do we need testing?
Ans: Testing is necessary in order to provide the facilities to the customers like the delivery of high quality product or software application which requires lower maintenance cost and hence results into more accurate, consistent and reliable results.
Q. Does software testing require coding?
Ans: Not all roles in software testing require coding. There are functional and product-based Testing roles that require no coding at all. However, technical software testing roles require programming or scripting knowledge for developing tools and automation testing.