1.
Introduction to Software Testing
Q.1 What is software testing and why is it important?
Definition:
Software testing is the process of executing a program with the intention
of finding errors. Unlike debugging (which removes errors), testing
discovers undiscovered errors to ensure that the software works as
intended.
Importance:
1. Ensures reliability – verifies whether software behaves correctly and
consistently.
2. Early error detection saves cost – fixing errors in early phases
(requirements/design) is much cheaper than fixing them during testing
or maintenance.
3. Quality assurance – ensures software meets standards and customer
expectations.
4. Reduces risk of failure – poor quality software has high failure rates;
testing prevents business and system risks.
5. Customer satisfaction – delivers a trustworthy and usable product
Q.2 Define an error in the context of software testing.
In software testing, an error refers to a mistake made by a developer or
programmer during coding, design, or requirement specification.
• It is generally a human mistake that leads to incorrect results or
unexpected software behavior.
• Errors can arise due to wrong logic, syntax mistakes, misinterpretation
of requirements, or improper data handling.
• When an error exists in code, it may later cause faults (bugs/defects)
and eventually lead to failures when the software is executed
• Error → human mistake in coding/design.
• Fault/Defect → error reflected in the software.
• Failure → when the fault causes incorrect behavior at runtime.
Q.3 What is a fault and how does it differ from an error?
A fault (also called a defect or bug) is the manifestation of an error in the software.
• When a developer makes a mistake (error) in coding, design, or requirements, it gets
embedded in the software as a fault.
• Faults are present in the code, design, or documentation.
Error vs. Fault:
1. Error → A human mistake (wrong logic, syntax mistake, misinterpretation of
requirement).
2. Fault → The actual incorrect code or design in the software caused by that error.
3. Example:
o If a developer writes a = b + c instead of a = b – c, the mistake in logic is the
error, and the wrong statement in the program is the fault.
A fault may cause a failure when the software executes incorrectly at runtime
Error (human mistake) → leads to Fault (defect in code) → may cause Failure (wrong
output during execution).
Q.4 Explain the difference between a defect and a failure.
• A Defect (also called a bug or fault):
o It is a flaw or imperfection in the software product that occurs due to an
error made during development (coding, design, requirement analysis).
o Defects exist in the code or design before execution.
o Example: Wrong formula coded in a calculation module (total = price * qty +
tax instead of total = (price * qty) + tax).
• A Failure:
o A failure occurs when the software does not perform as expected during
execution, i.e., the presence of a defect causes the system to behave
incorrectly or produce the wrong output.
o It is the observable effect of a defect during runtime.
o Example: When the above incorrect formula is executed, the program shows
wrong billing results → this is a failure.
Key Difference:
• Defect = flaw in the code or design (potential problem).
• Failure = actual incorrect behavior/output seen when executing the software
Error (human mistake) → Defect/Fault (flaw in code) → Failure (incorrect behavior at
runtime).
Q.5 How does testing contribute to software reliability?
• Software Reliability means the ability of software to perform its intended functions
consistently, correctly, and without failure over a period of time.
• Testing contributes to reliability in the following ways:
1. Early defect detection: Testing finds errors before deployment, preventing failures in
real use.
2. Validation of requirements: Ensures the software meets user expectations and
specifications.
3. Verification of performance: Testing checks functional and non-functional aspects
(performance, usability, efficiency), ensuring consistent behavior.
4. Improves confidence: By systematically executing test cases, testing increases
confidence that the software will behave reliably under different conditions.
5. Supports maintenance: Regression testing ensures reliability is maintained even
after updates and bug fixes.
In short, testing removes defects, validates requirements, and ensures consistent
performance, which directly increases software reliability.
Testing is not just about finding bugs — it is about ensuring that the software can be trusted
to work consistently and correctly, which is the essence of reliability.
Q.6 What is the primary goal of software testing?
• The primary goal of software testing is to detect defects in the software and
ensure that it meets the specified requirements and quality standards.
• Testing does not guarantee an error-free product, but it ensures that:
1. Software behaves as expected under different conditions.
2. Defects are identified and fixed early, reducing cost and risk.
3. The product meets functional and non-functional requirements
(performance, usability, reliability).
4. It increases customer confidence and satisfaction.
In short, the main goal is “finding defects early and ensuring quality & reliability”,
not just proving the absence of errors
Testing is about detecting defects and ensuring the software works as intended, not about
proving perfection.
Q.7 Describe the difference between static and dynamic testing.
1. Static Testing
• Definition: Testing of software work products without executing the program.
• Focus: Prevention of defects by reviewing documents, code, and design.
• Activities: Code reviews, walkthroughs, inspections, requirement reviews, design
validation.
• When done: Early stages of SDLC (requirements & design).
• Goal: Detect errors before code execution and improve software quality at lower
cost.v
2. Dynamic Testing
• Definition: Testing of software by executing the program with test data.
• Focus: Detection of defects in the actual running system.
• Activities: Unit testing, integration testing, system testing, acceptance testing.
• When done: After coding phase.
• Goal: Validate that the software works as expected during execution.
Key Difference Table
Aspect Static Testing (Verification) Dynamic Testing (Validation)
Execution Code is not executed Code is executed with inputs
Objective Find defects in design/code before run Find defects during execution
Techniques Reviews, walkthroughs, inspections Black-box & White-box testing
Cost Impact Cheaper (detects errors early) More expensive (fixing after execution)
Example Requirement review, code inspection Running a login test with test data
In simple words: Static = Prevent defects (before running), Dynamic = Detect defects
(while running).
Static = Verification (no execution, prevention)
Dynamic = Validation (execution, detection)
Q.8 Why is exhaustive testing not possible?
• Exhaustive testing means testing a software system with all possible inputs,
conditions, and paths.
• In theory, this would ensure the software is completely defect-free.
• However, exhaustive testing is not possible in practice because:
1. Infinite input combinations – Most programs accept a huge range of inputs (e.g.,
integers, strings, files). Testing all is impossible.
2. Multiple execution paths – A program can have millions of different paths due to
loops, conditions, and branches.
3. Resource limitations – Time, budget, and manpower constraints do not allow testing
every possibility.
4. Diminishing returns – Testing every case is unnecessary; many cases are repetitive
and do not add new coverage.
5. Practical approach – Instead, we use effective test case design techniques
(equivalence partitioning, boundary value analysis, risk-based testing) to select a
finite, manageable set of tests that provide maximum coverage.
In summary: Exhaustive testing is impossible due to infinite possibilities, so testing
focuses on representative and critical cases.
Q.9 Explain the concept of “early testing.”
• Definition:
Early testing means starting testing activities as early as possible in the software
development life cycle (SDLC) — ideally during the requirement and design
phases, not waiting until after coding.
• Why Important?
1. Early defect detection – Errors in requirements or design are found before
coding begins.
2. Cost reduction – Fixing defects early is much cheaper than fixing them after
development or deployment.
3. Prevents defect propagation – Early detection avoids errors spreading into
later stages of the project.
4. Improves software quality – Continuous involvement of testers ensures
better alignment with customer expectations.
5. Supports verification & validation – Testing activities are integrated
throughout SDLC, not just at the end.
• Example:
If requirements are ambiguous, testers can identify issues early during requirement
reviews instead of waiting until the system fails during acceptance testing.
In short: Early testing = “Shift-left testing” → Detect defects earlier → Save time,
cost, and improve quality.
Early Testing = “Shift-left testing” → start testing early (requirements/design) → find defects
early → save cost and improve quality.
Q.10 What is the role of a software tester in the development process?
A software tester plays a crucial role in ensuring that the developed product is reliable,
defect-free, and meets customer requirements. Their main roles include:
1. Requirement Analysis & Early Testing
o Review requirements and design documents to identify ambiguities or
inconsistencies.
o Apply early testing principle (shift-left).
2. Test Planning
o Decide what to test, how to test, and prepare the test strategy, test plan, and
test cases.
3. Test Design & Test Case Development
o Prepare effective test cases using techniques like equivalence partitioning,
boundary value analysis.
4. Test Execution
o Run the test cases, compare expected vs. actual results, and log defects.
5. Defect Reporting & Communication
o Report bugs clearly to developers, track fixes, and retest resolved issues.
6. Quality Assurance Contribution
o Ensure software meets both functional and non-functional requirements
(reliability, usability, performance).
o Provide feedback to improve process as well as product quality.
7. Customer Advocacy
o Act as the “voice of the customer” by validating that the software satisfies
end-user needs.
In short: A tester is not just a bug-finder, but a quality advocate who works with
developers to deliver reliable software.
Testers don’t just “find bugs” → they ensure quality, reliability, and user satisfaction
throughout the SDLC.
Q.11 How can software testing reduce development costs?
Software testing reduces development costs mainly by detecting and fixing defects early in
the Software Development Life Cycle (SDLC).
Key Points:
1. Early Defect Detection
o Errors found in requirement or design phase are much cheaper to fix than
those found after coding or deployment.
2. Prevents Rework
o Catching issues early avoids defect propagation, which saves rework and extra
effort.
3. Reduces Maintenance Cost
o Well-tested software needs fewer patches and fixes after release.
4. Avoids System Failures
o Preventing failures in production reduces customer support costs, downtime
losses, and damage to reputation.
5. Optimizes Resources
o Planned testing avoids trial-and-error fixes later, saving time and manpower.
Conclusion: Testing lowers overall development and maintenance costs by detecting
defects earlier, avoiding rework, and improving software reliability
Early testing = Early defect detection = Less cost + Less rework + Reliable software.
Q.12 What are the limitations of software testing?
Although testing improves quality, it also has certain limitations:
1. Cannot Guarantee 100% Defect-Free Software
o Testing can show the presence of defects, but never prove their absence.
2. Exhaustive Testing Impossible
o It is not possible to test all possible inputs, paths, and conditions due to
time/resource constraints.
3. Dependent on Test Cases
o The effectiveness of testing depends on how well test cases are designed. Poor
test cases may miss critical defects.
4. Resource Constraints
o Limited time, budget, and manpower may prevent complete coverage.
5. Human & Tool Limitations
o Testers may overlook scenarios; automation tools also cannot cover all
aspects.
6. Dynamic Nature of Software
o Changes due to new requirements or environment updates may introduce new
defects after testing.
Conclusion:
Testing reduces risk but cannot ensure absolute correctness or perfection of the software
Q.13 How does software complexity affect the testing process?
• Software complexity refers to the level of difficulty in understanding, designing,
coding, and maintaining a program. As complexity increases, testing also becomes
more challenging.
Effects of Complexity on Testing:
1. Increased Number of Test Cases
o Complex programs have multiple conditions, loops, and execution paths →
require more test cases to achieve sufficient coverage.
2. Harder to Achieve Complete Coverage
o With high complexity, exhaustive testing becomes impossible; testers must
rely on sampling techniques (equivalence partitioning, boundary value
analysis).
3. Higher Probability of Defects
o More modules, interactions, and dependencies → higher chance of introducing
defects.
4. Greater Effort & Resources Needed
o Testing complex systems requires more time, manpower, and advanced tools.
5. Maintenance Challenges
o Complex software often changes more frequently → regression testing effort
increases.
Conclusion:
As software complexity increases, testing effort, cost, and difficulty also increase,
making it necessary to use systematic test design techniques and automation
Greater complexity → more defects, more test cases, higher cost.
Testers must use systematic techniques and automation to handle complex software
effectively.
Q.14 What is meant by the “pesticide paradox” in testing?
• Definition:
The pesticide paradox in software testing states that if the same set of test cases are
repeated over and over, eventually they will no longer find new defects.
• Explanation:
o Just like insects develop resistance to the same pesticide after repeated use,
software defects may remain hidden if testers keep executing the same test
cases.
o Over time, the existing tests only confirm what is already working, but
new/unexpected defects remain undiscovered.
• How to Overcome It?
1. Regularly review and update test cases.
2. Design new test cases based on recent changes, risk areas, and defect history.
3. Use different test design techniques (e.g., boundary value analysis, exploratory
testing).
Conclusion:
• Repeating old tests loses effectiveness.
• Test cases must be revised, improved, and diversified to continue finding defect
Pesticide Paradox = Old tests stop finding new bugs → testers must refresh & diversify tests
Q.15 Why is it important to document test results?
• Definition:
Test result documentation means recording the test cases executed, inputs used,
expected vs. actual outcomes, and status (pass/fail).
• Importance of Documenting Test Results:
1. Traceability
o Links requirements → test cases → results. Helps ensure all requirements are
tested.
2. Defect Tracking
o Clearly shows which tests failed, what defects were logged, and their current
status.
3. Communication
o Provides useful information for developers, managers, and clients about the
quality of the product.
4. Regression Testing Support
o Previous test results act as a reference for re-running tests after changes or
fixes.
5. Process Improvement
o Helps analyze defect patterns, test coverage, and areas needing improvement.
6. Audit & Compliance
o In regulated industries, documented test results are mandatory for legal or
quality certification purposes.
Conclusion:
Documenting test results ensures accountability, repeatability, and continuous quality
improvement
Document test results = Better traceability + defect tracking + regression testing +
compliance.
