Testing theory

Answer

Testing is the systematic investigation of a product and its related documentation to reveal defects, check expected behaviour, and give the team information about quality and risk. Its purpose is not to “prove everything works,” but to reduce uncertainty before a decision.

Examples

• For a money-transfer service, a successful payment is not enough: the team also needs evidence about repeated requests, bank declines, and network loss.

Practice exercises

1. Choose a familiar product and describe three decisions that testing evidence could support.

Answer

The number of data combinations, states, configurations, and execution paths quickly becomes impractically large. Testing is therefore a sample: we prioritise by risk, apply test-design techniques, and clearly communicate what remains untested.

Examples

• Even a ten-character field allows an enormous number of values; adding browsers, roles, and system states expands the test space further.

Practice exercises

1. For a sign-in form, list the dimensions of the test space and explain how you would reduce them deliberately.

Answer

Quality Assurance focuses on processes intended to prevent problems; Quality Control evaluates properties of the product that was built; testing is one way to perform that evaluation. Terminology varies by organisation, so agreed responsibilities and outcomes matter more than labels.

Examples

• Reviewing the Definition of Done is process prevention, while checking an implemented API contract is product control.

Practice exercises

1. Classify five team activities as defect prevention, product evaluation, or test execution.

Answer

Verification checks whether agreed requirements, designs, or contracts were implemented correctly. Validation asks whether the product solves the user’s real need. An implementation can match the specification exactly and still be inconvenient or useless.

Examples

• A form accepts exactly 20 characters as specified, but real customer identifiers contain 24 characters.

Practice exercises

1. For a checkout, give one verification and one validation example and identify who can provide the oracle.

Answer

Testing can reveal problems but cannot guarantee their absence; exhaustive coverage is unattainable; earlier feedback is cheaper; defects often cluster; repeating the same set loses effectiveness over time; and the approach depends on context. A product with no known defects may still fail its users.

Examples

• A stable regression suite stays green for years but does not cover a new mobile journey used by most customers.

Practice exercises

1. Choose two principles and describe a release decision that would change if the team applied them seriously.

Answer

Static testing analyses artefacts without executing application code: requirements, designs, schemas, code, or test scenarios. Dynamic testing observes the running system’s behaviour. The two approaches complement each other and reveal different classes of problems.

Examples

• An OpenAPI review finds inconsistent types before the service runs, while an API test shows the actual request handling at runtime.

Practice exercises

1. For a new feature, propose three static and three dynamic checks and explain the findings you expect.

Answer

Black-box checks focus on external behaviour without implementation knowledge. White-box testing uses code structure, branches, or internal flows. Grey-box testing combines an external scenario with partial knowledge of architecture or data. These are perspectives on a system, not separate test levels.

Examples

• A UI journey may be black-box, a unit test of calculation branches white-box, and an API check with database verification grey-box.

Practice exercises

1. For one checkout scenario, design one check from each perspective.

Answer

Component testing isolates a small unit; integration testing checks interactions among parts; system testing evaluates the complete system against requirements; acceptance testing assesses readiness to satisfy a business or user need. Boundaries depend on architecture and must be defined for the product.

Examples

• A tax calculation function, checkout-to-tax-service interaction, a complete purchase, and accounting acceptance represent different levels of one risk.

Practice exercises

1. Map one critical product risk to checks at all four levels without duplicating the same details.

Answer

Functional testing checks what the system does: rules, calculations, transitions, and outcomes. Non-functional testing investigates how it does so: performance, reliability, security, accessibility, compatibility, and other characteristics. One journey often needs both perspectives.

Examples

• Search returning the correct products is functional; staying within the latency budget under load is non-functional.

Practice exercises

1. For a file upload, define three functional and three non-functional risks.

Answer

Positive testing checks expected use with valid data. Negative testing explores invalid, unexpected, or forbidden conditions and whether the system handles them safely. Negative does not mean entering random bad values; each scenario should come from a specific risk.

Examples

• For a promo code, a positive test uses an active code within its rules; negative tests cover expiry, reuse, or a changed user role.

Practice exercises

1. Create three positive and five risk-based negative scenarios for password recovery.

Answer

A test basis is the set of sources from which we derive test conditions: requirements, contracts, models, risks, laws, or the observed behaviour of an earlier version. A test oracle is the means used to determine the expected result. It may come from a specification, business rule, reference system, calculation, or expert judgement, and its reliability must also be assessed.

Examples

• For a discount calculation, the loyalty-program rules form the test basis, while an independent calculation can serve as the oracle.

Practice exercises

1. For a familiar feature, list the available test basis, choose an oracle, and identify how that oracle could be wrong.

Answer

A practical lifecycle covers requirement and risk analysis, planning, test design, environment and data preparation, execution, defect work, retesting and regression, reporting, and closure. These are not necessarily linear phases: iterative development makes them overlap and repeat.

Examples

• While analysing a new refund workflow, the team also clarifies requirements, prepares API fixtures, and defines production monitoring signals.

Practice exercises

1. Draw the testing lifecycle for a small API change and mark the inputs, outputs, and owners of each activity.

Answer

A good requirement should be understandable, unambiguous, consistent, sufficiently complete, feasible, current, prioritised, traceable, and verifiable. A formal template does not help when the team cannot identify an observable outcome.

Examples

• “The page must load quickly” provides no oracle; “p95 below two seconds for 500 active users in the defined environment” can be tested.

Practice exercises

1. Take a vague requirement and rewrite it with conditions, an observable result, and explicit boundaries.

Answer

Smoke testing quickly checks whether a build is suitable for deeper testing. Sanity narrowly confirms an agreed area after a change. Retesting repeats the scenario of a specific defect. Regression looks for unintended effects in related behaviour. Teams use the labels differently, so scope must be explicit.

Examples

• After a discount fix, retesting repeats the failed calculation, regression covers tax and payment, while smoke first confirms that checkout opens at all.

Practice exercises

1. For one bug fix, define separate scopes for all four sets and explain which ones should be automated.

Answer

The team connects testing depth and order to the likelihood and impact of a problem while considering change complexity, defect history, data criticality, observability, and recovery cost. It is not a magic formula but a transparent way to discuss constraints.

Examples

• A small invoice-format change may carry high risk when many customers need that document for tax reporting.

Practice exercises

1. Build a risk matrix for three release changes and name one signal that would make you revise each assessment.

Answer

A checklist compactly captures test ideas and works well for an experienced team and a changing product. A detailed test case helps when repeatability, knowledge transfer, auditability, or complex data and expectations matter. Choose the format by the cost of ambiguity, not habit.

Examples

• A short list of browser risks may be a checklist, while a regulated financial flow with exact preconditions and expected results needs a test case.

Practice exercises

1. Represent one scenario as both a checklist and a test case; compare preparation time and interpretation risk.

Answer

A useful test case has a clear purpose, controlled preconditions and data, unambiguous actions, an observable expected result, and a link to a risk or requirement. It should be detailed enough for its audience without restating the obvious or hiding the oracle in long prose.

Examples

• “Test payment” does not define success; expectations for order state, charge, event, and retry behaviour make the check diagnostic.

Practice exercises

1. Edit a weak test case: remove incidental UI detail and add data, an oracle, and postconditions.

Answer

An error is a human mistake or incorrect decision; a defect is a flaw in an artefact or code; a failure is an observable deviation while the system runs; a root cause is an underlying condition that allowed the problem to occur or escape. One failure may have several causes, and a defect may remain dormant.

Examples

• A misunderstood rule produced a faulty condition in code; the failure appears only for one currency, while root causes include a vague requirement and missing review.

Practice exercises

1. For a known production incident, map error → defect → failure → contributing causes.

Answer

A report should let others understand, reproduce, and assess the problem: a factual summary, version and environment, preconditions and data, minimal steps, actual and expected results, reproducibility, impact, evidence, and related artefacts. Severity describes impact; priority describes urgency.

Examples

• Instead of “payment is broken,” a useful summary names condition, location, and outcome: “Repeated POST creates a second charge after response timeout.”

Practice exercises

1. Rewrite a vague bug report so another person can reproduce the problem without verbal context.

Answer

Severity estimates the scale and nature of a defect’s impact on the product, user, or data. Priority represents business repair order considering deadlines, reach, workarounds, and cost. High severity does not always mean first to fix, while a low-severity issue can be urgent in its business context.

Examples

• A rare crash in an admin tool may have high severity but lower priority; a homepage typo before a campaign can show the opposite pattern.

Practice exercises

1. Provide four high/low severity and priority combinations and justify each with context.

Answer

Traceability shows which requirements and risks are covered by checks, which results and defects relate to them, and where gaps remain. It does not have to be a large RTM spreadsheet: links may live in test management, an issue tracker, or code. What matters is being able to explain what was checked and which evidence supports it.

Examples

• A requirement → API test → CI run → defect chain shows not only that a test exists, but also its current result and a known problem.

Practice exercises

1. Build a minimal traceability map for three requirements and look for a requirement without a test or a test without a clear purpose.

Answer

A result depends not only on test steps but also on service versions, configuration, integrations, access, time, and data state. A controlled environment improves reproducibility, while representative data helps expose realistic risks. Test data must also comply with privacy and security rules.

Examples

• A refund test may pass against a stub but fail with the real payment sandbox because of a different timeout and webhook redelivery.

Practice exercises

1. For one integration test, list the dependencies, configurations, and data that must be controlled or recorded as evidence.

Answer

Entry criteria define when a test activity is ready to start; exit criteria define the evidence needed to finish it or make a decision; suspension criteria define when continuing would produce unreliable results or waste resources. They guide decisions rather than automatically guaranteeing quality.

Examples

• If the environment is unstable and half of the API requests fail because of infrastructure, a suspension criterion prevents the team from drawing false conclusions.

Practice exercises

1. Define entry, exit, and suspension criteria for a short regression cycle and name the owner of exceptions.

Answer

A defect lifecycle describes states and decisions from reporting to closure: triage, assignment, fixing, verification, reopening, deferral, or rejection. Exact labels vary by team. Clear transitions, ownership, and reasons for decisions matter more than having many statuses.

Examples

• After a defect is marked Fixed, verification confirms the original scenario but regression reveals a side effect; team policy determines whether to reopen it or report a separate defect.

Practice exercises

1. Draw a minimal defect workflow for your team and define who performs each transition and which evidence supports it.

Answer

A strategy connects quality goals and product risks to testing levels, types, and techniques. It defines scope and exclusions, environments, data, automation approach, roles, evidence, entry and exit criteria, reporting, and responses to findings. It is a decision model, not a document template for its own sake.

Examples

• For a payment feature, the strategy may place most contract checks at API level, retain a few critical UI journeys, and add production signals.

Practice exercises

1. Create a one-page strategy for a change with three major risks and explain what you will deliberately not test.

Answer

Release readiness is a decision based on evidence: coverage of critical risks, important defect status, test and review outcomes, environment stability, data quality, known limitations, observability, rollback, and ownership of risk acceptance. Pass rate is useful only with the context of the test set.

Examples

• A 99% green result may hide the one failed refund journey, while 90% with obsolete low-risk failures may not block release.

Practice exercises

1. Prepare a short release recommendation containing facts, uncertainty, residual risks, and an explicit decision owner.

Answer

A metric is useful when it supports a specific decision and has a clear denominator and context. Trends in escaped defects, feedback time, or coverage of defined risks may expose a problem. Counts of test cases, defects, or automation percentage without context easily become vanity metrics and encourage harmful behaviour.

Examples

• A growing test count proves little when the suite becomes slower, flakier, and still misses critical regressions.

Practice exercises

1. Choose three team metrics and document the decision, limitation, and possible gaming behaviour for each.