Training a QA team in Hyderabad
The digital payroll system I was designing for EP had a testing problem. Payroll calculation involved more than 5²⁰⁰ combinations of fields — manual testing was impossible, and existing unit tests didn’t capture the end-to-end workflows where objects passed between different users before reaching payroll processing.
The company had acquired an external QA team in Hyderabad. They needed to start writing automated tests — fast.
The problem
The QA team were experienced developers. They’d already reverse-engineered parts of the codebase and researched the film industry independently. What they were missing was an understanding of the real-world user scenarios the tests needed to reflect: who the users were, how they interacted with the system, and what the critical paths looked like.
Without that context, automated tests would cover code paths rather than user journeys — and miss the failures that actually mattered.
What I did
I travelled to Hyderabad to run an intensive knowledge-transfer session with the team — Srikanth, Ram, Kowsalya, and others. Because they’d prepared so thoroughly, I could go into far more depth than originally planned: full persona breakdowns, detailed workflow walkthroughs, edge cases, and the business logic behind each step.
The session was structured around the user scenarios that automated tests needed to replicate — grounding the technical test-writing in real human behaviour.