Module 4 Assessment Overview
Congratulations on reaching the final lesson of Module 4. This assessment evaluates your understanding of all test documentation topics covered across 20 lessons.
The assessment has three parts:
- Knowledge Questions — 10 quiz questions in frontmatter (answer before reading)
- Scenario Questions — Apply documentation concepts to real-world situations
- Practical Exercise — Create a complete documentation suite
Scoring
- Part 1 (Quiz): 10 questions x 3 points = 30 points
- Part 2 (Scenarios): 5 scenarios x 6 points = 30 points
- Part 3 (Exercise): 40 points
- Total: 100 points. Passing score: 70
Topics Covered
| Area | Lessons | Key Concepts |
|---|---|---|
| Strategy and Planning | 4.1-4.2 | Test strategy, IEEE 829 test plan |
| Test Case Design | 4.3-4.5 | Writing test cases, positive/negative/boundary, test data |
| Defect Management | 4.6-4.10 | Bug reports, severity/priority, lifecycle, Jira, alternatives |
| Reporting | 4.11-4.13 | Execution reports, coverage reports, release notes |
| Process | 4.14-4.16 | Triage meetings, checklists vs cases, agile documentation |
| Advanced | 4.17-4.19 | Summary reports, RTM, templates and standards |
Part 2: Scenario Questions
Scenario 1: You join a new company as the only QA engineer. There is no test documentation at all. The product is a B2B SaaS platform with 50 enterprise customers. What documents do you create first, and in what order?
Scenario 2: Your team’s bug reports keep getting bounced back by developers with “Cannot Reproduce.” Bug fix cycle time has increased from 2 days to 7 days. What is wrong and how do you fix it?
Scenario 3: The CTO asks for a go/no-go recommendation for a release. You have: 88% pass rate (target 95%), 2 open major bugs, 45 open minor bugs, and the release deadline is tomorrow.
Scenario 4: A regulated healthcare client requires full traceability for their annual audit. Your team uses agile with no formal test plans. How do you satisfy both agile speed and compliance?
Scenario 5: You have 200 test cases for a feature, but the feature changes significantly every sprint. Maintenance is consuming 40% of QA time. What do you do?
Solution — Scenario 1
Priority order: 1) Bug report template (immediate value, used daily). 2) Test case checklist for critical features (payments, auth). 3) One-page test strategy. 4) Sprint test notes template. 5) Test summary report template. Start lightweight and expand. Do NOT try to create everything at once.Solution — Scenario 2
Root cause: Poor bug reports — missing environment info, vague steps, no evidence. Fix: 1) Create bug report template with required fields. 2) Train team on effective bug writing (the "developers love" format). 3) Add environment, exact steps, screenshots as mandatory fields in Jira. 4) Peer review bug reports for the first 2 weeks. 5) Track "Cannot Reproduce" rate as a quality metric.Solution — Scenario 3
Recommendation: **No-Go.** 88% pass rate is below the 95% target. 2 open major bugs represent significant risk. 45 minor bugs indicate broader quality issues. Propose: Fix 2 major bugs (estimate time), re-run failed tests, and provide a revised timeline. If business pressure is extreme, offer a Conditional Go with: hotfix plan for majors within 48 hours, monitoring for minor bug impact, and customer communication about known issues.Solution — Scenario 4
Hybrid approach: 1) Keep agile sprints and lightweight sprint notes. 2) Add RTM (Requirements Traceability Matrix) linking user stories to test cases. 3) Use Jira + Xray for automatic traceability (stories → test cases → executions → results). 4) Generate audit reports from tool data, not manual documents. 5) Add "traceability verified" to Definition of Done. The key insight: compliance does not require heavy documents — it requires traceable connections between requirements, tests, and results.Solution — Scenario 5
The 200 test cases are over-specified. Actions: 1) Convert to checklists for stable areas (reduce 200 to ~50 checklists + 30 detailed cases for critical paths). 2) Automate the stable happy paths (reduce manual maintenance). 3) Use acceptance criteria as test specs instead of separate detailed cases. 4) Delete obsolete test cases — they provide negative value when outdated. 5) Target: maintenance should consume < 15% of QA time. If a test case changes every sprint, it should be a checklist, not a detailed case.Part 3: Practical Exercise — Complete Documentation Suite
You are QA Lead for a new ride-sharing application launching in 3 months. Features: user registration, driver verification, ride booking, real-time GPS tracking, payment processing, ratings/reviews, push notifications, and an admin dashboard.
Create:
A (10 points): A one-page test strategy covering scope, approach, tools, environments, and risks.
B (10 points): Five test cases for the ride booking feature (mix of positive, negative, and boundary).
C (10 points): A bug report for this issue: “When a rider cancels a ride within the free cancellation window, they are still charged the cancellation fee.”
D (10 points): An RTM showing the mapping between 6 key requirements and their test cases (identify any gaps).
Exercise Solution
Part A — Test Strategy:
- Scope: All 8 features, iOS + Android + Web, 3 environments
- Approach: Risk-based. Critical: payment + GPS = 100% coverage. High: booking + verification = 80%. Medium: notifications + admin = checklists
- Tools: Playwright (web), Appium (mobile), k6 (performance), Postman (API)
- Environments: Dev (synthetic data), QA (masked production), Staging (production mirror)
- Risks: GPS accuracy in low-connectivity areas, payment gateway test mode limitations, driver verification document processing time
Part B — Test Cases:
- Positive: Book ride with valid pickup/dropoff, verify driver assignment within 5 minutes, trip starts and ends with correct fare
- Positive: Book scheduled ride 24 hours in advance, verify confirmation notification, ride appears in upcoming trips
- Negative: Book ride with pickup and dropoff at same location — error: “Pickup and destination must be different”
- Negative: Book ride when no drivers available within 10km — message: “No drivers available. Try again in a few minutes”
- Boundary: Book ride at maximum distance (100km) — verify fare calculation at upper limit is correct
Part C — Bug Report: Title: Rider charged cancellation fee when cancelling within free cancellation window (0-2 minutes) Environment: iOS 17.2, iPhone 15, Production Severity: S1 (Critical — incorrect financial charge) Priority: P1 (Immediate — active financial harm to users) Preconditions: Rider has active payment method, ride booked with driver assigned Steps: 1. Book a ride. 2. Note the booking confirmation time. 3. Cancel within 60 seconds. 4. Check payment history. Expected: No cancellation fee charged. Cancellation message: “Cancelled — no charge.” Actual: $5.00 cancellation fee charged. Payment history shows “Cancellation fee” line item. Evidence: [Screenshot of payment history showing charge] [Screenshot of cancellation policy showing 2-minute free window] Frequency: Always when cancelling within 0-2 minutes of booking.
Part D — RTM:
| Req | Requirement | Test Cases | Gap? |
|---|---|---|---|
| R1 | User registration | TC-REG-001 to 005 | No |
| R2 | Driver verification | TC-DRV-001 to 003 | Need document upload edge cases |
| R3 | Ride booking | TC-BOOK-001 to 005 | No |
| R4 | GPS tracking | — | Critical gap — no GPS test cases |
| R5 | Payment processing | TC-PAY-001 to 008 | No |
| R6 | Cancellation policy | TC-CAN-001 | Need more: partial refund, outside window |
Critical gap: R4 (GPS tracking) has zero test coverage. This is a core feature that requires immediate test case creation.
What is Next
Congratulations on completing Module 4: Test Documentation. You now have the skills to create every type of test documentation — from strategies and plans to bug reports and summary reports.
Module 5: Web Application Testing takes you from documentation into hands-on testing of web applications — HTML/CSS basics for testers, browser DevTools, cross-browser testing, form testing, authentication, and more.