I'm Yelchuri Venkata Sai Subha, an SDET at TransUnion CIBIL. For ~4 years I've owned test automation for credit-bureau data systems that process 70M+ records a day under RBI compliance - where a wrong digit isn't a bug ticket, it's someone's credit score.
At TransUnion CIBIL I lead functional QA in a 3-member team. Our suite validates everything from REST APIs to record-level baseline comparisons through Jenkins-driven ingestion pipelines - the plumbing that decides whether 900M+ consumer records stay correct.
My layer of the stack: Python + Playwright + pytest for UI and E2E, requests for API automation, PostgreSQL for data validation, and Ab Initio ETL pipelines under the hood. All of it in a regulated environment where "it mostly works" is not an acceptable test result.
What I care about isn't test count - it's failure patterns. The most valuable thing I do is read audit logs and data the way an attacker reads code: looking for the ten ways something can go quietly wrong before it goes loudly wrong.
Corporate code stays corporate. So I built my own frameworks on GitHub, wired to GitHub Actions, where every push runs the full suite in public.
45 Playwright tests with a strict Page Object Model discipline - pages own actions, tests own assertions. Parallelized with pytest-xdist, reported with Allure, data faked with Faker.
→ view repo & passing pipeline
A mini payment system built to be tested: 61 tests (25 unit / 35 integration / 1 E2E) covering idempotency, schema contracts, and mocked failure modes with unittest.mock and jsonschema.
→ view repo & passing pipelineA suite of 2,000 tests is only as good as the failure modes it was designed around. I start from audit logs and production data - the ten ways something goes quietly wrong - and work backwards to test cases.
My best catch wasn't automated at all: a design flaw spotted at 75% build, on domain knowledge. Automation scales judgment - it doesn't replace it. Shift-left means being in the design review, not just the pipeline.
Every assertion should answer "what production failure does this prevent?" If it can't, it's maintenance debt wearing a green checkmark. Same rule I apply to my resume: every claim must survive drilling.
Testing at bureau scale means the interesting work happens when something breaks. These are real incidents, told the way I'd defend them in a room.
Payment data corruption hit 400K records in production. Working alongside dev on root cause, I identified ten distinct corruption patterns from the audit logs, translated them into 100 targeted test cases, and validated the fix end to end.
Owned test coverage across a full database engine migration. Ran 6 pre-production validation cycles covering 600M records before cutover.
~2,000 records/day were silently duplicating serial numbers. Designed 55 test cases around the duplication surface and drove verification through a ~1.5-month fix cycle.
Spotted a fundamental design flaw in a data format feature on domain knowledge alone - before it ever reached production. Feature was disabled with zero production exposure.
Open to SDET-2 / Senior SDET roles - fintech, banking, and credit-bureau domains especially.
B.Tech CS, KIIT University '22, CGPA 9.16.