Lesson 2: What Testing Is: Objectives, Testing vs Debugging

Before you start

Reminders from Level 1:

• The exam has 40 multiple-choice questions in 60 minutes, and you need 26 correct to pass.
• The syllabus is ISTQB's copyright and is not reproduced here.
• Download the current syllabus (v4.0.1), the sample exams and the glossary free from istqb.org and keep them open beside this lesson.
• This course is independent of ISTQB, is not accredited, and cannot promise a pass.

This level covers syllabus section 1.1.

Task 1: Define testing correctly

Many beginners think testing means "running the program to see if it works". That is too narrow for the exam.

Software testing is a set of activities that discover defects and evaluate the quality of software work products.

Three terms to learn now:

• Work product: anything produced during development, such as requirements, user stories, designs or code.
• Test object: the work product being tested. In a review of a design document, the design document is the test object.
• Defect and failure (working definitions; Level 3 goes deeper): a defect is a flaw in a work product. A failure is the software visibly misbehaving when it runs.

Testing is also more than executing tests. It includes planning, managing, estimating, monitoring and controlling the test work, and it has to fit the development lifecycle.

Do this: write the definition in your own words, then compare it with the ISTQB glossary entry.

Task 2: Separate static from dynamic testing

Ask one question: is the software being executed?

• Dynamic testing: yes. You run the software and observe its behaviour.
• Static testing: no. You examine a work product without running it. This includes reviews (people reading it) and static analysis (a tool examining it).

Example: a team builds a login page.

1. A tester reads the user story and spots a missing rule for locked accounts. This is static testing.
2. A tool scans the code for unused variables. This is static testing.
3. A tester types a wrong password and observes the error message. This is dynamic testing.

Consequence to remember: only dynamic testing can trigger a failure, because only running software can misbehave. Static testing finds defects directly.

Task 3: Separate verification from validation

Testing checks two different things.

• Verification: does the system meet its specified requirements? Short form: are we building the product right?
• Validation: does the system meet the real needs of users and other stakeholders in its operational environment? Short form: are we building the right product?

Analogy: a builder follows the blueprint exactly, so verification passes. The family then finds the kitchen too small for how they cook, so validation fails. A product can match its specification and still not suit its users.

Do this in any scenario question:

1. Find what the work product is compared against.
2. If it is a specification, requirement or standard, answer verification.
3. If it is user needs or expectations in real use, answer validation.

Task 4: Learn the typical test objectives

A test objective is the reason for testing. The syllabus lists these typical objectives, paraphrased here:

• Evaluate work products such as requirements, user stories, designs and code.
• Cause failures and find defects.
• Ensure the required coverage of a test object.
• Reduce the level of risk of inadequate software quality.
• Verify that specified requirements have been fulfilled.
• Verify compliance with contractual, legal and regulatory requirements.
• Provide information so stakeholders can make informed decisions.
• Build confidence in the quality of the test object.
• Validate that the test object is complete and works as stakeholders expect.

Two points the exam relies on:

1. Objectives vary with context. They depend on the work product, the test level, the risks, the development lifecycle and business factors such as time to market.
2. Note what is absent. No objective promises defect-free software. No objective involves fixing anything.

Do this: cover the list and recall it from memory. This is a K1 (remember) learning objective, so recognition is what gets tested.

Task 5: Separate testing from debugging

These are separate activities.

• Testing triggers failures (dynamic testing) or finds defects directly (static testing).
• Debugging finds the cause of a failure, analyses it and removes it.

When dynamic testing triggers a failure, debugging typically follows three steps:

1. Reproduce the failure.
2. Diagnose it by finding the defect that caused it.
3. Fix the cause.

Testing then resumes:

• Confirmation testing checks that the fix resolved the problem.
• Regression testing checks that the fix did not break something else.

Both get full treatment in a later level. For now, classify them as testing, not debugging.

When static testing finds a defect, there is nothing to reproduce or diagnose. The defect itself has been found, and it only needs removing.

Analogy: a smoke alarm sounding is the failure. The inspector who triggers and reports it is testing. The electrician who traces the faulty wire and replaces it is debugging.

What the exam asks about this

• Test objectives (K1): pick the typical objective from a list, or spot the option that is not one. Common distractors are "fix defects" and "prove there are no defects".
• Testing versus debugging (K2): a short scenario lists activities and you classify each one. Triggering a failure, reviewing, and confirmation testing are testing. Reproducing, diagnosing and fixing are debugging.
• Verification, validation, static, dynamic: these terms appear inside questions and options. Know them exactly.

Key takeaways

• Testing discovers defects and evaluates the quality of work products. It is more than running tests.
• The test object is the work product under test. It need not be code.
• Static testing does not execute the software. Dynamic testing does.
• Verification checks against specified requirements. Validation checks against stakeholder needs in real use.
• There are nine typical test objectives, and they vary with context.
• Testing triggers failures or finds defects. Debugging reproduces, diagnoses and fixes.