Most teams get everything ready in an afternoon. Below is exactly what to prepare, why each item matters, and how the project runs from start to finish.
“…now I click Pay. I should see the order confirmation and get an email.”
WhyTests are code. Keeping them next to your app means they are versioned, reviewed and run alongside it.
WhyTests need a predictable place to run. Production has real customers and real data, so the tests never run there.
WhyEvery test starts by logging in. The rules for these accounts are further down this page.
Read the credential rules →WhyA short video shows us in minutes what a spec document takes days to explain, including the edge cases only your team knows about.
WhyQuestions always come up. Quick answers keep the delivery date on track.
WhySo the tests run automatically on every pull request, not just on our machines.
WhyReal payment and SMS providers can’t be used in automated tests. Sandboxes make checkout and OTP flows testable.
WhyStable hooks mean the tests don’t break when you change copy or styling.
This is the one thing that makes or breaks a test suite. The accounts we test with have to stay exactly as they were set up, for as long as the tests exist.
What happens if one changes?
Not even “just quickly to test something”. Changing any of these breaks every test that uses the account.
The tests expect exactly what each role can and can’t see.
This includes database clean-ups and QA refreshes. If QA is restored from a snapshot, re-create the accounts afterwards.
No 90-day password expiry, forced resets or lockouts after failed attempts.
Either turn MFA off for these accounts on QA, or share the TOTP secret so the tests can generate codes. Disable CAPTCHA on QA or use the provider’s test keys.
Nobody on your team logs in with them. People testing by hand use their own accounts.
New SSO provider, a redesigned login page or new password rules: tell us first and we’ll update the tests before they go red.
Use a password manager (1Password, Bitwarden) or put them straight into CI secrets. Never send them in plain email or WhatsApp.
No editing and no script needed. Just use the product the way a customer would and talk while you do it.
0:00 “I’m logged out on the homepage. I search for ‘running shoes’ and add the first one to the cart.”
0:24 “In the cart I enter promo code SAVE50. The total should drop from R500 to R450.”
0:41 “If I type an expired code like OLD10, I should see ‘This code has expired’ and the total stays the same.”
1:05 “I pay with the PayFast sandbox card. I land on the confirmation page with an order number, and a confirmation email arrives.”
1:32 “A customer should never see the ‘Refund’ button. Only admins can refund.”
Shown for a Core Coverage project. A Smoke Suite takes about half as long.
Signed before we see a single line of code.
We never need admin rights to your org or any access to production.
Test accounts use fake data. No real customer personal information is used or stored.
At handover we remove our access and confirm it in writing. You rotate the secrets if you want to.
Your progress is saved in this browser. Use “Copy as text” to paste the list into Slack, Teams or Jira for your team.
Book a free call and we’ll go through this list with you and your developer.