Chương 20 Nâng Cao
Phỏng Vấn QA — Chuẩn Bị
Câu hỏi thường gặp, sample answers, STAR method và live testing exercise strategy.
💻 Technical Questions & Answers Required
What is the difference between Severity and Priority?
Severity is the technical impact of a bug on the system — how badly it breaks functionality. It's determined by QA/dev (Critical/Major/Minor/Trivial). Priority is the business urgency to fix it — decided by PM/PO based on user impact, visibility, and business needs. Classic example: a typo on the homepage has Low Severity (cosmetic only) but High Priority (millions of users see it). A crash when uploading a 10GB file has High Severity but Low Priority (almost no user does this). They're independent axes.
What is the difference between Regression Testing and Retesting?
Retesting is running the specific test case that failed after a bug fix — to verify that exact bug is fixed. Regression Testing is a broader re-run of the test suite to ensure the fix hasn't broken other previously working features. Retesting is narrow and targeted; regression is wide. You always do retesting after a fix; regression is typically done after each sprint or build to catch unintended side effects.
What is the difference between Smoke Testing and Sanity Testing?
Smoke testing is done after a new build to verify that the basic, most critical functions work — it's broad and shallow (covers many features quickly). If smoke fails, we reject the build without further testing. Sanity testing is done after a specific fix or small change to verify that the changed area works correctly — it's narrow and deep (focused on the changed area). Smoke checks "is the build testable?" Sanity checks "does this specific fix work?"
What is RTM and why is it important?
RTM — Requirement Traceability Matrix — is a document that maps each requirement to its test cases and tracks execution status. It's important for three reasons: 1) Coverage assurance — every requirement has test coverage, no gaps; 2) Impact analysis — when a requirement changes, you know exactly which test cases to update; 3) Audit trail — in regulated industries, you must prove every requirement was tested. Without RTM, you're guessing about coverage and can't quantify testing completeness.
When should you stop testing?
Testing never reaches 100% — you stop when the risk is acceptable. Factors: (1) Test coverage target achieved (e.g., 95% of test cases executed); (2) Pass rate above threshold (e.g., 90%+); (3) No Critical or Major bugs open; (4) Diminishing returns — only finding trivial bugs; (5) Deadline reached with stakeholder acceptance of known risks. I always document what was NOT tested and why, so stakeholders can make informed deployment decisions.
What do you do when a developer says "it's not a bug, it's by design"?
First, I go back to the source of truth — the spec, user story, or acceptance criteria. If the spec clearly defines the expected behavior differently than what the dev says → I have a reference. I share it calmly: "Per AC-003, the expected behavior is X. The current behavior is Y — this appears to be a defect." If the spec is ambiguous, I propose a 3-Amigos meeting with the BA to clarify. I never close a bug just because a dev disagrees — if there's genuine disagreement, it gets escalated for a decision. The goal is to resolve the ambiguity, not win an argument.
⭐ Behavioral Questions — STAR Method
STAR = Situation → Task → Action → Result
Tell me about a time you found a critical bug close to a release deadline.
S: During Sprint 12, one day before our scheduled production deployment.
T: I was doing final regression on the checkout flow.
A: I discovered that when users applied a percentage discount AND had a subscription item in cart, the total was calculated incorrectly — users were being undercharged by 30%. I documented it thoroughly, immediately escalated to PM and dev lead via Slack, and continued testing other areas while waiting for their response.
R: The team made the call to delay the release by one day. The bug was fixed and verified within 4 hours. We prevented a revenue-impacting issue from reaching production. The stakeholders appreciated the early alert that gave us time to react.
T: I was doing final regression on the checkout flow.
A: I discovered that when users applied a percentage discount AND had a subscription item in cart, the total was calculated incorrectly — users were being undercharged by 30%. I documented it thoroughly, immediately escalated to PM and dev lead via Slack, and continued testing other areas while waiting for their response.
R: The team made the call to delay the release by one day. The bug was fixed and verified within 4 hours. We prevented a revenue-impacting issue from reaching production. The stakeholders appreciated the early alert that gave us time to react.
Describe a situation where you disagreed with a developer about a bug.
S: I reported a bug where the search results showed expired products to users.
T: The dev said it was "by design" — the spec didn't explicitly say expired products should be hidden.
A: I acknowledged his point and didn't argue directly. Instead, I requested a 15-minute call with the BA to clarify the intent. In the call, the BA confirmed that showing expired products was indeed an oversight in the spec. I suggested a quick fix and updated the spec as well.
R: The bug was fixed, the spec was updated, and both the dev and I agreed. No conflict — just a clarification process. The key was focusing on the spec, not on who was "right."
T: The dev said it was "by design" — the spec didn't explicitly say expired products should be hidden.
A: I acknowledged his point and didn't argue directly. Instead, I requested a 15-minute call with the BA to clarify the intent. In the call, the BA confirmed that showing expired products was indeed an oversight in the spec. I suggested a quick fix and updated the spec as well.
R: The bug was fixed, the spec was updated, and both the dev and I agreed. No conflict — just a clarification process. The key was focusing on the spec, not on who was "right."
How have you improved a testing process?
S: Our team was spending 8 hours every sprint running the same 80 smoke test cases manually.
T: As QA lead, I was responsible for testing efficiency.
A: I proposed automating the smoke test suite using Playwright. I wrote the initial 80 automated tests over 2 sprints and trained one junior QA on maintenance.
R: The automated suite runs in 12 minutes in CI, replacing 8 hours of manual work. That's 32+ hours saved per month. We redirected that time to exploratory testing and found 3 critical bugs in the next sprint that we'd been missing previously.
T: As QA lead, I was responsible for testing efficiency.
A: I proposed automating the smoke test suite using Playwright. I wrote the initial 80 automated tests over 2 sprints and trained one junior QA on maintenance.
R: The automated suite runs in 12 minutes in CI, replacing 8 hours of manual work. That's 32+ hours saved per month. We redirected that time to exploratory testing and found 3 critical bugs in the next sprint that we'd been missing previously.
🎓 Senior-level Questions
How would you design a test strategy for a new microservices-based product?
I'd structure it in layers: (1) Unit tests — dev-owned, per service; (2) Contract testing — Pact.io to ensure API contracts between services are maintained; (3) Integration tests — key service-to-service flows (order service + inventory service + notification service); (4) E2E tests — critical user journeys (registration, checkout, order tracking) using Playwright; (5) Performance tests — load tests per service + full system; (6) Security — OWASP scanning, auth testing. I'd also define quality gates for each layer in the CI pipeline and establish clear ownership (dev vs QA vs shared).
How do you build a business case for investing in test automation?
I present ROI data: (1) Current manual regression cost: X test cases × Y minutes each × Z sprints per year = total hours. (2) Automation one-time cost: development time + tool cost. (3) Automation ongoing cost: maintenance (estimate 20-30% of development time per year). (4) Break-even point: when savings exceed investment — typically 6-12 months. Beyond numbers, I emphasize quality benefits: faster feedback (hours vs days), run at 3 AM before business hours, consistent execution, and enables CI/CD. I'd also point to specific recent bugs that were missed due to manual regression constraints.
🖥️ Live Testing Exercise — Playbook
Khi được yêu cầu "test website này ngay bây giờ," dùng approach sau:
- Clarify (2 phút): "Tôi có bao nhiêu thời gian? Focus vào feature nào? Có known issues không? User persona là ai?"
- Think aloud: Nói to tư duy đang làm. Interviewer chấm tư duy, không chỉ bugs tìm được.
- Explore quickly (5 phút): Scan qua tất cả features — không deep-dive ngay. Ghi mental note: what's here, what seems risky.
- Happy Path first (10 phút): Complete the main user journey từ đầu đến cuối. Log mọi vấn đề theo từng step.
- Negative tests (10 phút): Empty inputs, invalid data, boundary values, error paths.
- Edge cases (5 phút): Special characters, concurrent actions, browser back button, session behavior.
- Cross-cutting (3 phút): Quick check responsiveness, console errors, HTTPS, basic accessibility (keyboard navigation).
- Summarize (3 phút): "In 30 minutes I tested [list areas]. Found [N] issues: [list by severity]. Areas I didn't cover: [list]. If I had more time I'd focus on [X]."
💡 What Interviewers Look For
Systematic approach (not random clicking), ability to think aloud, prioritization, communicating tradeoffs (what you chose and why), and professionalism when finding issues. Finding the most bugs is less important than demonstrating good testing methodology.
🙋 Câu Hỏi Nên Hỏi Nhà Tuyển Dụng
- "What does a typical QA engineer's day look like in a sprint?" — Hiểu daily work thực tế
- "What is the current ratio of manual to automated testing? What are the plans to grow automation?" — Assess technical maturity
- "How is QA embedded in the team — centralized QA team or embedded in scrum teams?" — Culture and collaboration
- "What testing tools does the team currently use?" — Assess tooling and learning curve
- "What does success look like for a QA engineer in the first 3/6 months?" — Understand expectations
- "What is the biggest quality challenge the team is currently facing?" — Shows strategic thinking
- "How does the team handle tech debt and regression coverage?" — Assess process maturity
- "Can you tell me about a time a bug made it to production and how the team responded?" — Culture of blamelessness vs blame
✏️ Bài Tập
📝 Bài Tập: Mock Interview Preparation
- Viết đầy đủ STAR answer cho: "Tell me about a time you had to test something with very little documentation or requirements."
- Chuẩn bị 5 technical questions phổ biến nhất và luyện nói to câu trả lời trong 2 phút mỗi câu.
- Thực hành live testing: Mở một web app bạn chưa test trước đây (e.g., một website thương mại điện tử bất kỳ). Set timer 30 phút. Document mọi thứ bạn làm theo format: Step | What I Did | What I Found.
- Viết 5 câu hỏi bạn sẽ hỏi interviewer cho một Senior QA Engineer role tại một startup fintech.