Test Case Design & Evidence Standards

Prerequisites

• STE-K001: What STE Is

Why This Lesson Matters

A test case is a procedure. A good test case is reproducible, unambiguous, and generates evidence that another evaluator could verify independently. Poorly designed test cases produce results that cannot be defended — a defence attorney (or a peer reviewer) can challenge a finding whose evidence is vague or whose procedure was inconsistent.

1. Anatomy of a Complete Test Case

Test Case ID:    TC-AC01-003
Control:         CSS-AC01 — Role-based access control
Test objective:  Verify that VIEWER role cannot create new users
Priority:        High (access control on sensitive admin function)

Preconditions:
  - Test account VIEWER-001 exists with role = VIEWER
  - Test account ADMIN-001 exists with role = ADMIN
  - Application accessible at https://staging.app.corp.local
  - Evaluator has captured the VIEWER-001 session token

Procedure:
  Step 1: Authenticate as VIEWER-001
  Step 2: Navigate to POST /api/users with body {"username":"testuser","role":"admin"}
  Step 3: Include VIEWER-001 session token in Authorization header
  Step 4: Record the HTTP response code and body

Expected result:
  HTTP 403 Forbidden
  Body: {"error": "Insufficient privileges"}

Actual result:       [fill during test]
Pass / Fail:         [fill during test]

Evidence to capture:
  - Screenshot of HTTP request (Burp Suite Repeater or equivalent)
  - Screenshot of HTTP response
  - Screenshot of VIEWER-001 account confirming role = VIEWER

2. Evidence Standards

Evidence must be:

Contemporaneous — captured at the time of the test, not reconstructed later.

Unambiguous — the screenshot must clearly show what you claim. A browser URL bar, the response code, and the response body must all be visible in the same screenshot.

Attributable — the evidence must be linked to a specific test account on a specific system at a specific time. Redact personal data but preserve forensic metadata.

Sufficient — one screenshot per claim. Three claims per finding = three screenshots minimum.

2.1 Screenshot Standards

Good screenshot:
  ✓ Shows the full browser or Burp window
  ✓ URL bar visible (confirms the target system)
  ✓ Request and response visible
  ✓ Timestamp visible (Burp logger or OS clock in taskbar)
  ✓ Response code clearly readable

Bad screenshot:
  ✗ Cropped to hide the URL
  ✗ Shows only part of the response
  ✗ No timestamp
  ✗ Blurry or low resolution

2.2 Request/Response Pairs

For web application STE, the minimum evidence for any HTTP-based finding is a captured request/response pair. Burp Suite's "Save item" produces a clean export:

=== REQUEST ===
POST /api/users HTTP/1.1
Host: staging.app.corp.local
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json

{"username":"testuser","role":"admin"}

=== RESPONSE ===
HTTP/1.1 403 Forbidden
Content-Type: application/json

{"error":"Insufficient privileges"}

This pair is self-contained evidence. Anyone reading the report can understand exactly what was sent and what was received.

3. Negative Testing: Beyond Happy Path

Most developers test that their system works correctly. Evaluators test that it fails correctly.

3.1 Boundary Testing

Control: Input fields shall accept a maximum of 255 characters.

Test cases:
  TC-IN01-001: Submit 254 characters → Expected: accepted
  TC-IN01-002: Submit 255 characters → Expected: accepted
  TC-IN01-003: Submit 256 characters → Expected: rejected
  TC-IN01-004: Submit 1000 characters → Expected: rejected
  TC-IN01-005: Submit 0 characters   → Expected: depends on requirement

Failure modes:
  If TC-IN01-003 crashes the application → buffer overflow or unhandled exception
  If TC-IN01-003 is silently truncated → data integrity issue
  If TC-IN01-003 is accepted → input validation failure

3.2 Error Handling Testing

Control: The application shall not reveal internal details in error messages.

Test cases:
  TC-ERR-001: Submit invalid SQL characters → Expected: generic error page
  TC-ERR-002: Request a non-existent page → Expected: generic 404
  TC-ERR-003: Submit malformed JSON → Expected: generic error, no stack trace

FAIL examples:
  "MySQL syntax error near '' at line 1" → reveals database type and query structure
  Java NullPointerException stack trace → reveals internal class paths
  "Could not connect to postgres://10.0.0.5:5432/finance_db" → reveals internal architecture

4. Evidence Chain: Traceability

Every piece of evidence must be traceable through the evaluation chain:

System requirement SR-042
    ↓
STE scope (SR-042 included in evaluation)
    ↓
Test case TC-AC01-003 (tests SR-042)
    ↓
Evidence EX-005 (screenshot of TC-AC01-003 execution)
    ↓
Finding F003 (SR-042 FAIL — access control bypassed)
    ↓
Report Section 6.3 (Finding F003 with EX-005 cited)

If any link in this chain is missing, the finding can be challenged. If a finding cannot be traced to a requirement, it should not be in an STE report (it may belong in a separate pentest report).

5. Common Mistakes

Mistake 1: Capturing evidence after the fact. "I found the issue but forgot to screenshot — I'll recreate it" is not acceptable. Recreated evidence is not contemporaneous. Re-run the test from the beginning and capture fresh evidence.

Mistake 2: Generic screenshots that could apply to any test. A screenshot showing "HTTP 403" with no URL, no account context, and no timestamp proves nothing specific.

Mistake 3: Only capturing the failure, not the baseline. If you claim a control fails for VIEWER but passes for ADMIN, you need screenshots of both. The ADMIN pass is as important as the VIEWER fail.

6. Practice Exercises

1. Write a complete test case for: "The application shall enforce session timeout after 30 minutes of inactivity." Include all fields from the anatomy template.

2. You are testing error message disclosure. The application returns: {"error": "select * from users where id=' UNION SELECT 1-- : syntax error"}. Write the evidence item description and FAIL justification.

3. Review this evidence statement: "Tested the admin panel and it worked." List five specific things that are missing that would make it acceptable STE evidence.

7. Lab

Assessment mode: quiz

You are given three incomplete test cases. Complete each with: preconditions, step-by-step procedure, expected result, and evidence requirements. Then identify the gaps in a provided evidence screenshot.

8. Framework Alignment

9. Further Reading

• NIST SP 800-53A Rev.5 — Assessment procedures are exactly the STE test cases in this lesson
• ISTQB Foundation Level Syllabus — General software testing foundations; boundary testing chapter is directly applicable
• OWASP Testing Guide — Evidence Collection — Practical screenshot and evidence standards

["Write a complete STE test case with all eight fields (ID, control, objective, priority, preconditions, procedure, expected result, evidence requirements) for a described authentication requirement", "Apply boundary testing to a described input validation control by writing four test cases that cover the boundary, below it, above it, and an extreme value", "Identify five specific deficiencies in a provided vague evidence statement and rewrite it to meet the four evidence standards (contemporaneous, unambiguous, attributable, sufficient)"]

Prerequisites → Why this matters → Complete test case anatomy (8-field template with example) → Evidence standards (4 properties, screenshot standards, request/response pairs) → Negative testing (boundary testing, error handling) → Evidence traceability chain → Common mistakes → Practice exercises → Quiz lab → Framework alignment → Further reading