A genuine Req2QA run — not a mockup. Requirements in, validated test coverage out, real live-execution results.
The requirements below come from a sample Incident Management requirements document written for this demonstration — the kind of document a client would supply.
1.2 The system must auto-generate a unique Incident Number (format INC#######) when a new incident record is created.
1.4 The “Caller” field must … allow free-text entry that creates a new caller record automatically if no match exists.
1.8 The “Channel” field … must default to a sensible value when the incident is created through the standard form.
Req2QA generated 11 test cases from the requirements document and executed them unattended in a real browser. We show the three we have independently checked against their screenshots — including two where the software did not meet its requirement. The remaining results from this run are still under review, and we don’t publish a result until it has been checked.
| ID | Test case | Req. | Result |
|---|---|---|---|
| TC-003 | Create two incidents and confirm each receives a different Incident Number | 1.2 | PASS |
| TC-014 | Channel field has a sensible default on a new incident | 1.8 | FAIL |
| TC-007 | Free-text Caller that doesn’t exist is auto-created | 1.4 | FAIL |
Both FAILs are gaps between this sample requirements document and how the developer instance is configured — the instance doesn’t do what the document asks. They are not defects in ServiceNow itself; they show Req2QA reporting a mismatch rather than assuming a PASS.
Executed 24 September 2026 (Australian time) against a live ServiceNow developer instance. Times inside the screenshots are shown in the instance’s own time zone.
Cropped to the evidence; click any screenshot to view it full size.
TC-003 — PASS. Both test incidents appear in the list with different numbers, INC0010009 and INC0010010.
TC-014 — FAIL. A brand-new incident opens with Channel set to “–– None ––”. Requirement 1.8 asks for a sensible default — this instance doesn’t provide one.
TC-007 — FAIL. Typing a caller who doesn’t exist is rejected with “Invalid reference”; no record is offered or created. Requirement 1.4 expects the new caller to be created automatically.
The requirements below come from a sample Salesforce Sales Cloud requirements document written for this demonstration — the kind of document a client would supply.
1.2 The Lead creation form must allow entry of standard identifying fields … Values entered in each of these fields must be saved exactly as entered and must be visible, unchanged, on the Lead’s detail page after save.
1.3 The Email field on a Lead must be validated for a well-formed email address format … before save.
1.4 … Lead Status … must be changeable to any other value in the org’s configured Lead Status picklist without error.
1.5 A user must be able to convert a qualified Lead into an Account, Contact, and (optionally) an Opportunity using Salesforce’s standard “Convert” action.
Req2QA produced test cases from the requirements document and ran them against a Salesforce trial organisation (a free Salesforce trial environment, not a customer’s production system). Below are four of them, all of which passed. We checked each result against its screenshots before publishing it. A PASS means the behaviour described was observed; it is not a claim that Salesforce has no defects.
| ID | Test case | Req. | Result |
|---|---|---|---|
| TC-004 | Lead creation form saves all standard identifying fields correctly | 1.2 | PASS |
| TC-006 | Lead Email field accepts a well-formed email address | 1.3 | PASS |
| TC-008 | Lead Status can be changed to a configured picklist value | 1.4 | PASS |
| TC-010 | Convert a Lead without creating an Opportunity | 1.5 | PASS |
Scope of this run.
Executed 7 October 2026 (Australian time) against a Salesforce trial organisation. Salesforce asked for an identity-verification code during sign-in; a person on our side entered it, as the application requires.
Cropped to the evidence; click any screenshot to view it full size.
TC-004 — PASS. The saved Lead shows the company, title, phone and email exactly as typed.
TC-006 — PASS. A Lead created with a well-formed email address is saved, and the email is displayed unchanged.
TC-008 — PASS. The Lead’s status path now shows “Working” after the change was saved.
TC-010 — PASS (1 of 2). After conversion a new Contact exists, linked to the new Account, with Opportunities (0) — no Opportunity was created.
TC-010 — PASS (2 of 2). Searching “All Open Leads” for the converted Lead returns 0 items.
R1. The system shall allow an HR administrator to add a new employee record by providing first name, middle name (optional), and last name.
R3. The system shall allow an HR administrator to optionally attach a profile photo (JPG, PNG, or GIF, up to 1MB).
Typical engagements run 25–300 test cases; this is a genuine excerpt, not a curated best case.
| ID | Test case | Type | Result |
|---|---|---|---|
| TC-001 | Add new employee with first, middle, and last name | Happy path | PASS |
| TC-003 | Attempt to add employee without a last name | Negative / validation | PASS |
| TC-007 | Attach a valid JPG profile photo within the 1MB limit | Edge case | PASS |
3 test cases executed, 3 passed, 0 failed, 0 blocked. Executed 2026-09-21.
Click any screenshot to view it full size.
TC-001 — record created and saved successfully.
TC-003 — form correctly blocked save with a "Required" validation message.
TC-007 — the attached test photo is intentionally watermarked "generated by Req2QA — not a real document." We never use realistic-looking fake photos of real people as test data — see our Security Overview for how we handle test data generally.
