STQA
Principles of Software Testing
Principles of software testing
The seven principles of software testing provide a foundation for
effective testing strategies and help in delivering high-quality software
solutions.
Testing Shows the Presence of Defects
The primary goal of software testing is to identify defects in the
software. Testing can demonstrate the presence of defects but cannot
prove their absence. Even after extensive testing, it is impossible to
guarantee that the software is entirely bug-free
• Principle: Testing can show that bugs are present, but not that there
are no bugs.
• Example:
Imagine testing a calculator app. You try 5 + 5, 10 – 3, and 4 × 2. All
work fine. But that doesn't guarantee all operations are bug-free—
what if 9 ÷ 0 crashes the app?
• Lesson: Just because something seems to work doesn't mean it's
100% correct.
Exhaustive Testing is Impossible
Exhaustive testing, which involves testing all possible inputs and
scenarios, is impractical due to the vast number of combinations.
Instead, testers should focus on risk-based testing and prioritize the most
critical areas of the application
• Principle: You cannot test every possible input or path.
• Example:
A login form accepts usernames and passwords. If there are 1 million
possible combinations of input, you can’t test them all.
• Lesson: Focus on important and risky areas instead of trying
everything.
Early Testing
• Incorporating testing early in the software development lifecycle
(SDLC) helps identify defects at an early stage, reducing the cost and
effort required to fix them. Early testing ensures that issues are
addressed before they become more complex and expensive to resolve
• Early Testing Saves Time and Money
• Principle: Start testing early in the development life cycle.
• Example:
If an architect forgets to include a bathroom in a house plan, it's
cheaper to fix on paper than after building.
Lesson: Finding bugs in design or requirements is much cheaper than
fixing them after coding.
Defect Clustering
• Defect clustering follows the Pareto Principle, which states that
approximately 80% of defects are found in 20% of the modules. By
identifying and focusing on these high-risk areas, testers can
efficiently allocate their resources and improve the overall quality of
the software
• Principle: A small number of modules contain most of the defects.
• Example:
In a shopping app, the payment module often fails because it's
complex, while the homepage rarely has bugs.
Lesson: Pay more attention to areas with a history of defects or
complexity.
Pesticide Paradox
• Repeating the same set of tests will eventually become ineffective in
finding new defects. To overcome this, testers should regularly review
and update their test cases, incorporating new and different tests to
uncover additional defects
• Principle: Repeating the same tests won’t find new bugs.
• Example:
If you keep checking that the login button works, you'll miss bugs in
the forgot password feature.
Lesson: Regularly update and improve test cases to catch new issues.
• Imagine you are testing a calculator app:
• Day 1: You test basic operations: 1 + 1, 2 × 3, 5 – 2, and find a bug in
subtraction.
• After fixing, you keep testing those exact same calculations every time
— but you never try something new like division by zero or large
numbers.
• So, after a while, those tests don’t find any new bugs because you’re
not exploring new scenarios.
Testing is Context-Dependent
• The approach to testing varies depending on the context of the
software being developed. Different types of applications require
different testing methodologies, techniques, and types of testing. For
example, testing an e-commerce site will differ from testing a
healthcare application
• Principle: How you test depends on what you’re testing.
• Example:
A medical app needs very strict testing for accuracy, but a game app
might focus more on user experience.
Lesson: The purpose and risk level of the software affect how you test
it.
Absence of Error – Fallacy
• A software product that is 99% bug-free may still be unusable if it
does not meet user requirements and business needs. Testing should
not only focus on finding defects but also ensure that the software
fulfills its intended purpose and satisfies user expectations
• Principle: A system with no bugs may still fail to meet user needs.
• Example:
An ATM works perfectly but only dispenses Rs.1000. Technically bug-
free, but not useful to users.
Lesson: A system must do the right things, not just work error-free.