1. Testing shows the presence, not the absence of defects

Testing can prove that defects are present in a system, but it can never prove that the system is 100% defect-free. Even after the most rigorous testing, we cannot say with absolute certainty that no bugs remain. Instead, testing reduces the probability of undiscovered defects and increases our confidence in the software’s quality.

Example A: You run 100 automated Playwright tests on a login page, and all of them pass. This proves those 100 scenarios work, but it doesn't prove a hacker can't bypass the login using a specific SQL injection.

Example B: A mobile app works perfectly on the latest iPhone. While testing shows it is functional on iOS, it doesn't prove the app won't crash on an older Android device that hasn't been tested yet.

Example C: After a week of rigorous testing, a release is labeled "stable." However, a bug is found by a user who enters a 500-character string into a field that the testers only tested with 50 characters.

2. Exhaustive testing is impossible

Trying to test every possible combination of inputs, preconditions, and paths is mathematically unfeasible for anything beyond the most trivial applications. For example, a simple form with 10 fields, each having multiple valid and invalid values, could result in billions of combinations.

• Solution: Use Risk Analysis, Prioritization, and Test Techniques (like Equivalence Partitioning and Boundary Value Analysis) to focus your efforts on the areas that matter most.

Example A: A "Date of Birth" field. Testing every single valid and invalid date combination from the year 1900 to 2026 would require millions of test cases, which is impossible due to time constraints.

Example B: A simple calculator. Trying to test every possible addition of two numbers (including decimals, negatives, and large integers) is mathematically infinite.

Example C: A search bar. Testing every possible combination of characters, emojis, and special symbols in every language would take years.

3. Early testing saves time and money

Often referred to as Shift-Left testing, this principle emphasizes starting test activities as early as possible in the Software Development Lifecycle (SDLC).

• Static Testing: Reviewing requirements and design documents before a single line of code is written can identify “bugs” in logic that would be exponentially more expensive to fix later.

• Cost impact: Fixing a defect found during requirements analysis is significantly cheaper than fixing one found during production.

Example A: An SQA engineer reviews a requirement document and notices that "User Roles" aren't defined. Correcting this text takes 5 minutes. Waiting until the code is written to realize roles are missing would take days of refactoring.

Example B: A developer writes unit tests for a Bash script before deploying it to the server. They find a syntax error immediately rather than crashing a production server later.

Example C: Testing a Figma prototype for usability. Finding that a button is too small to click on mobile is much cheaper to fix in the design phase than after the frontend has been built.

4. Defects cluster together

In many systems, a small number of modules or components contain the majority of the defects. This is often an application of the Pareto Principle (the 80/20 rule), where roughly 80% of the problems are found in 20% of the code.

Example A: In an e-commerce app, 80% of the crashes occur within the "Payment Gateway" module, while the "Product Description" and "Contact Us" pages are nearly bug-free.

Example B: A legacy module that was written 10 years ago and has been "patched" many times by different developers often contains more bugs than a brand-new, clean module.

Example C: A highly complex "Report Generation" feature that handles massive data processing is likely to have more defects than a simple "User Profile" edit page.

5. Tests wear out (The Pesticide Paradox)

If you run the same set of tests over and over again, they will eventually stop finding new defects. Just as insects develop resistance to a specific pesticide, the software “evolves” past your existing test cases (often because those specific bugs were already fixed).

• Action: Regularly review, update, and add new test cases to exercise different parts of the system and find new potential issues.

Example A: An automation suite has been running the same "Happy Path" tests for six months. It passes every time, but users are reporting bugs in the "Checkout" flow because the automated tests never check different shipping methods.

Example B: A tester always uses the name "John Doe" to test a form. The system works for "John Doe," but fails when a user enters a name with an apostrophe, like "O'Connor," because the tester never varied their data.

Example C: A security scan that only checks for the "OWASP Top 10" from five years ago will fail to find modern vulnerabilities that hackers have developed since then.

6. Testing is context dependent.

Testing is not a “one-size-fits-all” activity. The way you test an e-commerce mobile app is fundamentally different from how you would test a safety-critical medical device or a banking backend. The context dictates the test techniques, the level of rigor, and the types of testing required.

Example A: Testing a Banking Application requires extreme focus on security and data integrity. Testing a Video Game requires more focus on graphics, frame rates, and user immersion.

Example B: For an Agile project, testing is done in small increments every two weeks. For a Safety-Critical Medical System, testing requires months of documentation and strict regulatory compliance.

Example C: On an Ubuntu Server automation script, testing focuses on permissions and resource usage. On a Marketing Website, testing focuses on SEO and cross-browser responsiveness.

7. Absence-of-defects fallacy.

It is a fallacy (i.e., a misconception) to expect that software verification will ensure the success of a system. Even if the testing team finds and fixes 100% of the identified defects, the system might still be a failure if it doesn’t meet the user’s actual needs or business requirements.

Example A: A team builds a "bug-free" application that is technically perfect but is so difficult to navigate that no one wants to use it.

Example B: You develop a software that calculates taxes perfectly for the UK market, but the client actually needed it for the Bangladesh market. Despite having no bugs, the software is a failure.

Example C: An automation script runs perfectly without errors, but it's automating a business process that the company discontinued last month. The tool is "correct" but useless.

If you found this post helpful, consider buying me a coffee. It keeps me writing!