Test Design Tasks of the Test Analyst: A Complete ISTQB CTAL-TA Guide
Introduction
In the ISTQB Advanced Level Test Analyst (CTAL-TA) syllabus, the chapter on the Test Analyst in the test process covers what the Test Analyst does in each activity: analysis, design, implementation, execution and completion. Test design turns abstract test conditions (what to test) into test cases (how to test). Exam questions on this topic check whether you can tell design apart from analysis and implementation, and whether you know the key test design decisions.
1. Why Test Design Is Important
Test design matters for several reasons:
• It makes test conditions executable. Test conditions from analysis are not enough to run tests. Test design gives them inputs, expected results and coverage items.
• It drives efficiency. Good use of test techniques lets the Test Analyst cover more risk with fewer test cases. This avoids both redundant tests and gaps.
• It provides measurable coverage. Techniques define coverage items, such as equivalence partitions, boundary values, decision table columns and state transitions. These allow coverage to be measured and reported.
• It finds defects early. Designing test cases often exposes ambiguity, contradictions and missing information in the test basis. These are cheap to fix at this stage.
• It supports traceability and risk management. Test cases trace back to test conditions, requirements and risks. This helps impact analysis, prioritisation and reporting to stakeholders.
• It enables reuse and maintenance. Well-designed test cases can be reused for regression testing and automation.
2. What Test Design Is
The ISTQB defines test design as the activity that derives and specifies test cases from test conditions. During test design, the test conditions are elaborated into high-level (logical) test cases, sets of high-level test cases, and other testware.
The core question of design is 'How to test?'. This contrasts with test analysis ('What to test?') and test implementation ('Do we now have everything in place to run the tests?').
Main test design tasks of the Test Analyst
• Decide the level of detail. Determine which test areas need low-level (concrete) test cases and which need high-level (logical) test cases.
• Select test techniques. Choose techniques that achieve the required coverage. These may be black-box, experience-based or defect-based techniques, chosen according to risks, the test basis, constraints and objectives.
• Design and prioritise test cases. Create test cases and sets of test cases that exercise the identified test conditions. Prioritise them based on risk.
• Identify necessary test data. Specify test data requirements that support the test conditions and test cases.
• Design the test environment. Identify required infrastructure, tools and environment configuration.
• Define expected results. Use a test oracle, such as specifications, previous versions, a domain expert or a comparable system.
• Capture bidirectional traceability. Link the test basis, test conditions and test cases.
• Report test basis defects. Record ambiguities or defects found in the test basis.
• For experience-based testing, write test charters for exploratory sessions, or checklists, instead of fully scripted cases.
3. How It Works
3.1 Low-level (concrete) versus high-level (logical) test cases
This distinction is a favourite exam subject.
Low-level (concrete) test cases contain specific input values, specific expected results, detailed preconditions and step-by-step procedures.
• Advantages: They are reproducible and verifiable. They are suitable for inexperienced testers, regulatory or audit needs, and automation.
• Disadvantages: They are costly to write and maintain. They are brittle when the test basis changes. They may limit tester creativity. They need a detailed, stable test basis.
• When to use them: requirements are well defined, testers lack domain knowledge, external certification or audit is needed, or tests will be automated.
High-level (logical) test cases describe what to test without specific values. For example: 'verify that a premium customer receives the discount'.
• Advantages: They give better coverage variation from run to run. They are less maintenance-heavy. They can be written early, when requirements are still vague. They allow experienced testers flexibility.
• Disadvantages: Reproducibility and verifiability are lower. They depend on tester experience. Coverage is harder to audit.
• When to use them: requirements are poorly defined or changing, testers are experienced, and documentation must be lightweight (common in Agile).
High-level test cases may be designed first and later refined into concrete ones during implementation, once the detail becomes available.
3.2 Selecting test techniques
The Test Analyst picks techniques based on several factors:
• type of component or system and its complexity
• regulatory standards
• customer or contractual requirements
• risk levels and types
• available documentation (the test basis)
• tester knowledge and skills
• tools, time and budget
• SDLC model
• expected use and previous experience with the techniques
• types of defects expected
Typical choices include:
• equivalence partitioning and boundary value analysis for data ranges
• decision tables for combinations of business rules
• state transition testing for event-driven behaviour
• classification trees, pairwise or combinatorial testing for many parameters
• use case testing for end-to-end flows
• error guessing, checklists and exploratory testing to complement the systematic techniques
3.3 Contents of a well-designed test case
A test case typically includes:
• objective or purpose
• preconditions, such as environment, data and configuration
• test data requirements
• inputs or actions
• expected results, both outputs and state changes
• postconditions
• traceability to the test condition or requirement
• priority
Expected results must come from a test oracle. The Test Analyst should design test cases that are understandable to other testers and stakeholders, and that can be reviewed by developers and business representatives.
3.4 Considerations during design
• Design must be consistent with the test strategy and test plan, for example on the level of detail and documentation standards.
• Test cases should be reviewed, because test design defects cause missed defects or false failures.
• The degree of detail is influenced by the project context, risk, the SDLC model and test automation plans.
• In Agile, design is often done just in time, and it is linked to acceptance criteria, BDD scenarios and test charters.
3.5 Worked mini-example
• Test condition from analysis: 'Discount calculation for order totals.'
• Technique selected: equivalence partitioning plus boundary value analysis.
• Partitions: below 100 means no discount, 100 to 499.99 means 5%, and 500 or more means 10%.
• High-level test case: 'Verify that an order in the 5% band gets 5% discount.'
• Low-level test case: Input order total 100.00. Expected discount is 5.00 and the total payable is 95.00.
• Test data requirement: a registered customer with an empty basket.
• Traceability: REQ-DISC-03 links to TC-DISC-07.
4. Distinguishing Design From Neighbouring Activities
• Analysis answers WHAT. It covers analysing the test basis, identifying test conditions, prioritising them, and finding test basis defects.
• Design answers HOW. It covers test cases, techniques, coverage items, test data requirements, environment design and expected results.
• Implementation answers 'are we ready?'. It covers test procedures and scripts, test suites, execution schedules, actual test data creation, building or verifying the environment, and automation scripts.
• Execution covers running the tests, comparing actual results with expected results, logging, and reporting defects.
Exam Tips: Answering Questions on Test Design Tasks of the Test Analyst
Tip 1 – Match the activity to its keywords.
• 'Identify test conditions' is analysis.
• 'Design test cases, select techniques, define test data requirements, design environment' is design.
• 'Create test procedures, test suites, execution schedule, prepare test data, set up environment' is implementation.
Many distractors place an implementation task in a design question, or the reverse.
Tip 2 – Know the drivers for concrete versus logical test cases.
• Choose low-level/concrete for: inexperienced testers, regulatory or audit requirements, automation, and a detailed and stable test basis.
• Choose high-level/logical for: experienced testers, vague or changing requirements, early design, lower maintenance, and more variation.
Scenario questions usually hide one of these drivers in the text.
Tip 3 – Read the context clues.
Words such as 'safety-critical', 'regulator', 'external auditors', 'offshore team new to the domain' or 'to be automated' point to detailed test cases. Words such as 'Agile', 'evolving user stories', 'domain experts' or 'limited time' point to logical test cases or test charters.
Tip 4 – Expected results need an oracle.
If a question asks what is essential when designing a test case, expected results derived from an oracle are almost always part of the correct answer. Answers suggesting you determine expected results during execution are wrong.
Tip 5 – Technique selection is multi-factor.
Prefer answers that tie technique choice to risk, the test basis and objectives. Reject answers claiming one technique is always best, or that techniques depend only on tester preference.
Tip 6 – Traceability is a recurring correct answer.
Traceability from test basis to test conditions to test cases supports coverage measurement, impact analysis and auditing. It is a design-time responsibility of the Test Analyst.
Tip 7 – Watch the K-levels.
• K2 questions ask you to explain or distinguish, for example the advantages of logical test cases.
• K3/K4 questions present a scenario and ask you to choose or justify an approach. Eliminate options that contradict the scenario's constraints first.
Tip 8 – Defects in the test basis.
Defects can be found during design as well as analysis. Designing test cases often reveals missing or ambiguous requirements, and the Test Analyst should report them.
Tip 9 – Beware of absolute words.
Options containing 'always', 'never', 'only' or 'must in all cases' are usually wrong. The syllabus stresses context-dependent decisions.
Tip 10 – Experience-based design still counts as design.
Writing test charters, checklists and defect taxonomies for exploratory or checklist-based testing is a legitimate design output. Do not dismiss these answers as 'not design'.
Quick revision checklist
• Define test design: the 'how to test' activity that derives test cases from conditions.
• List the design tasks: level of detail, techniques, test cases and coverage items, test data requirements, environment and tools, expected results, traceability and prioritisation.
• Compare low-level and high-level test cases: advantages, disadvantages and when to use each.
• Name the factors influencing technique selection.
• Separate design from analysis and implementation.
Summary
Test design is where the Test Analyst's technical skill shows most clearly. It converts test conditions into effective, traceable and prioritised test cases using appropriate techniques and the right level of detail. In the exam, identify the activity from its keywords, spot the context drivers for detail and technique, and favour context-sensitive, risk-based and traceable answers over absolute ones.
