QA Engineer

I automate anything that is repetitive, stable, and high-value to check on every build: core user flows like login, checkout, or the main data entry path. Those go into my Selenium or Playwright suite and run on every pull request. I keep testing manual for anything new, visually driven, or likely to change in the next sprint, because writing automation for a feature that is still being iterated on is wasted effort. I also reserve manual testing for exploratory sessions, where I am deliberately trying to break the product in ways a scripted test would never think to try. A rough rule I use: if I expect to run the same check more than five times over the life of a feature, it is worth automating. I review the automated suite every quarter to retire tests for features that were removed or changed enough that the test no longer reflects real user behaviour.

I start by reading the requirements and flagging anything ambiguous before writing a single test case, because unclear requirements produce unclear tests. I map out the happy path first, then list edge cases: empty states, maximum input lengths, concurrent users, and permission boundaries. I group test cases by risk, prioritising anything that touches payments, authentication, or data loss. I include both positive and negative test cases, and I note which ones are candidates for automation versus one-off manual checks. Before execution I share the plan with the developer who built the feature, since they often know an edge case I have not thought of. I also build in a regression pass covering adjacent features that share code paths with the new one. Once testing starts, I track results in Jira against each test case so the coverage is visible to the whole team, not just me.

A good bug report answers three questions before the developer even asks: what did you do, what did you expect, and what actually happened. I include exact steps to reproduce, numbered and specific, the environment (browser version, OS, build number), and a screenshot or short screen recording whenever the bug is visual. I attach relevant logs or console errors rather than describing them from memory. I always state the severity from the user's perspective, not just technical severity: a broken button on a rarely used admin page is not the same priority as a broken checkout button. I avoid vague language like 'sometimes it breaks' and instead note the reproduction rate, for example '8 out of 10 attempts'. If I cannot reproduce it consistently, I say so explicitly rather than letting the developer assume it is a hundred percent reproducible. A clear report saves a developer twenty minutes of back and forth.

I keep a core regression suite that covers the critical user paths and run it against every release candidate, automated where possible so it does not slow the team down. For areas that change often, I maintain a risk map that flags which features share components or data models with the area being changed, so I know what else to check even if it was not directly touched. I rely on the automated suite for coverage breadth and reserve manual regression time for the specific areas the release notes call out as changed. When a release is large, I prioritise regression around anything tied to revenue or account access first, since those are the areas where a missed bug has the highest cost. I also keep the regression suite itself under review, retiring tests for deprecated features so the suite stays fast and relevant rather than growing indefinitely.

We were about to ship a subscription upgrade flow, and the whole team had tested the standard path: free to paid, using a fresh test account. During exploratory testing I tried upgrading an account that already had a cancelled subscription still inside its grace period. The upgrade appeared to succeed in the UI, but the backend created a duplicate subscription record instead of reactivating the existing one, which would have double-billed the customer at renewal. I found it because I deliberately tested an account state nobody had set up before, rather than only the clean-account scenario in the test plan. I filed it as a blocker with the exact account state needed to reproduce it, and the team delayed the release by a day to fix the billing logic. It reinforced for me that test plans built only around the happy path miss the account states that real users actually have after months of use.

I reported a bug where search results returned in the wrong order under specific filter combinations. The developer closed it as 'working as intended', arguing the sort logic was technically correct. I went back to the requirements doc and found the original spec explicitly stated results should sort by relevance first, then date, which is not what the code did. Rather than arguing over Slack, I recorded a short screen capture showing the mismatch next to the spec language, and reopened the ticket with both attached. We then had a five-minute call where he agreed the intent had been misread during implementation. I try to keep these conversations about the documented requirement rather than my personal opinion of what should happen, because that keeps the disagreement factual and quick to resolve. The fix shipped in the next patch, and we added a specific regression test for that filter combination.

A payment confirmation email went out with the wrong currency symbol for a small number of international customers. It passed testing because our test accounts were all set up with a single default region, so the currency formatting bug never triggered in QA. Customer support flagged it within a few hours, and we fixed the formatting logic and issued corrected emails to the affected users the same day. In the post-mortem, I realised our test data did not reflect the real distribution of our user base, which by then included several regions we had launched more recently. I built a set of test accounts covering our top five markets and added currency formatting to the core regression suite so it runs on every release touching billing or email. It changed how I think about test data generally: realistic account diversity matters as much as test case coverage.

For UI automation I have used Selenium and more recently Playwright, and I prefer Playwright for new projects because of its built-in waiting behaviour, which cuts down on the flaky tests that plagued a lot of our older Selenium suite. For API testing I use Postman for exploratory work and quick checks, and I write automated API tests in a framework like REST Assured or Playwright's request API when they need to run in CI. For bug and test case tracking I have worked mainly in Jira, with test cases either in Xray or a lightweight spreadsheet depending on the team's maturity. I choose tools based on what the team already has expertise in unless there is a clear technical reason to switch, since tool churn has a real cost in ramp-up time. When I do propose a new tool, I run a small pilot on one feature area first rather than migrating the whole suite at once.

I start with the API specification or contract, whether that is an OpenAPI document or a shared agreement with the backend developer, and write test cases directly against that. Using Postman or an automated framework, I test the happy path first: valid inputs returning the expected status code and response shape. Then I test edge cases: missing required fields, invalid data types, boundary values, and unauthorized or unauthenticated requests. I check that error responses return useful messages and correct status codes, not just a generic 500. I also test idempotency where relevant, for example confirming that calling a payment endpoint twice with the same request ID does not create a duplicate charge. Once the test suite is solid against the contract, I keep it in the CI pipeline so any backend change that breaks the contract is caught immediately, well before the front end team ever touches it.

I split the suite into tiers by speed and confidence. Unit and fast API tests run on every commit and have to pass before a merge is allowed. A smoke suite covering the critical user paths runs on every pull request against a staging environment, usually in under ten minutes. The full regression suite, which is slower and includes broader UI coverage, runs nightly or before a release candidate is cut, not on every commit, because it would slow the team down too much otherwise. I set the pipeline to fail the build on any smoke test failure but only flag regression failures for review rather than blocking automatically, since a flaky test in a large suite should not stop a release by itself. I also track flaky tests separately and quarantine them until they are fixed, so the team does not lose trust in the suite by seeing the same false failure repeatedly.