Test documentation

plans, cases, checklists, reports

What is a test plan and what is in it?

A document that describes what, how, when and by whom we test. Typical sections:

Scope: what we test and what we do not test.
Approach: test levels and kinds, manual or automated.
Environments, test data, tools.
Entry and exit criteria (when we start, when it is ready for release).
Risks and the plan of action for them.
Roles, schedule, artefacts.

In Agile a test plan is often shorter and alive: a page in Confluence for a release or a feature.

In an interview: A test plan describes what we test and what we don't, with what approach, on which environments and with which data, the entry and exit criteria, risks and roles. In Agile I keep it short and alive, for example a page in Confluence per release.

How does a test strategy differ from a test plan?

A strategy is the general approach to testing at the product or company level, and it changes rarely: which test levels, what we automate, which environments, standards, metrics.

A plan is the concrete application of the strategy to a project, a release or a feature: scope, schedule, people, risks.

In an interview: A strategy is the general approach to testing at the product level, and it rarely changes. A plan is the concrete application of the strategy to a release or a feature, with dates, people and scope.

What does a good test case consist of?

An ID and a clear title: what we check.
Preconditions: system state, user, data.
Steps: short, one action each.
The expected result: specific and verifiable.
Priority, link to a requirement, type (positive or negative).

The quality criterion: another tester will go through the case without questions and will assess the result the same way. One case, one check.

ID:        TC-PAY-014
Title:     A transfer that exactly exhausts the daily limit
Preconditions: The user is logged in, the daily limit is 10,000 UAH,
            9,000 UAH has already been transferred today, the balance is 5,000 UAH
Steps:
  1. Open "Transfer to card"
  2. Enter a valid recipient card number
  3. Enter the amount 1,000.00
  4. Confirm the transfer
Expected:  The transfer succeeds; the remaining limit is 0.00;
           the balance is 4,000.00 minus the fee per the tariff
Priority:  High   Requirement: REQ-LIM-03

In an interview: A good test case has a clear title, preconditions, short steps and a specific expected result, plus a priority and a link to a requirement. My criterion: another tester must be able to go through it without questions and assess the result the same way.

When test cases and when checklists?

A checklist is a list of checks without detailed steps. Quick to write and maintain, it fits an experienced team, smoke, exploratory, and stable simple parts.

A test case is a detailed scenario. It is needed for complex logic, new people on the team, regulatory requirements and scenarios that will later be automated.

In an interview: Checklists are faster, and I use them for smoke, exploratory sessions and stable simple parts. I write detailed test cases for complex business logic, for scenarios that will be automated, and where audit traceability is needed, as in fintech.

What is a traceability matrix?

A table of links "requirement → test cases → results → defects". It shows whether every requirement is covered by tests, what broke and which requirements a change will affect.

In Jira this is often done with links between stories, test cases (Zephyr, Xray) and bugs.

In an interview: A traceability matrix links requirements to test cases, results and defects. It shows that every requirement is covered and helps assess the impact of changes. In Jira I do this with links between stories, cases in Zephyr and bugs.

What should be in a test report?

What was tested: scope, build, environment, period.
Results: passed, failed, blocked, not executed.
Open defects by severity, especially blockers and critical ones.
Risks and what wasn't tested and why.
A recommendation: ready for release or not, with conditions.

A report is written for the people who make decisions, so the main thing is the conclusion and the risks, not tables of numbers.

In an interview: In a report I show what was tested and on which build, the execution results, open defects by severity, risks and what wasn't tested. And always a clear recommendation on the release, because the report is read by the people who make decisions.

How do you prepare test data?

Cover the classes: valid, invalid, boundary, empty, special characters.
Have different types of users: new, with history, blocked, with different roles and tariffs.
Create data through the API or SQL, not manually through the UI: faster and reproducible.
Don't use real personal data, only anonymised or generated.
Document where it lives and how to restore it.

In an interview: I prepare data for equivalence classes and boundaries, with different types of users. I create it through the API or SQL, so it is fast and reproducible, and I never use real personal data, only generated or anonymised.

Test case vs checklist

A test case is a detailed scenario: preconditions, steps, test data and the expected result for each step. A checklist is a short list of what to check, without a step-by-step description. A test case is reproducible by anyone, even a newcomer who doesn't know the product.

A checklist is quicker to write and maintain, but the result depends on the executor's experience. I choose test cases for critical functionality, complex business logic, regulatory requirements and as a basis for automation. Checklists are for smoke, stable parts of the product, exploratory sessions and when requirements change often.

In practice they are often combined: a checklist for broad coverage, test cases for key flows. The main criterion is the balance between the cost of documentation and the risk of missing a defect.

A quality test case

The basic structure: ID, title, preconditions, steps, test data, expected result, priority and a link to a requirement. The title must be short and describe exactly what we check, for example "Login with a wrong password shows an error". Each test case checks one thing, so that when it fails it is immediately clear what broke.

Steps are atomic and concrete: not "enter data" but "enter the value test@mail.com in the Email field". The expected result is measurable and unambiguous, without words like "works correctly". A test case must be independent of others and not depend on the order of execution.

A good test case is also easy to maintain: without unnecessary UI details that change often. And it must be traceable to a requirement, so that coverage is visible.