Zara Shafiq

Junior QA on a US-based EHR product (the therapy module: appointment scheduling, clinical notes, patient records, billing). HIPAA-regulated. Release bar of 99% defect-free.

I was working through a billing flow during a release cycle. Therapist completes a session, the system calculates the charge, the claim gets generated. For a standard session the numbers looked correct. When I switched to a less common session type (one that hit a specific billing-code boundary), the calculated charge didn't match what I worked out on paper.

I wrote out the expected charges across each scenario, ran them through the system one by one, and confirmed the mismatch was consistent and reproducible. Filed the bug with the math, the scenarios, and screenshots. Looped in the dev lead the same day.

Fixed before release. If it had shipped, therapists using that session type would have been under-billing for the work they'd done. In a regulated healthcare product, that's both a revenue and a compliance issue.

Never trust the UI when the math is doing the actual work. If a calculation looks right on screen, that's exactly when I check it by hand.

Manual QA at an EdTech company building a connected ecosystem: an AI quiz generator, an AI transcription and translation service, a video conferencing tool, a lesson capture platform, an NFC-badge notification system, and a lesson builder. All of it ran across web, Android, and Android-based interactive touchscreen displays.

The default at the company was to test on dev environments and emulators, because real hardware was slower and more annoying to set up. I pushed to test on the actual touchscreen units instead, because the bugs that mattered were the ones that showed up only on real hardware: touch input latency under heavy load, NFC tap reliability with real badges, audio routing on the embedded Android, cross-device sync between a touchscreen and a teacher's mobile.

That choice meant I had to context-switch fast (a hardware bug in the morning, an AI accuracy check at lunch, a Stripe webhook validation in the afternoon) and learn each product's edges quickly. Caught wrong-question bugs in the AI quiz generator, transcription errors in the captioning tool, and a Stripe billing edge case where a subscription state transition wasn't firing the right webhook. The Stripe flow was where I learned subscription testing the hard way: every plan transition, every webhook event, every failed payment branch needed its own case.

Emulators tell you what the product does in theory. Real hardware tells you what it does in the room with the people who'll actually use it.

Solo QA on a new Electron-based virtual office product. One of the meeting rooms routes through a production dialer for sales calls and customer demos. Customers were starting to ask how many concurrent dialer sessions the room could support. Internally, no one had a real answer.

Testing with real dialers at scale would have been expensive: real phone numbers, real per-minute call costs, real load on the dialer provider. My local machine also had hardware limits, so I couldn't just spin up more instances locally.

I worked through the test design in pieces. First, I substituted screen-share-with-sound for the real dialer. Both flow through the same LiveKit publisher pipeline under the hood, so the load on the backend would be equivalent without the per-call cost. Next, I moved off my local machine onto GitHub Actions runners to get past the hardware limits (36 runners in parallel). Then I asked the dev team to add a flag that allowed multiple instances of the app to run on the same machine, so a single runner could carry more than one user. Finally, I ran the test under realistic 3-window load (workspace + dialer + meeting room running simultaneously per instance), so the numbers reflected actual user behavior, not a synthetic baseline.

Verified 33 concurrent screen-share-with-sound publishers under production-equivalent load. The product team had a real number to give to customers, and a real understanding of where capacity actually sat (higher than the team had assumed). The setup is reusable, so when engineering ships changes to the real-time layer we can re-run the test instead of guessing.

A lot of capacity questions get answered with "we think it's around X." Going and measuring it takes more design work but produces a number you can actually defend.