Test Case Design Working Skill

What this skill is for

Test case design converts test scenarios and requirements into executable instructions. A test case is more granular than a scenario: it specifies the exact steps, input data, expected results, and preconditions needed for a tester to perform the verification. This skill ensures that every requirement has at least one executable test case, that edge cases are documented, and that the resulting Test Case Document is clear enough for a business tester or QA analyst to run without asking the developer for clarification. The output is a Test Case Document that serves as the primary input for test execution, automation scripting, and audit evidence.

When to use this skill

• Test scenarios are approved and the test team needs executable instructions before execution begins.
• A new feature or change request has acceptance criteria, but no one has written the click-by-click steps to verify them.
• Automation engineers need structured cases to convert into automated scripts.
• Business testers need clear instructions for UAT that do not assume SAP transaction knowledge.
• Regression testing requires updated cases for existing functionality affected by a change.
• An audit or compliance review requires documented test evidence with traceability to requirements.

Real work situations

SAP credit block: executable steps for a business tester

A change request modifies the credit limit check in S/4HANA. The test scenario covers blocking a sales order when the credit limit is exceeded. The test case must specify: the exact transaction (VA01), the customer master data values, the order material and quantity, the expected credit block status, the error message number, and where to verify the result (VKM1). Without this detail, a business tester creates an order with the wrong customer and concludes the feature works when it has not actually been tested.

Integration IDoc retry: verifying error handling in WE02

A requirement states that failed IDocs must queue for retry and alert the monitoring team after three failures. The test case must specify: the partner profile, the message type, the invalid data to trigger failure, the WE02 status sequence, the expected retry intervals, and the alert recipient. Without this detail, the tester only checks that the IDoc fails and misses the retry logic and alert routing entirely.

Master data migration: validation of converted records in target

A data migration loads customer master records from a legacy system to SAP. The test case must specify: the source extract criteria, the expected count of migrated records, the transaction to verify (XD03), the fields to check (name, tax number, account group), and the reconciliation report to run. Without this detail, the tester does a spot check and misses records with truncated names or incorrect account groups.

Inputs required

• Approved Test Scenario Set with scenario IDs, descriptions, and linked requirement IDs.
• System documentation showing transactions, fields, tables, and messages relevant to the scenario.
• Test data specifications: customer accounts, material numbers, vendor codes, organizational units, and dates.
• Environment details: system, client, URL, user roles, and prerequisites (e.g., credit limit set to a specific value).
• Business rules and error message catalog so expected error messages can be stated precisely.
• Existing test cases for the same area (if available) to avoid duplication and ensure regression coverage.
• Traceability matrix or requirements list showing which requirements still lack test cases.

Questions to ask

• What transaction or screen does the tester open to start the test?
• What exact data values must be entered, and where does the tester find them?
• What is the system state before the test begins, and how is it verified?
• What is the exact expected result: field value, message number, status code, or log entry?
• Where does the tester verify the result: table, report, log, email, or downstream system?
• What happens if the precondition is not met, and how should the tester reset the environment?
• Which business rules could cause a different outcome, and how does the case account for them?
• Can a tester without developer knowledge execute this case, or does it require internal system access?

Working method

1. Select the scenario to case. Pick an approved test scenario. Verify that the scenario has a clear requirement link, test type, and expected outcome. If the scenario is vague, clarify it before writing cases.
2. Identify the entry point. Determine the transaction, screen, API endpoint, or URL where the tester begins. Record the exact navigation path.
3. Define preconditions. Document the required system state and data before the test starts. Include how to verify the precondition and how to reset if it is not met.
4. Write step-by-step actions. Number each action. Use imperative language: "Enter," "Select," "Click," "Navigate." Each step must be observable and unambiguous.
5. Specify input data. State exact values for every field: customer number, material code, quantity, date, amount. Reference test data sheets or creation instructions if data is dynamic.
6. Define expected results for each step. For every action, state what the system must show: field value, message text, status color, table entry, or report line. Include message numbers where possible.
7. Define postconditions and cleanup. State how the tester leaves the system: delete the test order, reset the credit limit, or log out. Cleanup prevents data pollution for subsequent tests.
8. Map the case to requirement and scenario. Every case must trace to at least one requirement ID and one scenario ID. If a case cannot be traced, it is an orphan and must be linked or removed.
9. Estimate execution effort. Assign a rough time estimate (e.g., 5 minutes, 30 minutes). This helps test planning and scheduling.
10. Review with a peer tester. Ask a tester who did not write the case to execute it from the document alone. Fix gaps, ambiguities, and missing data.
11. Store in the test management tool. Import or transcribe the case into the organization's test tool (ALM, Azure Test Plans, Jira Xray, or equivalent). Maintain the traceability links.

Decision rules

• If a scenario covers multiple paths, split it into one case per path. Do not combine positive and negative steps in one case.
• If a test case requires a system role or access the tester does not have, either change the case or request access before execution.
• If expected results depend on dynamic data (current date, exchange rate), state the rule for calculating the expected value rather than a fixed number.
• If a test case cannot be executed without another case having run first, document the dependency clearly and schedule them in order.
• If a case duplicates an existing case, reference the existing one and note the difference rather than rewriting it.
• If a requirement has no scenario, do not write a case. Derive the scenario first.
• If a test case takes longer than 60 minutes, split it into smaller cases or add a setup/cleanup sub-case.

Deliverables

• Test Case Document — Per feature or per release. Contains case ID, linked requirement and scenario, preconditions, steps, input data, expected results, postconditions, and effort estimate. See template below.
• Test Data Sheet — List of data values, source system, creation instructions, and anonymization status.
• Traceability Update — Updated matrix showing requirements mapped to test cases, with coverage counts and gaps.

Templates

Test Case Document (compact)

---
artifact: Test Case Document
id: TC-<feature>-<number>
scenario: TS-<id>
requirement: REQ-<id>
type: positive | negative | boundary | regression
status: draft | reviewed | ready
---

## TC-001 — Positive: Create standard sales order
- **Objective:** Verify that a standard sales order can be created for a valid customer with available credit.
- **Preconditions:**
  - Customer C-10001 exists in test client 300 with credit limit 50,000 EUR and open exposure 0 EUR.
  - Material M-001 exists with stock and price 5,000 EUR.
- **Steps:**
  1. Open transaction VA01. Select order type OR and sales organization 1000.
  2. Enter customer C-10001 in the Sold-to party field. Press Enter.
  3. Enter material M-001, quantity 1, and confirm the price is 5,000 EUR.
  4. Save the order.
- **Expected results:**
  - Step 2: Customer data copies into the order header without incompletion log.
  - Step 3: Price is 5,000 EUR. Availability check confirms stock is available.
  - Step 4: Order is saved with status "Open." Order number is displayed. Credit exposure updates to 5,000 EUR.
- **Postconditions / Cleanup:**
  - Delete the test order in VA02 or note the order number for batch cleanup.
  - Reset credit exposure if needed.
- **Test data:** Customer C-10001, Material M-001, Sales org 1000.
- **Environment:** S/4 Test Client 300.
- **Effort estimate:** 10 minutes.
- **Tester role:** Business tester with VA01 access.

## TC-002 — Negative: Credit block on exceeded limit
- **Objective:** Verify that a sales order is blocked when the customer exceeds the credit limit.
- **Preconditions:**
  - Customer C-10002 exists with credit limit 50,000 EUR and open exposure 48,000 EUR.
- **Steps:**
  1. Open VA01. Select order type OR and sales organization 1000.
  2. Enter customer C-10002.
  3. Enter material M-001, quantity 1, price 5,000 EUR.
  4. Save the order.
- **Expected results:**
  - Step 4: Order is blocked with status "Credit block." Message "Credit limit exceeded" appears. Order is listed in VKM1 with block reason.
- **Postconditions / Cleanup:** Release the block in VKM3 or delete the order.
- **Test data:** Customer C-10002, Material M-001.
- **Environment:** S/4 Test Client 300.
- **Effort estimate:** 10 minutes.
- **Tester role:** Business tester with VA01 and VKM1 access.

Quality checklist

• Every test case traces to a specific requirement ID and scenario ID.
• Every case has a clear, testable objective stated in one sentence.
• Preconditions are documented with verification steps and cleanup instructions.
• Steps are numbered, imperative, and unambiguous.
• Input data is exact or includes a rule for deriving the value.
• Expected results are specific: field values, message numbers, status codes, or report lines.
• A peer tester can execute the case from the document alone without asking the author.
• No case mixes positive and negative paths; each path is its own case.
• Postconditions and cleanup are defined so data does not pollute subsequent tests.
• Effort estimates are realistic and the total effort is calculable for planning.

Common mistakes

• Writing scenarios instead of cases. Consequence: testers lack the exact steps and data needed to execute. The document is a planning artifact, not an executable script.
• Missing expected results for every step. Consequence: testers do not know whether an intermediate screen is correct, and defects are discovered late or missed.
• Using placeholder data without instructions. Consequence: testers invent data that does not match the business rule, leading to false positives and false negatives.
• Combining multiple paths in one case. Consequence: when the case fails, the tester cannot tell which path failed, and root cause analysis takes longer.
• Skipping cleanup steps. Consequence: test data accumulates, credit limits are left altered, and subsequent tests fail due to polluted state.
• Assuming system knowledge. Consequence: a business tester or new QA analyst cannot execute the case, and execution is delayed while questions are answered.

Weak output vs Strong output

Weak output

A generic test instruction with no steps, no data, and no traceability: "Test the sales order creation. Make sure it works. Also test that the credit block happens. Check the IDoc retry logic. Verify the master data is correct." No requirement links, no transaction names, no input values, no expected results, no cleanup.

Why it fails: Testers cannot execute it. Coverage is unmeasurable. Automation engineers cannot script it. Auditors cannot verify it. It is a brainstorming note, not a test case document.

Strong output

---
artifact: Test Case Document
id: TC-S4-CREDIT-2026-001
scenario: TS-101
requirement: REQ-101
status: reviewed
---

## TC-001 — Positive: Standard order within credit limit
- **Objective:** Verify that a sales order for a customer within credit limit creates without block.
- **Preconditions:**
  - Customer C-10001 in client 300 has credit limit 50,000 EUR and exposure 0.
- **Steps:**
  1. Open VA01, select order type OR, sales org 1000.
  2. Enter customer C-10001. Press Enter.
  3. Enter material M-001, quantity 1. Confirm price 5,000 EUR.
  4. Save.
- **Expected results:**
  - Step 2: Header data copies, no incompletion log.
  - Step 3: Availability check confirms stock.
  - Step 4: Order saved with status "Open." Order number displayed. Exposure updates to 5,000 EUR.
- **Cleanup:** Delete order in VA02 or record number for cleanup job.
- **Test data:** C-10001, M-001, sales org 1000.
- **Environment:** S/4 Test Client 300.
- **Effort:** 10 min.

Agent instructions

AI Prompt Pattern

Role: Test case designer for an enterprise SAP project.

Context: You have approved test scenarios with requirement links and acceptance criteria. You need to produce a Test Case Document that testers can execute without asking the developer for help.

Task: For each scenario, write numbered steps, exact input data, specific expected results, preconditions, cleanup, and effort estimates. Map every case to a requirement and scenario.

Output format: Test Case Document in Markdown, one section per case, using the compact template.

• Never write a test case without a linked requirement and scenario. If the link is missing, flag it and stop.
• Always specify exact transactions, fields, and values. Use placeholder text only when the value is genuinely dynamic, and state the derivation rule.
• Define expected results for every step, not only the final outcome. Include message numbers, status codes, and field values.
• Include cleanup steps. Do not leave the test environment in an altered state.
• Write cases a business tester can execute. Avoid steps that require debugging, custom code, or developer access.
• Do not invent requirements, scenarios, or system behavior. Derive only from approved inputs. If a scenario is unclear, request clarification rather than guessing.
• Link to Atlas diagnostics when cases touch SAP validation logic. For example, credit block cases should reference SAP Credit Management Diagnostics for message numbers and status paths.

Related skills

• Test Scenario Derivation — Scenarios are the input; this skill converts them into executable cases.
• Regression Test Planning — Uses test cases to decide what to retest and in what order.
• Test Evidence Review — Reviews the results after cases are executed.
• Acceptance Criteria — Provides the criteria that test cases must verify.

Related Atlas pages

• SAP Credit Management Diagnostics — Context for credit block test cases and status verification.
• SAP Incompletion Procedure Diagnostics — Validation context for completeness checks in order-to-cash cases.
• SAP IDoc Status Diagnostics — Reference for IDoc retry and error handling test cases.

Verification status and limitations

This skill is a public working interpretation of test case design practices. It is not official ISTQB, BABOK, or SAP documentation. It focuses on enterprise contexts where test cases must be executable by testers who are not developers and where traceability to requirements is required for audit and compliance.

Known limitations: the skill does not cover test automation scripting languages, performance test tool configuration, or security penetration testing. It assumes test scenarios already exist. It does not address exploratory testing without predefined scenarios. Some organizations use ALM tools with custom fields that may require additional metadata beyond the template provided.