Builds stakeholder-readable scripted manual test cases from a feature spec in four formats: a step-table (preconditions / steps / expected result / actual / pass-fail / notes) for spreadsheet review, a Gherkin Given/When/Then format for BDD-aware teams, a business-language UAT script with acceptance-criteria mapping and contractual sign-off (references/uat-format.md), and a one-line-per-item execution checklist for smoke / on-call / bug-bash / compliance sweeps (references/checklist-format.md). Each script is self-contained (no implicit team knowledge), single-scenario (one happy + N edge per script), and includes the data setup the tester needs without being a developer. Use when a feature can't be (or shouldn't be) fully automated and a human tester needs an executable script or checklist - UAT sign-off rounds, regression baselines, certification testing, deploy smoke checklists, exploratory follow-up scripts.
94
88%
Does it follow best practices?
Impact
95%
0.98xAverage score across 10 eval scenarios
High
Do not use without reviewing
qa/TC-451-transfer-limit.md is the case that checks a customer cannot send more
than their daily outbound allowance. It is five lines long and every tester who
has run it has run a different test.
One tester used the youth account and sent 6,000; the transfer went through and she raised a defect. Another used the same account and sent 30,000; it was blocked and he passed the case. A third ran it from Lisbon late in the evening, did the blocked transfer and then the allowed transfer, and both behaved backwards from what he expected. None of them recorded which account they used.
The case is also single-use in practice. Whatever it sends counts against that account for the rest of the day, so a tester re-running it an hour later to check a fix finds the "allowed" transfer refused as well, and logs a second, imaginary defect.
One of the numbers this case turns on is not documented anywhere we can find, and the last three testers each assumed a different value for it. We would rather the case says plainly that we do not know than have a fourth person assume.
Produce one markdown document at exactly qa/TC-451-daily-transfer-limit.md
containing:
Out of scope: automating the case, testing inbound transfers, and any change to the limits themselves.
Extract the following files before beginning.
=============== FILE: qa/TC-451-transfer-limit.md ===============
=============== FILE: docs/limits-and-accounts.md ===============
App: https://qa.mobile.veldbank.example (web build of the mobile app)
| Tier | Daily outbound limit |
|---|---|
| Standard | 5,000.00 ZAR |
| Premium | 25,000.00 ZAR |
The Youth tier was launched in June. Its daily limit is not published on this page; the product ticket that would define it (PROD-2291) is still open and the tier owner is Thandi M. in Retail Product.
The limit is cumulative over a calendar day in South African Standard Time (UTC+2) and resets at 00:00 SAST. Testers outside South Africa should expect the boundary to fall at a different local hour.
Any outbound payment above 1,000.00 ZAR requires a one-time passcode sent to the account's registered mobile number. In QA these are not sent to a real handset - they appear in the message sandbox at https://qa.mobile.veldbank.example/qa-tools/messages, usually within 60 seconds.
A beneficiary added today cannot receive a payment for 30 minutes. All beneficiaries listed below were added months ago and are past cooling-off.
| Customer login | Tier | Available balance | Saved beneficiary |
|---|---|---|---|
| qa.std1@veldbank.example | Standard | 48,000.00 ZAR | "K Mahlangu - Savings" |
| qa.prem1@veldbank.example | Premium | 190,000.00 ZAR | "T Naidoo - Cheque" |
| qa.youth1@veldbank.example | Youth | 9,500.00 ZAR | "Guardian - J Botha" |
Passwords for all three: see vault entry qa-mobile-customers.
The QA console (https://qa.mobile.veldbank.example/qa-tools/limits) can clear the accumulated daily total for a single account. The reset takes effect immediately and does not reverse payments already made.