Welcome
Testing the Grant Management System
You are going to test a real system — a grant application and approval system — just like a professional tester would. This page explains what you are doing, in what order, and why.
What is software testing?
Testing is how we find out whether a system actually does what it is supposed to do — and whether it is safe, accessible, and ready for real users. A tester does not just check if things work. They deliberately try to break things, push boundaries, and ask "what if?"
Good testing finds problems before real users do. Every bug you find today is a problem that will not reach a live system.
Your two tools today
📚
Tool 1 — This page
Learn the testing concepts
Use the group tabs above to find your group's testing type. You will learn what your testing type means, write test scenarios, complete and fix existing ones, and make pass/fail verdicts on described outcomes.
No live system needed for this part. It is paper-based practice to build your testing skills.
No live system needed for this part. It is paper-based practice to build your testing skills.
💻
Tool 2 — The live system
Run real tests
The grant management system is a real working application. You will log in as an applicant or caseworker and run guided test scenarios — submitting applications, making decisions, and checking that notifications arrive correctly.
This is where you actually test something real.
This is where you actually test something real.
What to do and when
1
Find your group and read your testing type (~5 mins)
Your teacher will assign you to Group A, B, C, D, or E. Click your group tab above. Read the overview card to understand what type of testing your group covers and why it matters.
2
Complete your group's four stages (~20 mins)
Work through Pre-test setup → Test scenarios → Pass/Fail verdicts → Debrief using the tabs in your group pack. For each stage, discuss with your group before writing your answers.
Pre-test setup
Test scenarios
Pass / Fail
Debrief
3
Test the live system in pairs (~20 mins)
Open the test scenario pack (your teacher will share the link). Work in pairs — one person plays the applicant, the other plays the caseworker. Follow each scenario step by step, record your verdict, and note what you actually observed.
Test environment notes: The password for all accounts is test1234. Verification codes appear on screen instead of arriving by email — this is intentional and shows you how test environments differ from live ones.
4
Present back to the class (~3 mins per group)
Use the Debrief tab in your group pack to guide your presentation. Cover: what your testing type is, which test outcomes were Pass/Fail/Blocked, what you found on the live system, and one thing that surprised you.
Which group does what
| Group | Testing type | The big question | Live system? |
|---|---|---|---|
| A | Functional & Integration | Does it work? Do the parts talk to each other? | ✓ Yes |
| B | Accessibility & Usability | Can everyone use it? Is it easy to navigate? | Concepts only |
| C | Performance & Security | Does it handle pressure? Is data safe? | ✓ Yes (security) |
| D | Operational Readiness | Are the teams ready? Is support in place? | Concepts only |
| E | Regression | When something changes, what else breaks? | ✓ Yes |
Welcome
Testing the Grant Management System
You are going to test a real working system — just like a professional tester would. This page explains what you are doing, in what order, and why.
What is software testing?
Testing finds out whether a system actually does what it is supposed to do — and whether it is safe, accessible, and ready for real users. A tester does not just check if things work. They deliberately try to break things, push boundaries, and ask "what if?"
Good testing finds problems before real users do. Every defect you find today is a problem that will not reach a live system.
Your two tools today
📚 Tool 1 — This page
Learn the testing concepts
Your group works through four stages: pre-test setup, writing scenarios, making pass/fail verdicts, and preparing a debrief. No live system needed for this part.
💻 Tool 2 — The live system
Run real tests against a working application
The grant management system is a real application. You log in, run guided test scenarios, and record what you find. This is where you test something real.
What to do and when
1
Find your group and read your testing type (5 mins)
Your teacher will assign you to Group A, B, C, D, or E. Click your group tab in the header above. Read the overview to understand what your testing type covers.
2
Complete your group's four stages (20 mins)
Work through Pre-test setup → Test scenarios → Pass/Fail verdicts → Debrief. Discuss with your group before writing your answers.
3
Test the live system in pairs (20 mins)
Your teacher will share the link to the live grant system and the test scenario pack. Work in pairs — one applicant, one caseworker. Follow each scenario step by step and record your verdict.
Test environment: Password is test1234. Verification codes appear on screen — no real email is sent. This is intentional.
4
Present back to the class (3 mins per group)
Use the Debrief tab in your group pack. Cover: what your testing type is, which outcomes were Pass/Fail/Blocked, what you found on the live system, and one thing that surprised you.
Which group does what
| Group | Testing type | The key question | Live system? |
|---|---|---|---|
| A | Functional & Integration | Does it work? Do the parts connect? | ✓ Yes |
| B | Accessibility & Usability | Can everyone use it? | Concepts only |
| C | Performance & Security | Does it handle load? Is data safe? | ✓ Yes (security) |
| D | Operational Readiness | Are teams ready for go-live? | Concepts only |
| E | Regression | When things change, what breaks? | ✓ Yes |
Class activity
Testing — why, what, and how
Testing is not just about checking if a feature works. A robust test strategy covers five dimensions. Each group will become the expert in one area and present their findings back to the class.
How this works: Each group works through four stages — Pre-test setup, Test scenarios, Pass/Fail verdicts, and a Debrief. You have 25 minutes. Use the group pills above to jump to your pack. At the end, each group presents their key findings to the class.
⚙️Group A — Functional & Integration
Does the feature work as specified? Do systems hand off correctly to each other? You will test the submission-to-confirmation flow end to end.
Focus: Application submission → eligibility check → confirmation email
♿Group B — Accessibility & Usability
Can all users use the system? Is it easy to navigate? You will test the submission form against GOV.UK accessibility standards and usability principles.
Focus: WCAG 2.1 AA, keyboard navigation, plain English, error handling
🔒Group C — Performance & Security
Does the system hold up under load? Is applicant data safe? You will test deadline-day volume and data handling against security principles.
Focus: Submission deadline load, data encryption, access control
🚀Group D — Operational Readiness
Are the teams ready for go-live? Is support in place? You will assess whether the grant management system is ready to go live using a readiness checklist.
Focus: Support, monitoring, training, rollback plan, comms
🔄Group E — Regression Testing
When the approval flow changes, what else breaks? You will identify which existing tests must be re-run and why change ripples through the system.
Focus: Impact analysis, re-test scope, test dependency mapping
What is a test scenario?
| Field | What it means | Example |
|---|---|---|
| Test ID | Unique reference for tracking | FUNC-001 |
| Story reference | Which user story this tests | As an applicant, I want to submit… |
| Preconditions | What must be true before the test runs | Applicant is logged in. Form is complete. |
| Test steps | Exactly what the tester does | 1. Click Submit. 2. Observe response. |
| Expected result | What should happen if the system works | Confirmation screen shown. Email sent. |
| Actual result | What actually happened (filled in when running) | — (filled during test execution) |
| Pass / Fail / Blocked | Verdict based on expected vs actual | Pass |
⚙️ GROUP A — FUNCTIONAL & INTEGRATION TESTING
Stage 1 of 4
Pre-test setup
Before running a single test, your group must agree what you are testing, under what conditions, and with what data. Complete this section together before moving to scenarios.
What are you testing?
Name the feature and the user story it comes from.
Test environment
Where will the test run? Is it the same as production?
Test data
What data do you need to set up before testing? Who creates it?
Entry criteria
What must be true before testing can start?
Who is the tester?
Role and responsibilities during the test.
Exit criteria
When is testing complete? What does done look like?
⚙️ GROUP A — FUNCTIONAL & INTEGRATION TESTING
Stage 2 of 4
Test scenarios
You have three scenarios to work through. Write one from scratch, complete one, and fix one broken scenario.
Scenario A-001 — Happy path submission✏️ Write from scratch
The most important scenario: a valid, complete application submitted successfully. Write every field using the template below.
| Field | Your answer |
|---|---|
| Test ID | |
| Story reference | |
| Preconditions | |
| Test steps | |
| Expected result |
Scenario A-002 — Incomplete form submission🔲 Complete the gaps
An applicant tries to submit without filling in all mandatory fields. Complete the missing parts.
| Field | Content |
|---|---|
| Test ID | FUNC-002 |
| Story reference | As an applicant, I want to submit a completed grant application so that I am considered for funding. |
| Preconditions | Complete this: What state must the form be in? Which field(s) are left empty? |
| Test steps | 1. Log in as test applicant. 2. Navigate to draft application FUNC-TEST-002. 3. Leave the "Project description" field empty. 4. Click Submit application. |
| Expected result | Complete this: What should the system do? What should the applicant see? Should an email be sent? |
Scenario A-003 — Integration: eligibility check fires🔧 Find and fix the errors
This scenario tests the integration between the submission form and the eligibility rules engine. It contains three deliberate errors. Find them and correct them in the boxes below.
| Field | As written (find the errors) |
|---|---|
| Test ID | FUNC-003 |
| Preconditions | Applicant is not logged in. Application is incomplete. Write the corrected precondition: |
| Test steps | 1. Log in as test applicant (ineligible org type). 2. Complete all form fields. 3. Click Submit application. |
| Expected result | Application is submitted and confirmed. Eligibility check does not run. Applicant receives approval email immediately. Write the corrected expected result: |
| Integration check | No need to check the eligibility rules engine — that is a separate system. Why is this wrong? Write the correct statement: |
⚙️ GROUP A — FUNCTIONAL & INTEGRATION TESTING
Stage 3 of 4
Pass / Fail verdicts
Read each described test outcome. Decide whether it is a Pass, Fail, or Blocked — and why.
TEST OUTCOME 1 — Happy path submission
"The tester submitted a complete application. A confirmation screen appeared with the reference number REF-2025-0099. The email inbox received a confirmation email within 30 seconds. The audit log shows a submission event at the correct timestamp. However, the eligibility rules engine log shows the check did not run — no entry recorded."
TEST OUTCOME 2 — Incomplete form
"The tester left the Project description field empty and clicked Submit. The page reloaded and showed the form again from the top, with no error message visible. Scrolling down revealed a red asterisk next to the Project description field but no explanatory text. No email was sent."
TEST OUTCOME 3 — Ineligible organisation
"The ineligible test applicant submitted a complete application. A confirmation screen appeared with a reference number. No eligibility flag was shown. The grants officer dashboard shows the application as 'Under review.' The eligibility rules engine log shows a failed check was recorded — but the applicant was not notified."
⚙️ GROUP A — FUNCTIONAL & INTEGRATION TESTING
Stage 4 of 4
Debrief — present back to the class
Use these points to guide your 3-minute presentation to the class.
DEBRIEF GUIDE
What your group should share
What is functional testing — and what is integration testing? What is the difference between them?
Which of your three test outcomes was Pass, which was Fail, and which was Blocked — and why?
The eligibility check is a system story that runs automatically. How do you test something no one triggers manually?
What would a Severity 1 defect look like in the grant submission flow? What would you do if you found one?
Key teaching point: A passing functional test and a passing integration test are different things. The form can work perfectly and the eligibility engine can fail to fire — both tests needed to catch that.
♿ GROUP B — ACCESSIBILITY & USABILITY TESTING
Stage 1 of 4
Pre-test setup
Accessibility testing checks that all users — including those with disabilities — can use the system. GOV.UK services must meet WCAG 2.1 AA as a minimum. Usability testing checks whether real users can complete tasks easily. Set up your approach before starting.
What are you testing?
Which screen(s) and which standard?
Test tools
What tools would you use in a real test?
User profiles
Who are you testing on behalf of?
Entry criteria
What must be ready before accessibility testing starts?
Usability tasks
What will you ask users to do?
Exit criteria
When is accessibility testing done?
♿ GROUP B — ACCESSIBILITY & USABILITY TESTING
Stage 2 of 4
Test scenarios
Scenario B-001 — Keyboard navigation✏️ Write from scratch
Some users cannot use a mouse and rely entirely on keyboard navigation. Write a scenario that tests whether the submission form is fully keyboard accessible.
| Field | Your answer |
|---|---|
| Test ID | |
| WCAG criterion | |
| Preconditions | |
| Test steps | |
| Expected result |
Scenario B-002 — Error message plain English🔲 Complete the gaps
GOV.UK standards require error messages to be specific, written in plain English, and explain how to fix the problem. Complete this scenario.
| Field | Content |
|---|---|
| Test ID | ACC-002 |
| WCAG criterion | 3.3.1 Error Identification — errors described in text; 3.3.3 Error Suggestion — suggestions provided |
| Preconditions | Submission form open. All mandatory fields empty. |
| Test steps | 1. Click Submit without filling in any fields. 2. Read every error message displayed. 3. Compare against GOV.UK error message guidance. |
| Expected result | Complete this: What should each error message do? Give an example of a good error message vs a bad one for the "Organisation name" field. |
| GOV.UK standard | What does the GOV.UK Design System say about error messages? (Think: be specific, say what went wrong, say how to fix it.) |
Scenario B-003 — Colour contrast check🔧 Find and fix the errors
This scenario tests colour contrast for users with visual impairments. It contains three errors. Find and fix them.
| Field | As written |
|---|---|
| WCAG criterion | 1.4.3 Contrast — minimum ratio 3:1 for normal text Fix: What is the correct minimum contrast ratio for normal text under WCAG 2.1 AA? |
| Test steps | 1. Use a colour contrast analyser tool on every text element. 2. Check submit button text against button background. 3. Check placeholder text in form fields. |
| Expected result | All text elements pass 3:1 contrast ratio. Placeholder text is exempt from contrast requirements. Fix the expected result — two things are wrong: |
| Scope | Only check the Submit button. Other elements are the designer's responsibility. Why is this wrong? Who is responsible for accessibility across the whole screen? |
♿ GROUP B — ACCESSIBILITY & USABILITY TESTING
Stage 3 of 4
Pass / Fail verdicts
TEST OUTCOME 1 — Keyboard navigation
"The tester navigated the form using Tab only. All fields were reachable. A visible focus ring appeared on most elements. However, the Submit button showed no visible focus indicator — the browser default had been overridden by CSS with no replacement style applied."
TEST OUTCOME 2 — Error messages
"Submitting with empty fields produced the message: 'Error: field required' next to each mandatory field. The organisation name field showed 'Error: field required' in red text. No suggestion of how to fix the error was provided. The error summary at the top of the page listed all errors with links to each field."
TEST OUTCOME 3 — Colour contrast
"The colour contrast analyser found: main body text passes at 7.2:1. The Submit button white text on dark green passes at 5.1:1. Placeholder text in form fields shows at 2.8:1. The 'Save draft' secondary button shows light grey text on white background at 2.1:1."
♿ GROUP B — ACCESSIBILITY & USABILITY TESTING
Stage 4 of 4
Debrief
DEBRIEF GUIDE
What your group should share
What is WCAG 2.1 AA and why does it matter for a GOV.UK service like this grant system?
Which of your three outcomes was Pass, Fail, or Blocked — and what specifically caused the failure?
What is the difference between accessibility testing and usability testing? Can something pass WCAG and still be unusable?
Who in a delivery team is responsible for accessibility — the designer, the developer, or the tester?
Key teaching point: Accessibility is not a nice-to-have. For public sector services it is a legal requirement under the Public Sector Bodies Accessibility Regulations 2018. A service that fails WCAG 2.1 AA cannot go live.
🔒 GROUP C — PERFORMANCE & SECURITY TESTING
Stage 1 of 4
Pre-test setup
Performance testing checks the system behaves correctly under load. Security testing checks that data is protected and access is controlled. These are often called non-functional requirements — but they are just as important as functional ones.
What are you testing?
Name the scenario and the risk.
Performance targets
What are acceptable response times and error rates?
Security scope
What data and access points are you testing?
Test tools
What would you use in a real test?
Test environment
Why can't you run load tests in production?
Exit criteria
When is performance and security testing complete?
🔒 GROUP C — PERFORMANCE & SECURITY TESTING
Stage 2 of 4
Test scenarios
Scenario C-001 — Deadline day load test✏️ Write from scratch
The submission deadline is midnight. Based on previous years, 400 applicants typically submit in the final hour. Write a performance test scenario for this.
| Field | Your answer |
|---|---|
| Test ID | |
| Risk being tested | |
| Preconditions | |
| Test steps | |
| Expected result |
Scenario C-002 — Access control: applicant data isolation🔲 Complete the gaps
Can Applicant A access Applicant B's form? This is a critical security test. Complete the missing fields.
| Field | Content |
|---|---|
| Test ID | SEC-001 |
| Risk | Horizontal privilege escalation — one applicant accessing another applicant's data. |
| Preconditions | What two test accounts do you need? What state must their applications be in? |
| Test steps | 1. Log in as Applicant A. 2. Note the URL of Applicant A's application (e.g. /applications/123). 3. Manually change the URL to Applicant B's reference (e.g. /applications/124). 4. Observe the response. |
| Expected result | What should happen? What should the system return? Should this be logged? |
Scenario C-003 — Role-based access control🔧 Find and fix the errors
This scenario tests whether a reviewer can access the grants officer's approval decision screen. It contains three errors.
| Field | As written |
|---|---|
| Preconditions | Log in as grants officer. Application REF-001 is in draft state. Fix: Who should be logged in? What state should the application be in? |
| Test steps | 1. Log in as a reviewer. 2. Navigate directly to the approval decision URL. 3. Attempt to click Approve. |
| Expected result | The reviewer sees the approval screen and can click Approve. The system processes the approval. Fix: What should actually happen when a reviewer tries to access the approval screen? |
| Security principle | This only matters if the reviewer knows the URL. Security through obscurity is sufficient. Why is "security through obscurity" not acceptable? What principle applies here? |
🔒 GROUP C — PERFORMANCE & SECURITY TESTING
Stage 3 of 4
Pass / Fail verdicts
TEST OUTCOME 1 — Load test
"400 simulated concurrent users submitted applications over 60 minutes. Average response time: 2.8 seconds. Peak response time at the busiest moment (minute 55): 11.4 seconds. Error rate: 3.2% — 13 submissions returned a 503 error and were lost. The system did not crash but degraded significantly at peak."
TEST OUTCOME 2 — Applicant data isolation
"Applicant A navigated to Applicant B's application URL by changing the ID in the address bar. The system returned a 403 Forbidden error — 'You do not have permission to view this application.' The attempt was recorded in the security audit log with Applicant A's user ID and timestamp."
TEST OUTCOME 3 — Role-based access
"A reviewer navigated directly to the approval decision URL. The system displayed the approval screen, including the rationale field and the Approve/Reject buttons. However, clicking Approve produced an error: 'Action not permitted for your role.' The screen was visible but the action was blocked server-side."
🔒 GROUP C — PERFORMANCE & SECURITY TESTING
Stage 4 of 4
Debrief
DEBRIEF GUIDE
What your group should share
What is the difference between performance testing and load testing? What is a stress test?
Which outcomes passed, failed, or were blocked — and what specifically caused each verdict?
Outcome 3 blocked the action server-side but showed the screen to the reviewer. Is that a pass or a fail — and why does it matter?
Why must performance and security tests run in a separate environment, not in production?
Key teaching point: Outcome 3 is a partial failure — server-side validation caught it, but showing the screen to an unauthorised user is still a security weakness. Defence in depth means blocking at every layer, not just the last one.
🚀 GROUP D — OPERATIONAL READINESS TESTING
Stage 1 of 4
Pre-test setup
Operational readiness testing asks: even if the system works perfectly, are the people and processes ready? Go-live is not just a technical event — it is an organisational one. Support must be trained. Monitoring must be in place. A rollback plan must exist.
What are you assessing?
What does "ready to go live" mean for the grant system?
Stakeholders involved
Who needs to sign off readiness?
Training check
What training must be complete before go-live?
Monitoring & alerting
What must be monitored from day one?
Rollback plan
If go-live fails, what happens?
Go / No-go criteria
What must be true for the SRO to approve go-live?
🚀 GROUP D — OPERATIONAL READINESS TESTING
Stage 2 of 4
Readiness scenarios
Scenario D-001 — Go-live readiness checklist✏️ Write from scratch
Write a go-live readiness checklist for the grant management system. Include at least 8 items across people, process, and technology. Tick the ones you believe are ready based on what you know about the system.
Scenario D-002 — Incident response🔲 Complete the gaps
At 11:45pm on deadline night, the submission endpoint returns 503 errors. Complete this incident response scenario.
| Field | Content |
|---|---|
| Incident trigger | Monitoring alert fires: submission endpoint error rate exceeds 5% for 3 consecutive minutes. |
| Immediate action | What is the first thing the on-call engineer does? Who do they contact? |
| Applicant communication | What should applicants be told? How quickly? Through which channel? |
| Resolution criteria | How do you know the incident is resolved? What checks confirm recovery? |
| Post-incident | What happens after the incident is resolved? (Think: applicants who failed, deadline extension, incident review.) |
Scenario D-003 — Go / No-go decision🔧 Find and fix the errors
This is the go/no-go briefing for the SRO. It contains three things that should block go-live but are being waved through. Identify them.
| Field | As stated — find what should block go-live |
|---|---|
| Defects | Two Severity 2 defects open — the team says they are "low risk" and will be fixed in the next sprint. One known issue: the confirmation email sometimes sends twice. SRO has approved proceeding. Should this block go-live? Why or why not? |
| Training | Service desk has not yet received training on the new system. The grants team lead says "they will pick it up on the day." Why is this a go-live blocker? |
| Monitoring | Monitoring dashboards will be set up in the week after go-live — the team is too busy right now. Why must monitoring be live before go-live, not after? |
🚀 GROUP D — OPERATIONAL READINESS TESTING
Stage 3 of 4
Go / No-go verdicts
For operational readiness, Pass = Ready to go live. Fail = Not ready — must be resolved. Blocked = Cannot assess until a dependency is resolved.
READINESS CHECK 1 — Support model
"The service desk has a dedicated phone line for applicant queries. They have been provided a one-page FAQ document. However, the FAQ was written by the development team and has not been reviewed by the grants team. The service desk manager confirms 2 staff will be on duty during the first week."
READINESS CHECK 2 — Rollback plan
"A rollback plan exists and is documented. It has been reviewed by the technical lead. It has not been tested in a staging environment — the team ran out of time. The plan states rollback can be completed in 90 minutes. No drill has been run."
READINESS CHECK 3 — Data protection
"The Data Protection Officer has reviewed the data flow diagram. A DPIA (Data Protection Impact Assessment) was completed 8 months ago when the project started. The DPO notes that the payment tranche feature was added 3 months ago and is not covered in the DPIA. The DPO has not signed off the updated scope."
🚀 GROUP D — OPERATIONAL READINESS TESTING
Stage 4 of 4
Debrief
DEBRIEF GUIDE
What your group should share
What is operational readiness testing — and why does it happen separately from functional testing?
Which readiness checks were Ready, Not ready, or Blocked — and what would you need to see before approving go-live?
A rollback plan exists but has not been tested. Does a plan that has never been practised count as readiness?
The DPIA gap — who is responsible for keeping the DPIA up to date as features are added during delivery?
Key teaching point: Go-live is a business decision, not just a technical one. The SRO owns the decision. Testers provide evidence. An untested rollback plan and an out-of-date DPIA are both blockers — even if the software works perfectly.
🔄 GROUP E — REGRESSION TESTING
Stage 1 of 4
Pre-test setup
Regression testing asks: when something changes, what else breaks? Every change to a system carries risk. Regression testing identifies which existing tests must be re-run to confirm the rest of the system still works after a change is made.
What changed?
Describe the change that triggers the regression test.
Impact analysis
What other parts of the system might be affected by this change?
Tests to re-run
Which existing tests must be re-run? Why?
New tests needed
What new scenarios does this change require?
Regression scope
What is NOT affected and can be skipped?
Exit criteria
When is regression testing complete?
🔄 GROUP E — REGRESSION TESTING
Stage 2 of 4
Test scenarios
Scenario E-001 — New status: end-to-end regression✏️ Write from scratch
A new "Request more information" status has been added. Write a regression test that checks the complete approval journey still works correctly after this change.
| Field | Your answer |
|---|---|
| Test ID | |
| Change being regressed | |
| Preconditions | |
| Test steps | |
| Expected result |
Scenario E-002 — Notification regression🔲 Complete the gaps
The change adds a new notification email for "Request more information." Complete this regression check for the notification system.
| Field | Content |
|---|---|
| Test ID | REG-002 |
| Why this is a regression risk | Adding a new email template to the notification service could affect the configuration of existing templates. |
| Tests to re-run | Which existing notification tests must be re-run? List them and say why each is at risk. |
| New test needed | Write the expected result for the new "Request more information" email. What should it contain? When should it fire? |
| Regression verdict | If the confirmation email now sends twice (it was working before the change), what type of defect is this? What caused it? |
Scenario E-003 — Reporting dashboard regression🔧 Find and fix the errors
The reporting dashboard shows a count of applications by status. The new status was added. This scenario contains three errors in how the regression was planned.
| Field | As written |
|---|---|
| Regression scope | The reporting dashboard does not need to be regression tested — it is a separate system and the change only affects the approval workflow. Why is this wrong? Why must the dashboard be regression tested? |
| Test approach | Run the dashboard report and check it looks the same as before. What specifically should be checked? What data values matter? |
| Expected result | The dashboard should show the same numbers as before the change. Why is "same numbers as before" the wrong expected result after adding a new status? |
🔄 GROUP E — REGRESSION TESTING
Stage 3 of 4
Pass / Fail verdicts
TEST OUTCOME 1 — End-to-end journey after change
"The complete journey was tested: submit → review → request more information → applicant uploads documents → grants officer approves. All stages worked correctly. However, the status on the applicant's dashboard still showed 'Under review' during the 'Request more information' stage — it did not update to show the new status."
TEST OUTCOME 2 — Notification regression
"The new 'Request more information' email fired correctly. The existing confirmation email still sends on submission. The existing approval notification still sends on approval. The rejection notification still sends on rejection. All email content is unchanged. Timing is within the original 30-second SLA."
TEST OUTCOME 3 — Reporting dashboard
"The reporting dashboard shows: Submitted 47, Under review 12, Approved 18, Rejected 9. The new 'Request more information' status does not appear as a separate row — applications in that status are counted under 'Under review.' Total count is correct. The reporting officer would not be able to see how many applications are awaiting additional information."
🔄 GROUP E — REGRESSION TESTING
Stage 4 of 4
Debrief
DEBRIEF GUIDE
What your group should share
What is regression testing — and why does every change, no matter how small, require it?
Which outcomes passed, failed, or were blocked — and what specifically caused each verdict?
Outcome 3 — the totals were correct but the new status wasn't shown. Is that a Pass or a Fail? Who decides?
How would you decide which tests to re-run after a change? Can you regression test everything every time?
Key teaching point: Outcome 3 depends on whether the reporting officer's user story requires the new status to be visible. If it does, it is a Fail. If not, it might be a known gap to address in the next sprint. Testing tells you what happened — requirements tell you whether that is acceptable.