QA Role

• Requirements / Refinement - Identify untestable requirements, missing edge cases, ambiguous acceptance criteria. Output: testable user stories with clear pass/fail criteria.
• Sprint Planning - Estimate test effort alongside development effort, flag stories needing test environment or data preparation.
• Developer Handoff - Walk through the feature with the developer before formal testing begins. Align on expected behavior, data setup, known caveats.
• Bug Triage - QA, dev, and PM decide severity and priority of open defects. QA provides evidence and impact assessment.
• Release Readiness Review - QA presents test coverage, open defect status, and a go/no-go recommendation.
• Retrospective - Reflect on escaped defects, test suite health, and process improvements.

Best fit to company tech stack from TestRail, Qase, Zephyr, Xray, Tuskr or other compatible test management system.

• HTTP/HTTPS - standard web requests, REST APIs
• WebSocket - real-time bidirectional communication
• gRPC - high-performance binary RPC
• GraphQL - query-based API protocol over HTTP
• MQTT - lightweight pub/sub for IoT
• TCP/UDP - transport layer
• DNS - domain resolution
• TLS/SSL - encryption layer over TCP

Browser DevTools, Wireshark, Charles Proxy

• Functional Testing - ensures features like buttons, forms, and navigation work as intended
• End-to-End (E2E) Testing - simulates a real user journey through the entire application
• API Testing - test backend endpoints directly, independent of the UI
• Session & State Management Testing - test logout, session expiry, multi-tab behavior, back button
• Performance & Load Testing - measures how the app handles high traffic and tests for bottlenecks
• Security Testing - scans for vulnerabilities like SQL injection or XSS
• Usability & Accessibility Testing - verifies accessibility for users with disabilities
• Compatibility Testing - checks across different browsers and devices
• Visual Regression Testing - detects unintended UI changes

I'm in requirement reviews asking "how will we test this?" before implementation starts. I'm in design conversations catching edge cases before they're built in. By the time code reaches formal testing, most of the ambiguity is already resolved.

Developers own unit tests for their own code. QA owns the E2E and regression suites that validate the system as users experience it. Integration coverage sits in between and belongs to whoever has the most context. If developers aren't writing meaningful unit tests, my E2E suite ends up doing work it shouldn't have to.

Quality becomes shared when the definition of done includes it. Done means tested, observable, and ready to ship - not "dev complete and thrown over the wall." That single shared definition changes how developers write tickets, how they hand off features, and how they respond to bug reports.

Bug triage is the clearest test of the relationship. In a good team, it's a joint conversation: QA brings evidence and impact, dev brings implementation context, PM brings priority. Nobody is defending territory. In a broken team, bugs are accusations and triage is negotiation.

The goal isn't a QA department that enforces quality. It's a team where quality is built into how everyone works, and QA is the function that keeps the signal clear.

1. Understand first. Spend time learning how the team actually works. Where does communication break down? Where are bugs coming from? What's breaking in production?
2. Start with a felt problem. Pick the highest-risk area, write test cases for it, and show what coverage looks like in practice. Make the value visible.
3. Shift quality left. Get into requirements and design conversations. Start asking "how will we test this?" as someone who helps the team think through edge cases early - when they're cheap to fix.
4. Introduce tooling incrementally. Start with what gives the most signal fastest: API tests and a basic smoke suite in CI. Once the team sees tests catching real issues, automation becomes easier to advocate for.
5. Automate by impact. High-impact cases first, full regression over time by priority. Sync with developers on keeping conventions and preserving stable data-testid attributes.
6. Make quality a shared definition. Done means tested, observable (logging, alerting, monitoring in place), and ready to ship.

• Prioritize ruthlessly. In a crunch, I'll cut low-signal tests before I cut anything touching payments, auth, or data integrity.
• Name the risk concretely. "We can ship without these tests. Here's what that means: if X breaks in production, we're looking at [time to fix / customer impact / data loss]. Is that a trade-off you want to make?" When the risk is named, the answer usually changes.
• Document everything. If we consciously skip coverage, I log what was skipped and why. That creates a follow-up ticket and makes it a known risk, not a forgotten gap.

The goal is to make sure it's a real decision, not just deadline pressure defaulting into the assumption that QA is optional when things get tight.

• Severity: data loss, security breach, broken core flow, or cosmetic?
• Blast radius: how many users, which paths?
• Is this newly introduced by this release, or was it already in production? A bug that's been in production for three weeks isn't a reason to delay today's release. A bug introduced by this specific build is.

• Feature flag - can the affected area be flagged off so the release goes out without it?
• Rollback plan - how fast and clean is a rollback if we ship and it escalates?
• Hotfix forward - can a fix be deployed within hours, and who stays on call?
• Workaround - is there a user-facing path around the affected flow?

• Data integrity or security: recommend delaying.
• Isolated, non-critical, with a flag or workaround available: present the options with trade-offs and let PM decide.

Either way: document what I found, when I escalated, who made the call, and what the stated trade-off was. If it ships and breaks, that record matters.

I weigh three things: how bad it is when it does hit, the real user volume behind that rate (1/50 on 50k weekly users is 1,000 people affected - not a rounding error), and how reproducible it is. A bug I can't reliably reproduce is one I can't confidently fix or regression-test.

• It causes data loss, corruption, or a financial error - frequency doesn't excuse severity.
• The feature just launched or the root cause looks systemic - a 1/50 symptom can be the visible edge of a deeper problem.

• The impact is cosmetic, traffic is low, or there's a clear workaround.
• Even then: write a repro script and attach it, so the moment it's fixed it becomes a regression test rather than a bug that quietly comes back.

• Irreversible action with no confirmation or undo (delete account with no dialog)
• Error handling is undefined - spec covers the happy path and nothing else
• Performance expectations are technically unrealistic
• The feature will drive support volume because the UX is confusing, even if it works
• Security or compliance implications aren't addressed in the spec

Works as designed. But I push back if:

• A power user's export takes 4 minutes with no feedback and looks frozen
• It silently fails for large accounts with no error message
• The CSV includes PII that shouldn't be in a client-downloadable file
• No rate limiting, so the endpoint can be hammered freely

None of these are bugs against the written spec. The design is just incomplete or unsafe. My job is to surface those gaps and advocate for the user even when the spec doesn't.

• Frame as risk, not refusal: "This will work. Here's what I think happens to users in scenario X."
• Bring data: "Support gets 20 tickets a month on similar flows."
• Propose a minimal fix: "A loading indicator and size warning is 2 hours of dev work."
• Accept the final call if the PM accepts the risk.

This is the core challenge of QA for AI systems. A UI either renders correctly or it doesn't. An API either returns 200 or it doesn't. But when the output is a generated summary, a recommended action, or a test case drafted by an agent, "correct" isn't binary.

The frame I use: turn subjective quality into a measurable loop. Collect examples of outputs that a domain expert marks good and bad, then define criteria that don't ask "is this right?" but "does this stay within an acceptable range across runs? Does it degrade on edge cases?"

• Output consistency - same prompt, similar context, different run: results should stay within a defined threshold. Semantic similarity scoring makes this measurable.
• Prompt regression - when the model or prompt changes, does quality drop? Track delta, not pass/fail.
• Failure mode coverage - hallucinated assertions, tool-loop exhaustion, context degradation at high token counts. Test for known failure classes explicitly.
• Human gate as a quality gate - for high-stakes outputs, HITL isn't a fallback. It's part of the design. Build it in before the output leaves the pipeline, not after something breaks.