TestingMagic generates manual QA test plans for council forms and services. Sign in with your council account to continue. You must be a member of the testing-magic-admin or testing-magic-user group.
Sign-in not working? Paste an ID token
For use only if the hosted sign-in redirect is unavailable. Paste a valid Cognito ID token (JWT). It is stored in this browser tab only.
The token is decoded locally to read your name and group membership.
!You are signed in, but you are not yet in a group that can use TestingMagic.
You need to be in one of two groups: testing-magic-admin for full access, or testing-magic-user for tester access. Ask your service administrator to add you to the group you need, then sign in again.
Open plans appear as tabs. Use the left and right arrow keys to move between tabs, Home and End to jump to the first or last, and Delete to close the plan tab you are on. Closing a tab only closes the view — the plan is kept.
How to generate a test plan
Drop in your requirements (Word, PDF, CSV, text or Markdown, up to 3 files) and the XFP form export (.zip). Each file is sorted automatically. If one is sorted wrongly, change it with Use as.
Select Generate plan. It takes a couple of minutes.
Review the plan, use Adjust and regenerate to steer it, then download the .xlsx.
Everything else is optional and under More options.
Base steps
Example sets follow the usual CXM test script: sign in, find the test customer, start the case, then check CXM and the back-office system. They are written with template variables and none is used until you tick it. Sets you already have, including archived ones, are not added again.
Steps added to the start or end of every test case, such as signing in to CXM or logging out. Each set also has Playwright steps, so automated runs can do them without generating anything. You choose which sets a plan uses under More options when you generate it.
Staged testing
Test a service in three stages. Stage 1 compares the requirements and use cases with the form, case type and integration code and lists the gaps. Stage 2 builds the test matrix (every route through the form, for each area). Stage 3 checks everything again before the final sign-off. An admin signs off each stage before the next one starts.
Projects, newest first
Service
Stage
Latest review
Started by
Form exports
Exports of XFP forms, pulled from XFP admin. Every version that changes is kept, and each one is added to the form backup repository (UAT exports in the uat folder, live ones in live). Pulling an export only reads from XFP: it can't change a form.
Exported forms
Form
Last changed
Last checked
Versions
In the repository
Stage 1: document gap review
Coverage
What the review found for each planned and built item
Side
Result
Items
Sign off Stage 1
Stage 2: test matrix
Every route through the form that ends differently, for each area. The routes are worked out from the form export (branching, conditions, calculated values and submission rules), not by AI. Test each row in UAT with a property in that area, then record the result here or in the spreadsheet.
Leave empty to build from the same export. In the final check, rows that haven't changed keep their results; only changed and new rows need testing again.
Check a new form export for changes
Compares the export's checksums with the one this matrix was built from. Changes to metadata only (such as the form's folder in XFP admin) don't count. Nothing is saved.
Results are matched to rows by the hidden Ref column, so sorting the sheet is fine.
Answer harness
The harness fills in each row's answers the way a resident would, at the row's test property, and does what the form does when it is submitted: it creates the case in UAT CXM. Two minutes after each submission it checks CXM and the contractor's system (read only) and records Pass or Fail. For South Northants it also raises the Bartec requests the form raises itself, in the Bartec test system, and writes the request number back to the case as the form does.
Harness runs
Started
By
Rows
Progress
Actions
Rows to test
Row
Answers to give
Expected
Result
Sign off Stage 2
Plan library
Loading plans…
What this test plan covers
This test plan covers every eventuality mentioned in the requirements, augmented with cases discovered from the form structure and integration code. It does not claim to cover every real-world eventuality. Anything the requirements do not mention, and that the form and code do not reveal, will not appear here. Use the flagged gaps and conflicts to decide where human judgement is still needed.