Validation status
Live totals across every tester. A scenario counts as covered when two testers have passed it. P1 scenarios must all be covered before the team relies on the module.
Scenarios
one row per scenario, all testers combined| # | Area | Pri | Results | Pass | Fail | Blocked | Covered | Notes from testers |
|---|
Testers
progress per person| Tester | Progress | Run | Pass | Fail | Blocked | Answers | Defects | Recommendation | Last activity |
|---|
Defects by severity
open = not Fixed, Retested or Won't fix| Severity | Open | Fixed | Retested | Won't fix | Total |
|---|
Feedback answers
every answer, grouped by questionMy scenarios
Run them in order. Pick a result, write the case reference you used and what you saw. Everything saves as you type.
My feedback
Pass or fail tells us whether the screens work. This tells us whether you would trust them. A one-line answer is fine; a blank is not.
Defects
Log every defect as soon as you find it, with the scenario it came from. The product team updates Status; the reporter confirms the fix by setting Retested.
New defect
| ID | Scenario | What happened | Expected | Severity | Status | Reporter | Logged |
|---|
Before you start
The KYC team validates the azakaw GO screening module in production, on real cases, before the team relies on it day to day. Your job is to test and report; the decision to rely on the module is taken separately on the strength of what you find.
| Where | Production, https://go.azakaw.ai, with real cases. Every search, decision, note and list change is real and stays in the audit trail. Work exactly as you would on a live file. Do not change policies, lists or settings beyond what a scenario asks, and only with your checker's agreement. |
| Login | Your own production account. If you cannot sign in, or your menu is missing a screen named in a scenario, say so before the test window opens. |
| Role | Each tester is an Analyst (screens, works alerts, decides matches) or a Checker (second reviewer, approves decisions, edits policies and lists). Some scenarios need both; pair up. |
| Cases | Real cases from your current workload: new onboardings, periodic reviews and clients already under monitoring. Between the testers, cover at least one known sanctions hit, one PEP, one subject with adverse media, one company, one vessel if you have one, and several clean names. Write only the case reference here, never a client's full identifiers. |
| Interface | Use the new interface. If a page offers "Open in the new interface", click it once; the choice is remembered. |
| Browser | Chrome or Edge, current version, on a laptop. One run of the critical scenarios on a phone browser as well. |
| Language | Run your pass in English. One tester repeats scenarios S01 to S09 in Arabic and reports layout or wording problems. |
| Time | Half a day per tester for the full script, plus the time to write feedback. |
| Evidence | Screenshot every failure and anything that surprised you, even when it worked. Name the file with the scenario number and send it with the defect. |
| Out of scope | Transaction monitoring, digital onboarding and the training module. Report anything you notice there separately, but do not spend test time on them. |
How this page works
There is no login. The first time you open the page you type your name; the page remembers it on this browser and files everything you record under it. Use the same spelling on every device. Results save as you type. The dashboard adds everyone up. Defects are shared: anyone can log one, and the status is updated by the product team.