This sample shows how IDCI runs user acceptance testing with the people who will use a system. It presents pages from the test package and the readiness report we delivered.
System ConfigurationSoftware TrainingWork Instructions
This excerpt comes from a delivered engagement. A public transit agency was preparing to launch a mobile app that lets riders report security incidents and lets dispatchers and field responders handle each report. We removed the names of the agency, its partner agencies, the vendor, and every participant before publishing these pages.
1 · Our approach
Test with real users
We test with the people who will use the system, each in the role that person holds every day.
Follow one record end to end
Each scenario follows a single incident through every state, from the rider’s report to the responder’s clearance.
Disciplined Project Management
Testers sort every comment as a crash, a usability concern, or a defect, and send feedback daily, so problems surface while the test period is still under way.
Information Systems Expertise
The scenarios verify the timestamps the app records at each state, because performance reporting depends on that data.
Business Acumen
The readiness report looks past the software to the contracts and practices that decide whether the app will deliver its value.
2 · The work product — excerpt
The test package states the objectives and directions, provides a feedback log for each tester, and walks through scenarios that follow an incident across every role. The status report closes the test period with a readiness conclusion and a recommendation.
Scenario flow: one incident through every state
ReportA rider submits an incident with a photo.
AssignThe dispatcher views the report and assigns a department.
DispatchThe department assigns a responder.
AcknowledgeThe responder acknowledges the call.
On sceneThe responder arrives and marks the incident on scene.
ClearThe responder completes the work and clears the incident.
At each state, the tester records the time the app displays, and quality assurance compares those times across every role.
Test directions, scenarios, and readiness report
View only. Use the arrows, the thumbnails, or your arrow keys to turn the pages; on a phone, swipe.
The excerpt pages are available for viewing at idcinc.net/worksamples/user-acceptance-testing.html and are not reproduced in print.
3 · What the sponsor gains
✓
Evidence for launch. The sponsor launches knowing that the app works for every role.
✓
Trained users. Users arrive at launch already familiar with their own screens.
✓
Complete data. The recommendations protect the quality of the performance data the app will produce.
4 · How we work, and what we will not do
Test directions
Objectives, the features under test, and instructions written for each tester.
Scenarios and feedback log
End-to-end scenarios for each role and a log that sorts every comment.
Readiness report
Testing status by group, a conclusion on readiness, and recommendations for rollout.
What we will not do
We do not recommend a launch that its users have not tested, and we do not treat a vendor’s internal test results as user acceptance.
Questions about any of this?
If you are preparing to launch a system, the fastest way through is a conversation. Bring the test plan, the rollout date, or the part of this sample you want tested. Thirty minutes is usually enough to establish whether we are the right fit for the work.