Test Analysis
Test analysis is the test activity that answers "what to test?". The tester studies the test basis — user stories, acceptance criteria, business rules, designs, API contracts — and turns it into test conditions. ISTQB defines a test condition as a testable aspect of a component or system identified as a basis for testing. Each condition is traced to its source and given a priority.
For example, "An expired promo code shows an error and the total does not change" gives two conditions: an expired code is rejected, and the total stays the same. It also raises a question the story does not answer: is a code valid on its expiry date, and in which time zone? Finding that gap is part of analysis too.
Why it matters
A test you design later can only cover what you decided to test. A rule that never becomes a test condition gets no test case, and nobody notices until a customer does. Analysis makes the scope of testing visible while it is still a short list the team can review.
It is also one of the earliest chances to find defects. A contradictory or missing requirement found now is fixed by editing a sentence; found after coding, it needs a code change and a retest, or it reaches customers first. For the tester, analysis is where you learn the product and earn trust by asking the questions nobody else asked.
What to test, not how to test
In the ISTQB test process, test analysis comes after test planning and before test design. The test plan from the previous lesson sets scope, approach and risk levels; analysis decides exactly what to test within that scope. Test design, the next lesson, then answers "how to test?" by turning each condition into test cases.
These are logical activities, not strict phases. The STLC model calls this work requirement analysis, and many teams start it as soon as a story is ready for refinement.
- In: the test basis for the features in scope, plus the risks and approach from the test plan.
- Out: prioritised test conditions traced to their sources. Good acceptance criteria can serve as test conditions directly.
- Out: defect reports about the test basis itself, when a defect is not fixed on the spot.
- Not yet: steps, concrete data and expected screens, which belong to test design.
- 1Test basisScope and risk levels from the test planUser stories, acceptance criteria, business rules, designs, API contracts
- 2Evaluate the basisAmbiguity, omission, contradiction, untestable wording
Branch: Defect in the basis → question or defect report to the product owner
- 3Identify test conditionsOne testable aspect each, with an id and its source
- 4Prioritise by riskLikelihood × impact → High, Medium or Low, with a reason
- 5Prioritised test conditionsThe answer to "what to test?"Output
Back to step 1 Each answer updates the basis; re-analyse what changed
Then:Into test design: how to test each condition
Simplified: in practice the steps overlap, and analysis repeats for every story and every change to the basis.
Evaluate the test basis and report its defects
Read the test basis critically before deriving anything: ISTQB asks testers to evaluate it for defects and for testability. A requirement is a work product like code, so its author's errors become defects in the requirement and, if nobody catches them, can end up as failures in the product.
Record each finding where the team will act on it: a comment on the story, a question in refinement or a defect report. Never quietly guess the answer; a guess becomes an expected result nobody agreed to. Typical defects:
- Ambiguity: "10% off your order" — off the items only, or off the delivery fee as well?
- Omission: the story covers an expired code but not an unknown or mistyped one.
- Contradiction: one criterion allows one code per order; a pricing rule lets loyalty members add a second.
- Untestable wording: "shown clearly", "fast", "user-friendly", "as appropriate" — nothing to compare a result against.
Try it: AI Requirement Ambiguity Detector Try it: AI Requirement Gap Analyzer
Identify test conditions
A test condition names one testable aspect: a rule, a behaviour, a state, an error path or a quality characteristic. Write what must be true, not steps: "the discount is calculated before VAT" is a condition; "type SAVE10 and press Apply" is a test step that belongs to design. Some teams write conditions as test ideas or one-line test scenarios, although a scenario often combines several conditions. Work through the basis systematically so you do not stop at the happy path:
- Each acceptance criterion and business rule: at least one condition, often a positive and a negative one.
- Each input, state and role: valid and invalid values, success and failure, who may act and who must not.
- Implicit needs: error messages, Arabic and right-to-left layouts, accessibility, performance.
- An id and a source for every condition (AC2, BR-9 or "implicit"), so coverage can be traced later.
Try it: User Story → Test Scenarios Try it: Requirements → Test Scenarios
Prioritise the conditions by risk
Not every condition deserves the same effort, and ISTQB places prioritising test conditions, with their risk levels, inside test analysis. A simple start is likelihood × impact: how likely is a defect here, given complexity and recent change, and how bad would a failure be for users or the business? Rate each condition High, Medium or Low with a one-line reason.
Priority sets the order of design and execution and the depth of testing: a High price calculation gets several techniques, a Low label check one test. Keep low-priority conditions on the list even if you decide not to test them: a visible decision is an accepted risk, an invisible one is a gap.
Worked example: a promo code story
An online shop plans story US-214 for the next sprint, and the test plan rates checkout pricing as high risk. The block below shows the test basis and the analysis result: four questions sent to the product owner before any test existed, and eight prioritised conditions.
C1 to C5 are High because they decide the amount the customer pays, which the test plan rates as high risk: a defect there charges customers the wrong amount. C4, C5 and C7 cannot be designed until the product owner answers, which is exactly why the questions are raised now.
US-214 Apply a promo code at checkout
AC1 A valid code reduces the order subtotal by its percentage.
AC2 An expired code shows an error and the total does not change.
AC3 Only one code can be used per order.
AC4 The discount is shown clearly on the order summary.
BR-9 Discounts apply to the subtotal before VAT.
Items already on sale get no further discount.
Loyalty members may add their member code to a promo code.
Questions for the product owner (comments on US-214)
Q1 Contradiction AC3: one code per order; BR-9: loyalty members may add a second.
Q2 Untestable AC4 "clearly": what exactly must the summary show?
Q3 Ambiguity AC2: is a code valid on its expiry date, and in which time zone?
Q4 Omission BR-9: what happens to a cart with both sale and regular items?
Test conditions
C1 AC1 High A valid code reduces the subtotal by its percentage.
C2 BR-9 High The discount is calculated before VAT.
C3 AC2 High An expired code is rejected and the total does not change.
C4 AC3, BR-9 High A second code on the same order (blocked until Q1 is answered).
C5 BR-9 High Sale items get no discount, also in a mixed cart (waits for Q4).
C6 implicit Medium An unknown or mistyped code shows an error.
C7 AC4 Medium The summary shows the code and the discount amount (after Q2).
C8 implicit Medium The code field and the summary work in the Arabic interface.Common mistakes
- Jumping straight to test cases with steps and data, so nobody can see what was left out.
- Treating the test basis as correct and quietly guessing what an unclear requirement means.
- Deriving conditions only from the happy path, forgetting error paths, roles and implicit needs.
- Writing conditions that are too vague ("test promo codes"), too detailed, or without a source.
- Giving every condition the same priority, or prioritising without recording why.
- Keeping findings in a chat or in your head, so the answers never reach the story.
The QA perspective
On a real team, test analysis starts when a story is ready for refinement, not when the build arrives. Many teams do part of it in a short "three amigos" conversation between the product owner, a developer and a tester. Bring draft conditions and questions: "What happens when…?", "Which rule wins if these two conflict?", "How will we know this is done?"
Record conditions with source and priority where the team works: the test management tool, the story or a shared sheet. When an answer arrives, make sure it is written into the story, because it is now part of the test basis. Scale the effort to the risk: a pricing change deserves a full list, a label change three lines.
Practice exercise
Analyse a clinic booking story
A clinic is adding online booking to its patient app. The story below is the test basis; the test plan rates double booking and patient privacy as high risk. Perform test analysis only, no test cases: list your questions for the product owner and the prioritised test conditions with their sources.
US-57 Book a clinic appointment online
As a patient, I want to book an appointment with a doctor online
so that I do not have to call the clinic.
AC1 The patient chooses a doctor, a date and a free 20-minute slot.
AC2 Appointments can be booked up to 30 days ahead.
AC3 A patient cannot have two appointments at the same time.
AC4 The patient receives a confirmation quickly.
AC5 Appointments can be cancelled up to 24 hours before the start.- Mark what is ambiguous, missing, contradictory or untestable, and turn each finding into a question for the product owner.
- List the conditions with their sources: at least one per criterion, plus the implicit ones.
- Rate each condition High, Medium or Low with a one-line reason.
Show the model answer
Questions: AC4 "quickly" is untestable — within how many minutes, by which channel, in which language? AC2: are 30 days counted from today or from now, and is day 30 included? AC5: what happens inside the last 24 hours? And what if two patients choose the same slot at the same moment?
Conditions: C1 (AC1) a free slot can be booked; C2 (AC1) a taken slot cannot, even when two patients choose it at once; C3 (AC2) the 30-day limit is enforced; C4 (AC3) a second appointment at the same time is rejected, even with another doctor; C5 (AC4) a confirmation is sent; C6 (AC5) an early cancellation frees the slot; C7 (AC5) a late cancellation follows the answer you receive; C8 (implicit) patients cannot see or cancel each other's appointments; C9 (implicit) the pages work in Arabic.
Priorities: High for C1, C2, C4 and C8, where a failure blocks booking, double-books a doctor or a patient, or exposes patient data; Medium for the rest, where a failure is inconvenient but does none of these, and C5 and C7 also wait for answers. Check yourself: every condition has a source, every unclear statement became a question, and the list has no steps or concrete dates yet.
Frequently asked questions
What is the difference between a test condition and a test case?
A test condition says what to test: "an expired code is rejected". A test case says how: preconditions, inputs such as a code that expired yesterday, steps and the expected result. One condition usually leads to several test cases in test design, and one test case can cover more than one condition.
Is test analysis the same as requirement analysis in the STLC?
Largely, yes, but the order differs. The STLC model calls its first phase requirement analysis and puts it before test planning; the ISTQB test process calls the same work test analysis, places it after planning and notes that its activities are often carried out iteratively or in parallel. ISO/IEC/IEEE 29119-2 covers it in the first steps of its test design and implementation process: identifying feature sets and deriving test conditions. In practice planning and analysis feed each other, and analysis repeats for each story, release and test level, and whenever the basis changes.
Should a problem in a requirement be reported as a defect?
It is a defect in a work product, and ISTQB lists defect reports about the test basis among the work products of test analysis when the defect is not fixed directly. Many teams record it as a question or comment on the story instead. The format matters less than the result: it is visible, someone owns it, and the answer is written back into the basis.
What if there are no written requirements?
Then the test basis is whatever you can find: conversations, the current system's behaviour, user documentation, similar products, support tickets. Write down the conditions you derive and the assumptions behind them, and ask the product owner to confirm them. Your list is often the first written record of what the feature should do.
References
- ISTQB Certified Tester Foundation Level (CTFL) v4.0The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
- ISTQB GlossaryThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
- ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesThe test process model: organisational, test management and dynamic test processes, with their activities and outcomes.
Practise with Mutqan tools
Derive test scenarios from functional requirements with coverage mapping.
Derive end-to-end test scenarios from a user story, including alternate and exception flows.
Score features by likelihood and impact, then generate a prioritised risk-based test plan.
Detect ambiguous, vague or contradictory statements in requirements and get clarifying questions from Mutqan AI.
Find missing requirements — error handling, permissions, edge conditions, non-functional needs — with Mutqan AI.
Go deeper
Your progress on this topic
Not started
Mark the topic complete when you have studied it and done the exercise.
Sign in to track your progress
Mark topics complete, continue where you left off and unlock specialisation exams.