Question 1

Introduce yourself and your testing experience. Do you consider yourself a manual tester, automation tester, or both?

Accepted Answer

Background -> Testing journey -> Specialization + manual/auto ratio -> Standout project. This question is both self-intro and an immediate level gauge. Junior QAs usually say '100% manual', mid-level starts with automation, seniors know how to balance both. I'm not looking for someone who says 'automate everything' - that's a sign they don't truly understand testing. Example of a good answer: 'I've been in testing for 4 years, started manual then gradually moved to automation. Currently about 60% automation for regression, 40% manual for exploratory and UAT. My latest project: set up a Playwright framework for an e-commerce app with 50+ endpoints.' Include numbers: how many test cases, bugs found, coverage percentage.

Question 2

When receiving a new project, how do you build a test strategy and test plan? Differentiate between these two concepts.

Accepted Answer

Strategy (high-level, project-wide) vs Plan (detailed, phase-specific) -> Process -> Deliverables. Many QAs confuse strategy with plan. Test Strategy is a high-level document for the entire project - defining testing approach (risk-based, requirement-based), test levels (unit, integration, system, UAT), automation scope, entry/exit criteria, tools. Test Plan is more detailed for each phase/sprint - specific test cases, schedule, resource assignment, environment setup. Real example: strategy says 'Project uses risk-based testing, focusing 70% effort on payment module as most critical'. Plan says 'Sprint 3: test 45 test cases for checkout flow, assign Hoa for functional, Minh for performance, need staging environment ready by Monday'. Senior QAs get involved from project kickoff to define strategy, not waiting until dev is done - that's shift-left in practice.

Question 3

Have you ever set up an automation framework from scratch? Compare Selenium, Cypress, and Playwright - when would you choose each?

Accepted Answer

Framework experience -> Tool comparison (criteria-based) -> Decision rationale -> Architecture. In 2026, Playwright has surpassed Cypress and Selenium in adoption (around 45% per recent surveys). But no tool is perfect. Selenium still fits when you need multi-browser legacy support or the team has a large existing ecosystem. Cypress excels in developer experience and real-time debugging but is limited to Chromium-based browsers (though Firefox is now supported). Playwright is the all-rounder - multi-browser, multi-language, great auto-waiting, powerful trace viewer for debugging. I want specifics: project structure (Page Object Model or screenplay pattern), how you organize test data, how you handle flaky tests, CI/CD integration. A good framework needs: clear folder structure, reusable utilities, proper reporting, parallel execution, and documentation for new team members.

Question 4

How do you test APIs? Beyond happy path, what do you check? Give an example of an API endpoint and the test cases you would write.

Accepted Answer

Approach -> Tool choice -> Test case categories -> Real endpoint example. Junior QAs test APIs like: send correct request -> get 200 response -> pass. Senior QAs cover: (1) Happy path - correct input, correct output; (2) Negative testing - wrong format, missing fields, null values, SQL injection in input; (3) Boundary testing - string max length, integer overflow, empty array; (4) Auth testing - expired token, wrong role, missing header; (5) Performance - response time within SLA; (6) Idempotency - what happens calling POST twice with same data? Example endpoint POST /api/orders: test successful order creation, test missing product_id, test quantity = 0, test quantity = -1, test user without permission, test concurrent orders. Tools: Postman for manual exploration, REST Assured or Playwright API testing for automation, running in CI.

Question 5

How do you integrate automation tests into a CI/CD pipeline? Share a real pipeline you've set up.

Accepted Answer

Pipeline architecture -> Test stages -> Trigger strategy -> Reporting -> Failure handling. In 2026, a QA who doesn't know CI/CD will struggle to find a job. I want specifics: do you use GitHub Actions, Jenkins, or GitLab CI? When does the pipeline trigger - every PR, merge to develop, or scheduled nightly? How are test stages divided - smoke test first (5 minutes), regression after (30 minutes)? What happens when tests fail - block merge, send Slack notification, or auto-create Jira ticket? Example real pipeline: PR trigger -> lint + unit test (2 min) -> build -> smoke e2e (5 min) -> merge. Nightly: full regression + performance test -> report sent to Slack channel. Senior QAs should also know about test parallelization (sharding), Docker containers for test environments, and managing test data in CI.

Question 6

Have you conducted performance testing? Differentiate load test, stress test, and spike test. What tools do you use and how do you interpret results?

Accepted Answer

Test type definitions -> Tool experience -> Metrics interpretation -> Real bottleneck found. Load test: test with expected user count (e.g., 1000 concurrent). Stress test: gradually exceed capacity to find the breaking point. Spike test: sudden traffic surge (e.g., flash sale). Tools: JMeter is still popular but heavy; k6 (Grafana) is rising fast because it's lightweight, uses JavaScript scripts, and integrates with CI much more easily. 2026 benchmarks show k6 uses 8x less memory than JMeter. Most importantly, how you read results: P95 response time (not average - averages hide outliers), throughput (requests/sec), error rate, and resource utilization (CPU, memory, DB connections). Share a bottleneck you found - like discovering an N+1 query causing 10x slowdown with large data, or connection pool exhaustion at 500 concurrent users.

Question 7

Describe your bug lifecycle. When a developer rejects your bug saying 'works as designed', how do you handle it?

Accepted Answer

Bug lifecycle stages -> Reject scenario -> Evidence-based discussion -> Escalation path. Basic bug lifecycle: New -> Assigned -> In Progress -> Fixed -> Retest -> Closed/Reopened. But the interesting part is handling rejections. This happens daily and tests a QA's EQ. Wrong approach: argue in Jira comments, CC the whole team. Right approach: (1) review the requirement/user story - if the requirement is ambiguous, you might be wrong; (2) if you're right, prepare clear evidence - screenshots, video, logs, exact requirement quotes; (3) discuss directly with the dev first, not via comments; (4) if unresolved, involve BA or PO to clarify requirements; (5) escalate to PM only after exhausting other options. Good QAs pick their battles - not every bug is worth fighting for, but critical bugs require you to stand your ground.

Question 8

What's your understanding of Shift-Left Testing? Share how you've applied it in a real project - not just theory.

Accepted Answer

Concept explanation -> Practical implementation -> Before/after metrics -> Team collaboration. Shift-left isn't a buzzword - in 2026 it's a real hiring requirement. Simple idea: bring testing as early as possible in the SDLC instead of waiting for dev to finish. In practice: (1) QA participates in requirement reviews - catching gaps before dev writes code; (2) QA writes test cases in parallel with dev, based on acceptance criteria; (3) QA reviews PRs - doesn't need to read code in detail but checks logic and edge cases; (4) QA defines Definition of Done for each story. Example: a QA shared that before shift-left, bug density was 15 bugs/sprint; after QA joined sprint planning and reviewed AC, it dropped to 6 bugs/sprint. That's real impact - not pretty presentation slides. Bonus if you know BDD (Behavior-Driven Development) and writing Gherkin scenarios with the PO.

Question 9

How is AI changing testing in 2026? What AI testing tools have you used (Testim, Mabl, Katalon AI, Copilot) and what's your assessment?

Accepted Answer

AI landscape in testing -> Tool experience -> Strengths/limitations -> QA role evolution. This is the hottest question in 2026. AI in testing operates at multiple levels: (1) AI-assisted test generation - Copilot/Gemini writing test code from descriptions; (2) Self-healing locators - Testim, Mabl auto-updating selectors when UI changes; (3) Visual regression AI - Percy, Applitools comparing screenshots smarter than pixel-by-pixel; (4) Predictive analytics - AI analyzing code changes to predict bug-prone areas. A good answer must balance: AI helps generate tests faster, reduces flaky test maintenance, but DOES NOT replace QA thinking - AI doesn't understand user intent, business context, or which test scenarios matter most. QA in 2026 needs to use AI as a multiplier, not a replacement. Be specific: which tool you used, how much effort it saved, limitations encountered.

Question 10

Do you have mobile app testing experience? Compare testing native apps, hybrid apps, and responsive web. Have you used Appium?

Accepted Answer

Mobile testing types -> Platform-specific challenges -> Tool experience -> Device strategy. Mobile testing is much more complex than web due to fragmentation. Native apps (Swift/Kotlin) need per-platform testing, gestures (swipe, pinch), permissions, push notifications, offline mode. Hybrid (React Native, Flutter) can share tests but still need device-specific testing. Responsive web testing on mobile browsers - viewport, touch events, orientation. Tools: Appium remains the standard for mobile automation, but setup is complex. Alternatives: Detox for React Native, XCUITest for iOS, Espresso for Android. Device strategy: you can't test every device - pick top 5-10 based on app analytics data. Use BrowserStack/Sauce Labs for device farms instead of physical devices. Share real experience: how many devices you tested on, platform-specific bugs you caught.

Question 11

Production has a critical bug - users can't make payments. You're the only QA online at that moment. What do you do in the first 30 minutes?

Accepted Answer

Immediate response -> Reproduce -> Communicate -> Assist fix -> Verify -> Post-mortem. This tests crisis handling. The first 30 minutes are critical: (1) 0-5 min: reproduce the bug, confirm severity - does it affect all users or just some? Collect evidence: screenshots, error logs, browser/device info, steps to reproduce; (2) 5-10 min: escalate immediately - ping dev lead + PM on Slack/call, don't wait - include clear impact assessment: 'Payment API returns 500, affecting 100% checkout transactions'; (3) 10-20 min: help dev investigate - check what changed in the latest deploy, compare with staging; (4) 20-30 min: when dev has a hotfix, test on staging IMMEDIATELY, don't skip testing because of urgency. Common mistake: QA panics and documents nothing, or waits until next morning to report. After resolution: write RCA (Root Cause Analysis) and propose regression tests for the payment flow.

Question 12

The PM says 'Only 2 days left, test only the most critical parts'. What do you decide to test and skip? Based on what criteria?

Accepted Answer

Risk-based prioritization -> Criteria (business impact, change frequency, user volume) -> Test selection -> Communication. This is the most realistic scenario in Vietnam outsourcing - never enough testing time. Junior QAs either try to test everything (superficially) or only test happy paths. Good QAs use a risk-based approach: (1) prioritize core business flows - e.g., for e-commerce, checkout + payment must be thoroughly tested; (2) prioritize areas with most code changes in the current sprint; (3) prioritize high user-volume features; (4) skip cosmetic issues, minor UI tweaks. Critical: MUST communicate clearly with PM: 'I will test A, B, C. I will skip D, E with this risk level. Does PM accept this risk?' - that protects you and maintains transparency with stakeholders. Document the decision in the test report. Never silently skip tests and say 'done'.

Question 13

The project has 2000 test cases, regression takes 3 days manually each sprint. How would you plan automation to reduce it to half a day?

Accepted Answer

Current state analysis -> Automation candidate selection -> Phased implementation -> ROI projection. Nobody automates 2000 test cases in one sprint. This is a strategy problem: (1) Analyze 2000 TCs - how many are stable regression, how many face frequent UI changes, how many are data-dependent? (2) Select candidates: 80/20 rule - automate 20% of test cases that cover 80% of critical flows. Usually: login, core business flow, payment, API contracts. (3) Phase plan: Sprint 1-2: setup framework + 100 smoke tests. Sprint 3-6: add 300 regression tests for core modules. Sprint 7+: expand gradually. (4) ROI: each sprint saves 2.5 days manual = 20 man-days/8 sprints. Investment: 1 automation QA for 2-3 months. Break-even around sprint 4-5. Parallel execution (sharding 4 workers) gets 500 tests done in 30 minutes instead of 4 hours. Important: keep exploratory testing manual - don't try to automate everything.

Question 14

In a typical workday, what tools do you use? Walk me through your morning-to-evening workflow.

Accepted Answer

Daily workflow -> Tool per activity -> Integration between tools -> Efficiency tips. Seems simple but reveals a lot. Real QA workflow in 2026: Morning - check Jira board for stories Ready for Test, check CI dashboard (Jenkins/GitHub Actions) for nightly test results, triage failed tests. Mid-morning - exploratory testing or writing/updating automation scripts (VS Code + Playwright). Review test results on Allure/TestRail reports. Noon - 15-min sync with dev on blockers. Afternoon - execute manual test cases (TestRail/Zephyr), log bugs on Jira with video evidence (Loom/OBS), update test coverage report. Late afternoon - review fellow QA's PR, update Confluence test docs. Common tool stack in Vietnam: Jira + TestRail + Postman + Playwright/Selenium + Jenkins/GitHub Actions + Slack. I want to hear how you connect tools - like Jira-TestRail integration for auto-updating test execution status.

Question 15

Beyond functional testing, have you tested non-functional requirements? Give examples of security testing or accessibility testing you've performed.

Accepted Answer

NFR types -> Security testing examples -> Accessibility basics -> Tools used. Many Vietnamese QAs focus only on functional testing and skip non-functional - this is a significant gap. Basic security testing every QA should know: SQL injection (try entering ' OR 1=1 -- in forms), XSS (inject script tags into inputs), IDOR (change user ID in URL to see if you can access others' data), broken authentication (test session expiry, token reuse). You don't need to be a pen tester but must know OWASP Top 10. Accessibility: test with screen readers (VoiceOver/NVDA), check color contrast (WCAG AA minimum 4.5:1), keyboard navigation (tab order), alt text for images. Tools: OWASP ZAP for security scanning, axe DevTools for accessibility audits, Lighthouse for overall audits. In Vietnam, almost nobody does accessibility testing - if you have experience here, it's a huge differentiator.

Question 16

Many people think QA is a stepping stone to become a developer. What's your view on QA career paths and why do you choose to stay in testing?

Accepted Answer

Perspective on QA career -> Personal motivation -> Growth direction (QA Lead, SDET, QA Manager). This helps me understand if you're committed to QA or just passing through. QA career paths in 2026 are very diverse: QA Manual -> QA Automation -> SDET (Software Development Engineer in Test) -> QA Lead -> QA Manager -> Head of Quality. Or specialized: Performance Engineer, Security Tester, AI Test Engineer. Good answer: 'I love testing because every day is detective work - finding bugs devs miss. I'm heading toward SDET to combine coding with a testing mindset. My 2-year goal is QA Lead, managing a team of 5-7.' Bad answer: 'I chose QA because it's easy to enter IT, then I'll switch to dev.' - not inherently bad, but shows you're not investing long-term in this position.

Question 17

What is your expected salary?

Accepted Answer

Market research -> State range -> Justify with skills/certifications -> Total compensation. Be direct, confident, and evidence-based. Vietnam market reference as of August 2026: QA Junior/Fresher (0-2 years) around 10-18M VND/month, QA Mid (2-4 years) around 18-30M, QA Senior/Automation (4-7 years) around 28-50M, QA Lead/Manager (7+) around 40-65M. QA with automation skills earn 30-50% more than manual-only. Additional performance testing or security testing skills add a 15-20% premium. State a range - like '22-28M' - with justification: 'I have 3 years of Playwright automation experience, know CI/CD, and hold ISTQB Foundation certification.' Ask back: review cycle, bonus structure, training budget (especially if the company sponsors ISTQB Advanced). QA who know their worth negotiate differently from those who just say 'up to the company'.

*Note: Salary ranges above are references from Vietnam recruitment market data as of August 2026 (ITviec, TopCV, Glassdoor). Actual figures may vary by company, industry, and location.*

Question 18

Do you have any questions for us?

Accepted Answer

2-3 questions: about QA process, tools, team structure, growth. Good QA questions: (1) About process - 'What test management tool does the current team use? What's the automation coverage? Is there a dedicated QA environment?'; (2) About team - 'What's the QA/Dev ratio? Do QAs participate in sprint planning?'; (3) About challenges - 'What's the QA team's biggest challenge right now? Flaky tests, understaffed, or immature process?'; (4) About growth - 'Is there a path from QA to QA Lead? Does the company support ISTQB certification?'. Bad questions: 'What time can I leave?' or 'Do QAs have to work overtime?'. Good questions show you're evaluating the company's QA maturity - you want to join a team with solid processes, not one where QA is an afterthought.