What testing is: terms and principles

Most testing interviews open with definitions: what testing is, the difference between an error and a failure, verification and validation. The questions look easy, so a vague or memorised answer stands out. This article explains each term in plain words, with small examples you can reuse. The terms follow the ISTQB Foundation Level syllabus, which many companies use as a shared vocabulary.

What testing is

Software testing is the set of activities that find defects (flaws, often called bugs) and judge the quality of a product. Running the app is only one part of it. Testing also covers reading requirements, planning, designing tests and reporting results.

Teams test to find defects before users do, to check that the product meets its requirements and fits what users really need, and to give managers facts for decisions such as "can we release?".

Testing and debugging are different jobs. Testing shows that something fails. Debugging, usually done by a developer, finds the cause in the code and fixes it. The tester then repeats the failed test on the new build (the new version of the software that the developers hand over). This is called confirmation testing, or retesting. The tester also checks that nothing else broke, which is called regression testing.

Error, defect and failure

These words describe one chain of cause and effect.

A person makes an error (a mistake): a developer misreads the discount rule. The error leaves a defect (also called a fault or a bug) in a work product (anything made during the project, such as code, a requirement or a design): the code now applies the discount to the wrong items. When that code runs, it may cause a failure, which is wrong behaviour someone can see: the customer is charged the wrong amount.

Not every defect causes a failure: code that never runs, or runs only with rare data, can hide a defect for years. The reason behind the error is the root cause, such as an unclear requirement or time pressure. Fixing it can prevent a whole group of future defects.

Verification and validation

Verification checks that the product meets its specified requirements (the written description of what it must do, also called the specification). A short way to remember it is "are we building the product right?". Validation checks that the product meets the real needs of its users in real use: "are we building the right product?".

Example: a banking app passes every test written from its specification, but branch staff find it cannot do a daily task that the specification never mentioned. Verification passed and validation failed. Acceptance testing with real users catches this.

Quality assurance and quality control

Quality control (QC) checks the product and finds defects in it. Testing is a major form of QC. Quality assurance (QA) improves the way the team works so that fewer defects are made in the first place. Suppose several bugs reach production and the team adds a rule that a tester reviews every user story (a short description of a feature) and its acceptance criteria (the conditions that must be true for the story to count as done) before coding. That rule is QA. Many job titles say "QA" for testing work, so say that you know the difference.

Static and dynamic testing

Static testing examines work products without running them. Reviews of requirements, stories, designs and code are static testing, and so are static analysis tools that read code and warn about problems. It can start before any code exists. Dynamic testing runs the software and watches for failures. Unit tests and exploratory testing in a browser are dynamic.

The seven testing principles

1. Testing shows the presence of defects, not their absence. Passing tests never prove that software is bug-free.
2. Exhaustive testing (testing every possible input and path) is impossible. A form with a few fields already has millions of input combinations, so we choose tests with techniques and risk.
3. Early testing saves time and money. A wrong requirement caught in a review costs minutes to fix. The same mistake found after release, in production (the live system that real users use), costs much more.
4. Defects cluster together. A few modules (separate parts of the application) usually hold most of the defects, so bug history shows where to test hardest.
5. Tests wear out. The same tests find fewer new bugs over time, so tests and test data need refreshing. Older material calls this the pesticide paradox.
6. Testing is context dependent. A banking app and a mobile game need different approaches.
7. Absence-of-defects fallacy. A product with few defects still fails if it does not do what users need.

Manual and automation testing

Manual testing uses a person's judgement and suits exploratory work, usability and features that still change. Automation runs scripted checks fast and often, which suits regression and smoke suites (groups of tests that re-check old features, or quickly check that a new build works at all; see test levels and test types). A script checks only what someone wrote down, so it supports testers and cannot replace them.

How to answer in an interview

Give the definition in one sentence, then a small example from real work. For "error, defect, failure", walk through the discount example above. For a sign-off question such as "all 600 tests passed, can you confirm there are no bugs?", name the principle and say what you would report instead: what was tested, what was not, and which defects are still open.

Common mistakes

• Saying "testing means finding bugs" and stopping. Mention quality information and risk too.
• Mixing up the chain, for example calling the wrong charge at checkout a defect. What the user sees is the failure.
• Using "QA" and "testing" as the same word without explaining the process side.

Recap

An error leads to a defect, which may cause a failure. Verification checks against the specification; validation checks against real user needs. QC checks the product and QA improves the process. Learn the seven principles with one example each.