I recently came across an article that discussed the 7 core software testing principles at the heart of the ISEB / ISTQB Foundation (CTFL) certification level. For me, it was an excellent way to refresh my memory so I thought it would be helpful to summarize the 7 principles in this blog post. As I’m sure you know, the ISEB Foundation level focuses on the fundamentals of software testing, so understanding these 7 key principles is critical to pass your exam.
Principle 1: Testing shows the presence of bugs (but a failure to find bugs does not necessarily mean that none exist). Tests must be designed to find as many bugs as possible, and since it is assumed that every product initially has bugs, a test that identifies bugs is better than one that finds none.
Principle 2: Exhaustive testing is impossible because there are usually too many variables that come into play. Therefore, testers must focus efforts on only the most critical priorities and risks.
Principle 3: Testing should be done as early as possible after the product or application has been created, in order to fix issues as fast as possible. Errors identified later in the process tend to be more expensive to mitigate.
Principle 4: Use defect clustering, as software problems tend to cluster around narrow areas or functions. By identifying and focusing on these clusters, testers can efficiently test the sensitive areas while concurrently testing the remaining “non-sensitive” areas.
Principle 5: Use a variety of tests and techniques to expose a range of defects across different areas of the product. Avoid using the same set of tests over and over on the same product or application, because this will reduce the range of bugs you will find.
Principle 6: The same tests should not be applied across the board because different software products have varying requirements, functions and purposes. For example, a website should be tested differently than a company Intranet site.
Principle 7: Don’t buy into the absence of errors fallacy. In other words, a test that finds no errors is different than concluding that the software is error-free. It should be assumed that all software contains some faults, even if said faults are hidden.