Quality is not an act.
It's an automated habit.

Every sprint starts in GitHub. I review GitHub Issues, feature requests, and bug tickets — reading the acceptance criteria, technical discussions, and linked pull requests to understand what's really being asked. Where business rules are ambiguous, I ask questions in the issue thread before development begins, so GitHub Projects reflects a shared, testable definition of done.

Why it matters: Defects prevented at the source instead of caught downstream.

I build the testing strategy from the sprint's GitHub Issues and project board scope — using labels, story points, and board columns to size the effort. I map which existing modules each ticket touches to identify regression impact, set testing priorities by risk, and prepare test data and environments so execution starts on day one of the sprint.

Why it matters: Finite testing time spent where failure costs the most.

I design reusable test scenarios directly from GitHub tickets and user stories — covering positive, negative, edge, and boundary cases, not just happy paths. Each scenario links back to its source issue, giving end-to-end traceability from requirement → test case → defect. AI-assisted tooling helps draft scenario matrices and surface missing edge cases from ticket descriptions before I refine them by hand.

Why it matters: Coverage that holds up under review — traceable and repeatable.

Critical workflows get automated in Playwright with TypeScript and a maintainable POM architecture, while Postman collections validate the API contract — auth, schemas, and error handling the UI can't reach. I organize automation specs around GitHub feature tickets (one spec suite per issue) so the automation stays maintainable and every test traces back to the requirement it validates.

Why it matters: Fast, reliable feedback that scales with every release.

I execute manual and automated suites across development, staging, and regression environments. Findings get recorded against the corresponding GitHub Issue or Pull Request — test results, logs, and screenshots attached where the developers are already working. While executing, I explore beyond the script: the bugs no requirement predicted usually surface here.

Why it matters: Evidence-based go/no-go signal, not gut feel.

GitHub Issues is my defect tracker. Every bug gets a clear, reproducible report: severity, priority, reproduction steps, screenshots, videos, and console/network logs — written so a developer can reproduce it in minutes. I collaborate with developers through issue comments and linked PRs, updating labels and status as fixes land, until I've verified the fix myself.

Why it matters: Faster fixes and a defect history the team can learn from.

I re-test every resolved GitHub Issue before it's considered done, then verify no unintended side effects across related modules — automated regression in Playwright confirms fixes didn't break neighbors, and Postman suite runs confirm API contracts held. Full regression suites run before every deployment, with results tracked back to the sprint's issue list.

Why it matters: Stability across releases without growing manual effort.

Before release, I check the GitHub Projects board: every planned issue is completed, deferred with a reason, or escalated. I confirm critical workflows pass both automation and manual validation, then provide QA sign-off with release risks, known issues, and a testing summary — posted where stakeholders live, with linked evidence from the sprint's issues and PRs. Retrospectives feed improvements back into the next cycle.

Why it matters: Releases backed by evidence, and a process that improves every cycle.