Skill Hub — Decision & Validation

Test Scenario Derivation Working Skill

Convert approved requirements and acceptance criteria into concrete test scenarios so that testers, developers, and business owners know what must be verified before any code is written.

What this skill is for

Test scenarios are the bridge between "what the system must do" and "how we will prove it does it." This skill converts requirements and acceptance criteria into structured test scenarios that cover positive paths, negative paths, boundary conditions, and exploratory conditions. A test scenario is higher-level than a test case: it describes the condition to verify, not the exact click-by-click steps. The output is a Test Scenario Set that maps each scenario back to its requirement, classifies the test type, and identifies the data needed. This gives test planners coverage visibility and gives developers clarity on edge cases before they build.

When to use this skill

Acceptance criteria are approved and the test team needs to know what to verify.
A test plan is being created and coverage must be estimated before effort is committed.
Developers need to understand edge cases, error conditions, and boundary values before implementation.
Regression testing must be scoped and you need to know which scenarios are already covered by existing tests.
A new feature or change request needs verification, and no one has written down what to test.
An AI agent is generating test cases and needs a structured scenario list as input.

Real work situations

SAP credit management: positive, negative, and boundary

A requirement states: "Block sales orders when the customer exceeds their credit limit." The acceptance criteria specify a 50,000 EUR limit. The test scenarios must cover: positive (customer at 40,000 EUR with a 5,000 EUR order proceeds), negative (customer at 48,000 EUR with a 5,000 EUR order is blocked), boundary (customer at 49,999 EUR with a 2 EUR order is blocked, customer at 50,000 EUR with a 0 EUR order proceeds). Without these scenarios, testers verify only the happy path and the credit block fails in production for edge cases.

IDoc processing: error and retry scenarios

A requirement states: "Sales order IDocs from the e-commerce platform must process within 5 minutes." The test scenarios must cover: positive (standard IDoc with valid data processes in 2 minutes), negative (IDoc with invalid material number fails and posts to error queue), boundary (IDoc with 1,000 line items processes within 5 minutes), error (IDoc arrives during system maintenance and queues for retry), exploratory (two IDocs for the same customer arrive simultaneously and both process without collision). Without these scenarios, the integration goes live with untested error handling and duplicate order risks.

Master data migration: validation and reconciliation

A requirement states: "Migrate all active customers with matching account group and tax number." The test scenarios must cover: positive (active customer with complete data migrates successfully), negative (inactive customer is excluded), boundary (customer with missing tax number is rejected and logged), error (duplicate account group in target system is detected and flagged), exploratory (customer with special characters in the name is handled correctly). Without these scenarios, the migration loads incomplete data that blocks invoicing and requires manual cleanup.

Inputs required

Approved requirements with unique IDs and clear requirement statements.
Acceptance Criteria Set for each requirement, covering normal, boundary, and error cases.
System documentation showing transactions, fields, tables, and business objects involved.
Test data samples or production data extracts that represent normal and edge cases.
Business rules catalog showing decision logic, validation rules, and exception handling.
Existing test plan or regression test suite to avoid duplication (if available).
Non-functional requirements: performance thresholds, availability windows, and data volume limits.

Questions to ask

What is the positive path: given valid data and normal conditions, what must happen?
What is the boundary condition: the largest value, the smallest value, the edge of a range?
What happens when required data is missing, invalid, or formatted incorrectly?
What happens when the system is unavailable, under load, or in maintenance mode?
What happens when two users or two processes attempt the same action simultaneously?
What existing behavior must remain unchanged, and how do we verify it is not broken?
Which data combinations are dangerous or historically problematic?
What would a malicious or mistaken user do that the system must handle gracefully?

Working method

Read the requirement and acceptance criteria. Ensure the requirement is approved and the acceptance criteria are testable. If criteria are missing, stop and request them.
Identify the positive scenario. Define the normal case: valid data, standard conditions, expected outcome. This is the baseline scenario.
Identify boundary scenarios. Find the edges of valid input: maximum credit limit, minimum order value, longest material description, largest IDoc payload. Define the expected behavior at each boundary.
Identify negative and error scenarios. Define what happens with invalid data, missing fields, unauthorized access, system downtime, and concurrent actions. Expected behavior must include error messages, logging, and rollback.
Identify exploratory scenarios. Define unusual but realistic conditions: high volume, slow network, corrupted data, unexpected sequence of events. These are not always automated but must be considered.
Map each scenario to a requirement. Every scenario must link to at least one requirement ID and acceptance criterion ID. If a scenario does not map, it is orphan.
Classify test type. Label each scenario: positive, negative, boundary, exploratory, regression, or performance. This helps with coverage estimation and test planning.
Estimate coverage. Count scenarios per requirement. A healthy requirement has at least one positive, one negative, and one boundary scenario. Flag under-covered requirements.
Document in a Test Scenario Set. Use the template below. Include scenario ID, description, linked requirement, test type, preconditions, expected outcome, and test data needs.
Validate with stakeholders. Walk through the scenario set with the requirement owner and a tester. Confirm that the scenarios match intent and are executable.

Decision rules

If a requirement has no acceptance criteria, do not derive scenarios yet. Request criteria first.
If a scenario cannot be executed in the test environment, flag it and request environment or data changes.
If multiple scenarios test the same condition with the same data, consolidate them into one scenario.
If a scenario requires production data, require anonymization or synthetic data creation before testing.
If a scenario touches a critical business process, prioritize it for manual verification even if automation is planned.
If a scenario changes existing data, require a rollback plan or a dedicated test environment refresh.
If a scenario has no expected outcome defined, it is not a scenario. Define the outcome before adding it to the set.

Deliverables

Test Scenario Set — Per requirement or per feature. Contains scenario ID, description, linked requirement, test type, preconditions, expected outcome, and test data needs. See template below.
Coverage Matrix — Table showing requirements versus scenario types, with counts and gaps.
Test Data Requirements — List of data needed, source system, creation method, and anonymization requirements.

Templates

Test Scenario Set (compact)

---
artifact: Test Scenario Set
id: TS-001
requirement: Link to requirement
status: draft | reviewed | approved
---

## Scenario: Positive — Normal case
- ID: TS-001-POS
- Description: <What is being tested>
- Requirement: REQ-001
- Acceptance Criterion: AC-001-A
- Preconditions: <System state and data before test>
- Steps: <High-level actions, not click-by-click>
- Expected outcome: <What must be true after the test>
- Test data: <What data is needed and where to get it>
- Environment: <System and client>

## Scenario: Boundary — Edge of valid range
- ID: TS-001-BND
- Description: <What is being tested>
- Requirement: REQ-001
- Acceptance Criterion: AC-001-B
- Preconditions: <System state and data before test>
- Steps: <High-level actions>
- Expected outcome: <What must be true after the test>
- Test data: <What data is needed>
- Environment: <System and client>

## Scenario: Negative — Error or invalid input
- ID: TS-001-NEG
- Description: <What is being tested>
- Requirement: REQ-001
- Acceptance Criterion: AC-001-C
- Preconditions: <System state and data before test>
- Steps: <High-level actions>
- Expected outcome: <Error message, status, log entry, or block>
- Test data: <What data is needed>
- Environment: <System and client>

## Scenario: Exploratory — Unusual condition
- ID: TS-001-EXP
- Description: <What is being tested>
- Requirement: REQ-001
- Preconditions: <System state and data before test>
- Steps: <High-level actions>
- Expected outcome: <What must be true after the test>
- Test data: <What data is needed>
- Environment: <System and client>

## Coverage summary
- Positive: <count>
- Boundary: <count>
- Negative: <count>
- Exploratory: <count>
- Total: <count>
- Gaps: <list any missing scenario types>

Coverage Matrix (compact)

| Requirement | Positive | Boundary | Negative | Exploratory | Performance | Total | Gap |
|-------------|----------|----------|----------|-------------|-------------|-------|-----|
| REQ-001 | 1 | 1 | 1 | 1 | 0 | 4 | — |
| REQ-002 | 1 | 0 | 0 | 0 | 0 | 1 | missing boundary, negative |
| REQ-003 | 1 | 1 | 1 | 0 | 1 | 4 | — |

Quality checklist

Every approved requirement has at least one test scenario.
Scenarios cover positive, negative, and boundary cases for every requirement.
Each scenario links to a specific requirement ID and acceptance criterion ID.
Each scenario has a clear expected outcome, not just a description of the action.
Test data is identified with source, creation method, and anonymization requirements.
Scenarios are higher-level than test cases: they describe what to verify, not how to click.
The Coverage Matrix shows no under-covered requirements.
All scenarios are validated with the requirement owner and a tester before execution.

Common mistakes

Writing test cases instead of test scenarios. Consequence: the scenario set is too granular to give coverage overview. Test cases belong in the test tool; scenarios belong in the planning document.
Missing negative paths. Consequence: production failures on invalid data, missing permissions, or system errors that were never tested because only the happy path was considered.
Not linking scenarios to requirements. Consequence: orphan tests that cannot be traced to business value, and requirements that appear covered but are not.
Defining scenarios without expected outcomes. Consequence: testers do not know what constitutes pass or fail. The scenario is a task description, not a verification standard.
Deriving scenarios from vague requirements. Consequence: the scenarios test assumptions, not approved criteria. When the requirement is clarified, the scenarios are invalid.

Weak output vs Strong output

Weak output

A vague list of test ideas with no structure: "Test that the system works. Test with invalid data. Test with large orders. Test during downtime. Make sure everything is fast enough." No requirement links, no expected outcomes, no data specifications, no classification of test types.

Why it fails: Testers cannot plan effort. Developers cannot understand edge cases. Coverage is unmeasurable. The output is indistinguishable from a brainstorming session.

Strong output

---
artifact: Test Scenario Set
id: TS-S4-CREDIT-2026-001
requirement: REQ-101 — Credit limit block at 50k EUR
status: reviewed
---

## Scenario: Positive — Normal case
- ID: TS-101-POS
- Description: Customer with open orders below credit limit can create a new standard order.
- Requirement: REQ-101
- Acceptance Criterion: AC-101-A
- Preconditions: Customer C-10001 has credit limit 50,000 EUR and open order value 40,000 EUR.
- Steps: Create sales order VA01 for customer C-10001 with value 5,000 EUR.
- Expected outcome: Order creates with status "Open" and no credit block. Credit exposure updates to 45,000 EUR.
- Test data: Customer C-10001 in test client 300. Use material M-001 with price 5,000 EUR.
- Environment: S/4 Test Client 300.

## Scenario: Boundary — At the limit
- ID: TS-101-BND
- Description: Customer at exactly the credit limit can create a zero-value order.
- Requirement: REQ-101
- Acceptance Criterion: AC-101-B
- Preconditions: Customer C-10002 has credit limit 50,000 EUR and open order value 50,000 EUR.
- Steps: Create sales order VA01 for customer C-10002 with value 0 EUR.
- Expected outcome: Order creates with status "Open" and no credit block. Credit exposure remains 50,000 EUR.
- Test data: Customer C-10002 in test client 300.
- Environment: S/4 Test Client 300.

## Scenario: Negative — Exceeds limit
- ID: TS-101-NEG
- Description: Customer exceeding credit limit is blocked with correct status and routing.
- Requirement: REQ-101
- Acceptance Criterion: AC-101-C
- Preconditions: Customer C-10003 has credit limit 50,000 EUR and open order value 48,000 EUR.
- Steps: Create sales order VA01 for customer C-10003 with value 5,000 EUR.
- Expected outcome: Order is blocked with status "Credit block." Alert is sent to credit team. Order is visible in VKM1.
- Test data: Customer C-10003 in test client 300.
- Environment: S/4 Test Client 300.

## Coverage summary
- Positive: 1 | Boundary: 1 | Negative: 1 | Exploratory: 0
- Total: 3
- Gaps: Add exploratory scenario for concurrent order creation by same customer. Create TS-101-EXP by 2026-06-14.

Agent instructions

AI Prompt Pattern

Role: Test scenario designer for an SAP enterprise project.

Context: You have approved requirements with acceptance criteria. You need to create a Test Scenario Set that testers can use for planning and developers can use for understanding edge cases.

Task: Derive positive, negative, boundary, and exploratory scenarios from each requirement. Map each scenario to its requirement and acceptance criterion. Produce a Coverage Matrix.

Output format: Structured Test Scenario Set per requirement, followed by a Coverage Matrix table.

Never derive scenarios from a requirement without acceptance criteria. Request criteria first, then derive scenarios.
Always include at least one positive, one negative, and one boundary scenario per requirement. Exploratory scenarios are added where risk warrants.
Link every scenario to a requirement ID and an acceptance criterion ID. No orphan scenarios.
Write scenarios, not test cases. Describe what to verify and the expected outcome. Do not write click-by-click instructions.
Define expected outcomes precisely. Include system status, field values, error messages, or log entries.
Identify test data explicitly. State what data, in which system, and how to obtain or create it.
Do not invent requirements or acceptance criteria. Derive only from approved inputs. If gaps exist, flag them.
Link to Atlas diagnostics when scenarios touch SAP validation. For example, incompletion procedure scenarios should reference SAP Incompletion Procedure Diagnostics.

Related skills

Acceptance Criteria Working Skill — Use to produce the acceptance criteria that feed scenario derivation.
Requirements Elicitation Working Skill — Use to produce the requirements that scenarios must trace to.
Requirements Review Checklist Working Skill — Use to verify that requirements are ready before scenarios are derived.

Related Atlas pages

SAP Incompletion Procedure Diagnostics — Validation context for completeness scenarios in order-to-cash.
SAP Release Strategy Diagnostics — Approval workflow context for scenarios involving block and release.

Verification status and limitations

This skill is a public working interpretation of test scenario derivation practices. It is not official ISTQB, BABOK, or SAP documentation. It focuses on enterprise and SAP contexts where scenarios must be concrete enough for testers to plan and developers to understand edge cases.

Known limitations: the skill assumes requirements and acceptance criteria are already approved. It does not cover test automation scripting, performance testing tooling, or security penetration testing. It treats scenarios as planning artifacts, not executable test scripts. Non-functional scenarios may require specialized tools or environments that are not always available.