TechSoft
Playbook menu: Testing

Delivery Playbook · Craft

Testing

The kinds of testing we do, who does each, and how defects are reported and closed.

Owner: CTO · Last reviewed: · Next review: 28 April 2027

Testing is how we prove that the software works before it reaches your users. We test in layers, and each layer has an owner, so nothing depends on one person remembering to check.

The layers

TestWho owns itPurpose
UnitDevelopersCheck the smallest parts while the story is being built. Acceptance criteria are covered by unit tests
Component and functionalQCCheck each function against its requirements
Smoke and sanityQCCheck that a new build is stable enough to test further
Integration (end to end)QCCheck that the parts work together across the whole flow
Data validityQCCheck that data is correct and stays correct
RegressionQCCheck that new work has not broken what already worked
AcceptanceQC with the customer's stakeholdersConfirm the solution is correct before release

Testing often starts by hand and moves to automation as scenarios stabilize. Automation is added where a check will be repeated many times, such as regression.

When testing counts as finished

Each layer has an exit rule. For example, regression and acceptance testing finish when no top-priority or high-priority defects remain open, and lower-priority defects are written down.

How a defect is reported

  • A summary of the exact problem
  • Exact steps to reproduce it
  • What happened and what was expected
  • A screenshot or video, and the version where it was found
  • A severity set by the reporter. Priority is set by the Delivery Manager or product owner

A fixed defect goes to code review, then to retesting. It is closed only when the tester confirms the fix and the surrounding area still works.

Testing AI-written code

AI can write tests quickly, and it can write tests that pass for the wrong reason. We therefore check that AI-written tests fail when the code is deliberately made wrong.

Related