Manual Testing Interview Questions for 5 Years Experience (28 Q&As)

These manual testing interview questions for 5 years of experience are for senior testers and QA leads (about 3–5 years). The focus moves from executing tests to owning quality: test strategy and metrics, CI/CD quality gates, microservices, accessibility and exploratory testing, leading and mentoring a team, and behavioural questions answered with the STAR method. Replace every bracketed placeholder in the sample answers with your own projects and numbers.

QA Strategy and Quality Metrics

1. What is the Test Pyramid? Why does it matter?

The Test Pyramid is a guideline for balancing test types: a large base of fast, cheap unit tests, a middle layer of integration/API tests, and a small top of slow, expensive E2E tests.

Ideal ratio: 70% unit, 20% integration/API, 10% E2E.

It matters because teams that invert the pyramid — mostly manual E2E tests, few unit tests — end up with slow, fragile, expensive test suites. As a senior QA I advocate for the pyramid shape to ensure the test suite is fast, reliable, and cost-effective.

2. What is Shift-Left Testing? How have you applied it?

Shift-Left testing means involving QA earlier in the development lifecycle — starting at requirements, not at code handoff.

Benefits: bugs found at requirement stage cost 1x to fix. Same bug found in production costs 100x.

How I apply it: I attend requirement reviews to flag ambiguous or untestable requirements. I write acceptance criteria with the BA before sprint starts. I review design documents for testability issues. I write test cases during development — not waiting for the build to arrive. This prevents entire categories of bugs from ever being coded.

3. What is Defect Removal Efficiency? What is a good target?

DRE = (Defects found before production / Total defects) × 100.

Example: 95 bugs found in testing + 5 bugs found in production = DRE of 95/100 = 95%.

A good target is 95% or higher. World-class organisations target 99%+. Below 90% means too many bugs are escaping to production — the QA process needs improvement.

DRE is one of the most important QA metrics because it directly measures how effective the QA process is at preventing production bugs.

4. What metrics do you track as a QA Lead and how do you present them to management?

As a QA Lead or senior tester, your ability to communicate quality through meaningful metrics is as important as the testing itself. Here is a comprehensive guide to testing metrics:

Execution metrics

1. Test Case Execution Rate:

Formula: (Test Cases Executed / Total Test Cases Planned) × 100

Example: 450 executed / 500 planned = 90% execution rate.

Use: Shows how much of the planned testing is complete. Below 100% requires explanation.

2. Test Pass Rate:

Formula: (Test Cases Passed / Total Executed) × 100

Example: 420 passed / 450 executed = 93.3% pass rate.

Use: Indicates stability of the build. <80% usually means the build is not ready.

3. Blocked Test Cases:

Formula: (Blocked / Total) × 100

Use: If 15% of tests are blocked, it highlights environment or dependency issues.

Defect metrics

4. Defect Density:

Formula: (Total Defects Found / Size of Software)

Size can be: Number of modules, function points, lines of code.

Example: 45 bugs found in the Payment module (highest density = most risky module).

Use: Identify defect-prone areas. Focus future testing here.

5. Defect Severity Distribution:

Critical: 5 | High: 15 | Medium: 30 | Low: 25

Use: If you have 5 critical open defects, the release is blocked. Zero criticals = candidate for go-live.

6. Defect Removal Efficiency (DRE):

Formula: (Defects found pre-release / Total defects including post-release) × 100

Example: 90 bugs found in QA, 10 found in production after release.

DRE = 90/100 × 100 = 90%.

Target: >95% DRE is considered excellent. Below 90% = testing processes need improvement.

Use: The gold standard metric for QA effectiveness. Present trend over multiple releases.

7. Defect Leakage Rate:

Formula: (Bugs found in production / Total bugs) × 100

Example: 10 production bugs / 100 total = 10% leakage rate.

Target: <5%.

8. Defect Age:

Average time from defect open to close, per severity.

Example: Critical: avg 2 days, High: avg 5 days, Medium: avg 15 days.

Use: Identify bottlenecks. Are defects aging because development is slow? Business hasn't triaged? Waiting for test environment?

9. Reopened Defects Rate:

Formula: (Reopened Defects / Total Closed Defects) × 100

High rate = developers are fixing without understanding root cause. Or test cases are ambiguous.

Target: <10%.

Coverage metrics

10. Requirements Coverage:

Formula: (Requirements with test cases / Total requirements) × 100

Use: Before test execution — ensure all requirements are testable.

11. Risk Coverage:

Which high-risk areas have been tested vs not tested?

Use: For management decisions on what risks are accepted if testing is cut short.

Presenting metrics to management

Rule 1: Tell a story with metrics, don't just present numbers.

Bad: "We executed 450 tests. Pass rate is 93%. DRE is 90%."

Good: "We're 90% through planned testing with a 93% pass rate, which indicates a stable build. We have 5 critical defects open — all 5 are owned by Dev Team A and are on track to be fixed by Thursday. Our DRE has improved from 87% last release to 90% this release, reflecting our improved regression strategy."

Rule 2: Use RAG (Red/Amber/Green) status.

• Green: On track, no blockers.
• Amber: Minor risk, being managed.
• Red: Significant risk, needs attention/decision.

Rule 3: Use visual dashboards.

• Defect trend graph (defects opened vs closed over time — should converge toward zero near release).
• Test execution burndown chart.
• Risk heatmap by module.

Rule 4: Include a release recommendation.

• "Based on current test results — 98% pass rate, 0 open critical/high defects, 95% DRE — we recommend proceeding with release."
• Or: "We recommend delaying release by 3 days to resolve 2 open critical defects (BUG-234, BUG-567)."

CI/CD and DevOps for QA

5. How does a QA engineer integrate testing into a CI/CD pipeline? Describe in detail.

CI/CD (Continuous Integration/Continuous Delivery) is the backbone of modern software delivery. QA plays a critical role in defining, implementing, and maintaining the quality gates within the pipeline.

THE CI/CD PIPELINE — STAGES AND QA INVOLVEMENT:

Stage 1: CODE COMMIT (Developer pushes code)

QA Involvement

• Pre-commit hooks: Enforce code quality (linting, formatting) before code even enters the repo.
• Pair review: QA reviews acceptance criteria with developer before implementation.

Automated actions: Code is committed to feature branch.

Stage 2: CONTINUOUS INTEGRATION (Build & Unit Tests)

Automated actions triggered by commit

• Code is compiled/built.
• Developer-written unit tests run.
• Code coverage threshold checked (e.g., must be >80%).
• Static code analysis (SonarQube) scans for bugs and vulnerabilities.

QA's role

• Define and maintain minimum code coverage thresholds.
• Review SonarQube quality gate rules.
• If unit tests fail → build is rejected → developer is notified immediately (within minutes).

Stage 3: MERGE/INTEGRATION (Feature branch → Main/Develop)

Automated actions

• Integration tests run — verify the new feature works with other components.
• Contract tests run (Pact) — verify API compatibility is maintained.
• Build artifact is created (Docker image, JAR, etc.).

QA's role

• Write and maintain integration test suite.
• Define contract tests for service boundaries.
• Any failure here blocks the merge.

Stage 4: DEPLOY TO TEST/QA ENVIRONMENT

Automated actions

• Build deployed to QA environment automatically.
• Smoke tests run automatically to verify deployment was successful.
• Full automated regression test suite runs.
• Performance baseline tests may run.

QA's role

• Maintain smoke test suite (critical path scenarios — must be fast, <5 min).
• Maintain and expand automated regression suite.
• Set thresholds: "95% of regression tests must pass for pipeline to proceed."
• Review automated test results and investigate failures.

Stage 5: DEPLOY TO STAGING

Automated actions

• Promote build to staging after QA tests pass.
• Full regression suite runs again on staging (same code, different environment).
• Security scanning (OWASP ZAP, Snyk).
• Performance tests run against production-like data.

Manual QA activities at this stage

• Exploratory testing of new features.
• UAT support.
• Manual verification of complex scenarios automation can't cover.

Stage 6: DEPLOY TO PRODUCTION (CD)

Automated actions

• Canary deployment or blue-green deployment.
• Smoke tests run on production immediately after deployment.
• Synthetic monitoring starts.

QA's role

• Define production smoke tests.
• Monitor alerts for post-deployment issues.
• Have rollback procedure tested and ready.

QUALITY GATES — WHAT THEY ARE AND WHY THEY MATTER:

Quality gates are automated checks that MUST pass before the pipeline proceeds. If a gate fails, the pipeline stops and the team is notified.

Example quality gates

• Unit tests: 100% pass, >80% coverage.
• Security scan: No critical vulnerabilities.
• Integration tests: >95% pass rate.
• Performance: Response time <500ms at 1,000 concurrent users.
• Regression: >98% pass rate.

FLAKY TESTS — THE ENEMY OF CI/CD:

Flaky tests are tests that sometimes pass, sometimes fail without any code change. They destroy trust in the pipeline.

Causes: Timing issues, environment dependencies, test ordering issues, shared test data.

Solutions

• Quarantine flaky tests immediately — remove from main pipeline to a separate "flaky" run.
• Investigate and fix root causes.
• Use retry mechanisms sparingly (max 2 retries).
• Improve test isolation — each test should set up and clean up its own data.

Tools in the ecosystem

• Version Control: Git, GitHub, GitLab, Bitbucket.
• CI Servers: Jenkins, GitHub Actions, GitLab CI, Azure DevOps, CircleCI.
• Containerization: Docker, Kubernetes.
• Test Frameworks: Selenium, Playwright, Cypress, RestAssured, JUnit, TestNG.
• Code Quality: SonarQube, Checkstyle.
• Security: OWASP ZAP, Snyk, Checkmarx.
• Performance: JMeter, Gatling, k6.

6. What is a quality gate in CI/CD?

A quality gate is a pass/fail condition that must be met before a build can proceed to the next stage in the pipeline.

Example quality gates: all unit tests pass (0 failures), code coverage is above 70%, no critical security vulnerabilities in static analysis, automated regression suite has a pass rate above 95%.

If a quality gate fails, the build is blocked — it cannot be deployed to staging or production until the issue is fixed. Quality gates automate enforcement of quality standards without requiring manual sign-off every time.

7. What is Jenkins? How have you used it in your QA work?

Jenkins is an open-source CI/CD automation server that orchestrates build, test, and deployment pipelines.

In my QA work I use Jenkins to: trigger automated regression test runs on every code merge, monitor build results and investigate failures using console output, read JUnit test reports to identify new failures vs pre-existing ones, and receive notifications when a build breaks so I can investigate quickly.

I also review Jenkinsfile pipeline configurations to ensure testing stages are not being bypassed and that the correct test suite is running for each environment.

8. What is a Canary Deployment? Why is it relevant to QA?

A canary deployment releases a new version to a small percentage of real users — typically 1–5% — before rolling out to everyone. The name comes from 'canary in a coal mine' — the canary detects danger early.

It is relevant to QA because: it is a form of Shift-Right testing, catching production bugs with minimal impact. QA monitors error rates, response times, and user-reported issues during the canary phase. If metrics are good, the rollout continues. If issues appear, the canary is rolled back instantly.

I proactively define what metrics to monitor and set alert thresholds before a canary release begins.

9. What is the difference between Continuous Integration, Continuous Delivery, and Continuous Deployment?

Continuous Integration (CI): Developers merge code frequently (multiple times per day). Every merge triggers an automated build and test run. Goal: catch integration bugs early.

Continuous Delivery (CD): The pipeline automatically builds, tests, and prepares a release-ready artifact. Deployment to production requires a MANUAL approval step.

Continuous Deployment: Every code change that passes all pipeline stages is automatically deployed to production — no manual approval. Requires very high confidence in the test suite.

Most organisations practise CI + Continuous Delivery. Full Continuous Deployment is rare and requires a mature, highly automated test suite.

Advanced Testing Areas

10. What unique challenges does microservices architecture present for testers and how do you address them?

Microservices architecture breaks a monolithic application into many small, independently deployable services. While this offers development agility, it creates significant testing complexity.

Challenge 1: DISTRIBUTED TESTING COMPLEXITY

Problem: Testing a single business flow (e.g., placing an order) might span 10+ microservices: API Gateway → Auth Service → Product Service → Inventory Service → Order Service → Payment Service → Notification Service → Analytics Service.

Solution

• Create end-to-end test scenarios that trace complete business flows across services.
• Use distributed tracing tools (Jaeger, Zipkin) to follow requests across services.
• Maintain a service dependency map to understand what calls what.
• Test at multiple levels: unit (per service), contract, integration, and E2E.

Challenge 2: INDEPENDENT DEPLOYMENTS

Problem: Each service can be deployed independently. Service A version 2.0 may break compatibility with Service B version 1.5 that hasn't been updated yet.

Solution: CONTRACT TESTING.

• Pact framework: Define contracts between consumers and providers.
• Consumer tests: "I expect the Order Service to return JSON with these fields."
• Provider verification: Order Service runs Pact tests to verify it still satisfies the contract.
• If Order Service changes its API, Pact immediately detects contract violations before deployment.
• This replaces the need for a full integration environment for compatibility testing.

Challenge 3: TEST ENVIRONMENT COMPLEXITY

Problem: Setting up a full environment with 20+ microservices, each with its own database, is complex and expensive. Local development is nearly impossible.

Solution

• Use Service Virtualization / Mocking: Stub dependent services that are not the focus of your test.
• Tools: WireMock, MockServer, Hoverfly.
• Example: Testing the Order Service — mock the Payment Service to return "payment_success" without needing the real payment infrastructure.
• Consumer-Driven Contract testing reduces need for full integration environments.
• Docker Compose for local testing of related service clusters.

Challenge 4: DATA MANAGEMENT

Problem: Each microservice owns its own database. Data created in Service A isn't directly accessible in Service B's database. Testing data consistency across services is hard.

Solution

• Use dedicated test data setup APIs (test-only endpoints to seed data).
• Understand the event flow — when Order Service publishes an event, verify the Inventory Service consumed it correctly.
• Test eventual consistency: After an event is published, poll until the consumer service updates (with timeout).
• Test saga patterns: Long-running transactions that span services — verify compensation transactions work correctly when one step fails.

Challenge 5: EVENT-DRIVEN ARCHITECTURE TESTING

Problem: Services communicate via events (Kafka, RabbitMQ, SQS). Testing asynchronous message flows is harder than synchronous REST calls.

Solution

• Use message queue monitoring tools to verify messages are published correctly.
• Write consumer tests that verify the service handles messages correctly.
• Test dead letter queues — verify failed messages end up there.
• Test message ordering when it matters.
• Test duplicate message handling (idempotency).

Challenge 6: CASCADING FAILURES

Problem: One service failure can cascade and break multiple downstream services.

Solution

• Test circuit breaker patterns: When Service A fails repeatedly, Service B should "open the circuit" and return a fallback response rather than waiting.
• Test retry logic: Verify services retry appropriate numbers of times with backoff.
• Test timeout handling: Verify services don't hang indefinitely waiting for a slow downstream service.
• Chaos Engineering: Deliberately inject failures (Netflix's Simian Army approach) to verify resilience.

Microservices testing pyramid

• Many unit tests per service (fast, isolated).
• Contract tests between service pairs (catches API compatibility issues).
• Integration tests for critical service clusters.
• Fewer E2E tests (slow, brittle) — only for critical business flows.
• Avoid the "Ice Cream Cone" anti-pattern (many E2E tests, few unit tests).

11. How do you plan and execute exploratory testing sessions professionally?

Professional exploratory testing is far more structured than "random clicking." Session-Based Test Management (SBTM) provides a framework to make exploratory testing measurable, reportable, and manageable.

The session-based exploratory testing framework

Before the session

1. Create Test Charters:

A charter defines the MISSION of the exploratory session.

Format: "Explore [TARGET] using [RESOURCES/TOOLS] to discover [POTENTIAL ISSUES/INFORMATION]"

Example Charters

• "Explore the user profile settings page as a premium user with 10 connected social accounts to discover performance issues, display bugs, and permission errors."
• "Explore the checkout flow on mobile Safari with a promo code applied and an address change mid-flow to discover workflow and validation issues."
• "Explore the admin reporting dashboard using date filters spanning 5+ years to discover data accuracy and performance issues."

2. Define Session Parameters:

• Duration: 45–90 minutes (focus usually drops after about 90 minutes).
• Charter: One per session for focus.
• Tester: Who will run the session.
• Environment and tools needed.

During the session

3. Take Real-Time Notes (Session Notes):

Document continuously

• What you explored (coverage): "Tested all form fields on the profile page."
• What you found (issues): "BUG: Middle name field accepts numbers silently."
• What you couldn't test (obstacles): "Admin section was inaccessible — waited 20 min for permission."
• Ideas and new charters: "Should test bulk upload with 1,000 users — new charter."
• Timing: Note when you switched areas.

4. Bug Logging:

Log defects as you find them during the session — don't wait until the end. Include your exact steps from your notes.

5. Stay On Charter (but be flexible):

Your charter is a guide, not a strict script. If you discover something unexpected that seems important, follow it briefly. Note that you deviated from the charter.

After the session

6. Session Debrief Report (SBTM):

Complete a structured debrief

Session ID: EXP-2024-042

Charter: "Explore checkout with promo codes and address changes."

Duration: 90 minutes.

Time Distribution

• Testing: 65 minutes (72%).
• Bug investigation: 15 minutes (17%).
• Setup/obstacles: 10 minutes (11%).

Test Coverage: Tested single-item checkout, multi-item, digital product, address change before/after promo, free shipping threshold.

Defects Found: 3 (Bug IDs: BUG-456, BUG-457, BUG-458).

Issues/Blockers: Promo code "HOLIDAY20" was not loaded in test environment — had to use "TEST10" instead.

New Charters Identified: "Explore promo code stacking behavior" (new session needed).

Session metrics (for QA Lead tracking)

• Total session hours.
• Bugs found per session hour.
• Coverage percentage of planned charters.
• Tester satisfaction with sessions (did they feel productive?).

TESTING HEURISTICS — TOOLS FOR EXPLORATORY TESTING:

SFDPOT (James Bach) — What areas to explore:

• Structure: Architecture, code, files, database.
• Function: Features, behavior, business rules.
• Data: Inputs, outputs, stored data.
• Platform: OS, browser, hardware, network.
• Operations: Real user workflows, admin tasks.
• Time: Performance over time, timeouts, scheduled events.

HICCUPPS (Michael Bolton) — How to judge if something is wrong:

• History: Does this match what it did before?
• Image: Does this match the company's brand/quality standards?
• Claims: Does this match documentation/specs?
• Comparable: Does this match similar products?
• User Expectations: Would users find this acceptable?
• Product: Is this consistent within the product itself?
• Purpose: Does this serve the stated purpose?
• Statutes: Does this comply with laws and regulations?

Tour-based testing (exploratory tours)

• Feature Tour: Test every feature at least once.
• Complexity Tour: Focus on most complex areas.
• Risk Tour: Focus on highest-risk areas.
• Garbage Tour: Enter all kinds of junk data to test robustness.
• Undo Tour: Test undo/redo/cancel/back button scenarios.
• Variability Tour: Try all possible valid combinations.
• Money Tour: Focus on revenue-critical paths.

12. How do you perform comprehensive accessibility testing and what tools do you use?

Accessibility testing ensures that people with disabilities can use your application effectively. It is increasingly a legal requirement (ADA, Section 508, EN 301 549) and a moral responsibility.

WCAG 2.1 overview

WCAG (Web Content Accessibility Guidelines) is organized around 4 principles (POUR):

Perceivable: Information must be presentable to users in ways they can perceive.

• Text Alternatives: Every non-text content must have alt text.
• Time-based media: Videos need captions, audio descriptions.
• Adaptable: Content can be presented in different ways without losing meaning.
• Distinguishable: Sufficient color contrast (4.5:1 for normal text, 3:1 for large text).

Operable: User interface components must be operable.

• Keyboard Accessible: ALL functionality available via keyboard.
• No Seizures: No content flashes more than 3 times per second.
• Navigable: Users can navigate, find content, determine where they are.
• Enough Time: Users have enough time to read and use content.

Understandable: Information and operation must be understandable.

• Readable: Text is readable and understandable (language set on page).
• Predictable: Pages appear and operate in predictable ways.
• Input Assistance: Users are helped to avoid and correct mistakes (error messages, labels).

Robust: Content must be robust enough to be interpreted by assistive technologies.

• Compatible: Content works with current and future assistive technologies.
• Parsing: Valid, well-structured HTML so screen readers can parse it.

Conformance levels

• Level A (Minimum): Must fix — blocks access for many users with disabilities.
• Level AA (Standard): Should achieve — required by most laws and regulations. Most organizations target this.
• Level AAA (Enhanced): Aspirational — very strict, not always achievable for all content.

Testing categories

1. KEYBOARD NAVIGATION TESTING (Manual):

• Unplug or ignore your mouse entirely.
• Use Tab to navigate forward, Shift+Tab for backward.
• Verify: Every interactive element (links, buttons, forms, menus) is reachable.
• Verify: Focus indicator is clearly visible (not hidden by CSS).
• Verify: Correct tab order (logical, top-to-bottom, left-to-right).
• Verify: Keyboard traps don't exist (can always Tab out of any element).
• Verify: Keyboard shortcuts don't conflict with screen reader shortcuts.
• Test: Custom components (dropdowns, date pickers, modals) work with keyboard.

2. SCREEN READER TESTING (Manual):

Tools: NVDA (Windows, free), JAWS (Windows, paid), VoiceOver (macOS/iOS, built-in), TalkBack (Android, built-in).

What to check

• Images have meaningful alt text (or empty alt="" for decorative images).
• Buttons have descriptive names ("Submit form" not "Click here").
• Form fields have proper labels associated via <label for=""> or aria-label.
• Error messages are announced when validation fails.
• Page titles are descriptive and unique.
• Headings (H1-H6) are used in logical hierarchy for navigation.
• Dynamic content updates are announced (using aria-live regions).
• Tables have proper headers (th) for data tables.
• PDFs are tagged for accessibility.

Common issues found with screen readers

• Icon buttons with no accessible name (just an image, no label).
• Modal dialogs that don't trap focus (screen reader can navigate behind the modal).
• Custom dropdowns that aren't keyboard accessible.
• "Skip to main content" link missing (users can't bypass repetitive navigation).

3. COLOR AND CONTRAST TESTING (Automated + Manual):

Tools: WAVE browser extension, Colour Contrast Analyser (desktop app), Lighthouse.

Minimum ratios (WCAG 2.1 AA): 4.5:1 for normal text, 3:1 for large text (18pt+ or 14pt bold), 3:1 for UI components.

Check: Information not conveyed by color alone (e.g., error fields highlighted only in red with no text label — colorblind users can't tell).

4. AUTOMATED ACCESSIBILITY TESTING:

Tools: axe DevTools (browser extension + API), WAVE, Google Lighthouse (run in Chrome DevTools), Siteimprove, Deque axe-core (integrates with Selenium/Cypress).

What automated tools find well

• Missing alt text on images.
• Missing form labels.
• Color contrast failures.
• Missing page language.
• Duplicate IDs.
• Empty links/buttons.

What automated tools cannot find

• Whether alt text is meaningful (e.g., alt="image1.jpg" passes automation but is meaningless).
• Whether keyboard navigation order is logical.
• Whether screen reader experience is good.
• Complex cognitive accessibility issues.

Note: Automated tools find ~30–40% of accessibility issues. Manual testing is essential.

5. COGNITIVE AND MOTOR ACCESSIBILITY:

• Ensure timeout warnings with option to extend.
• No complex captchas without audio alternative.
• Error messages are specific and explain how to fix the error.
• Consistent navigation across pages.
• Simple, plain language where possible.

Accessibility testing process in projects

1. Include accessibility in Definition of Done — stories must pass accessibility criteria before being marked done.

2. Run automated checks in CI/CD (axe-core integrated with test automation).

3. Manual keyboard and screen reader testing for each major feature.

4. Involve users with disabilities for periodic usability sessions.

5. Create an Accessibility Defect Backlog — log and prioritize findings.

6. Establish which WCAG level you're targeting (usually AA) and document exceptions.

Leadership and Communication

13. How do you build and lead a QA team, and what processes do you establish?

Leading a QA team requires balancing technical excellence, people management, process discipline, and stakeholder communication. Here is a comprehensive approach:

Building the QA team

1. Team Structure Assessment:

• Understand the current team's skills: Who is strong in automation, API testing, domain knowledge, documentation?
• Identify skill gaps based on project needs.
• Plan hiring or training to fill gaps.
• Consider team structure: Embedded QA (within dev squads) vs centralized QA (dedicated QA team serving all squads).

2. Skill Development Plan:

• Create individual learning plans for each team member.
• Identify training resources: courses, certifications (ISTQB), conferences.
• Pair junior testers with seniors for mentoring.
• Assign stretch assignments — give junior testers tasks slightly above their current level.
• Regular 1-on-1s: Monthly meetings to discuss progress, challenges, career goals.

Establishing QA processes

3. Definition of Done (DoD):

Work with the team to define what "done" means for every feature:

• Functional testing complete (all acceptance criteria verified).
• Negative test cases executed.
• Regression tests updated if needed.
• API tests created for new endpoints.
• Accessibility basic check complete.
• Test cases in test management tool (pass/fail recorded).
• No critical/high defects open.
• Code reviewed.

4. Test Case Review Process:

• New test cases are peer-reviewed before execution.
• Review criteria: Covers all ACs, has clear steps, has specific test data, has precise expected results.
• Reduces test case quality issues and knowledge silos.

5. Defect Triage Process:

• Weekly (or as-needed) triage meeting with Dev Lead and PM.
• Review all new defects: validate severity/priority, assign to developer, make defer/fix decisions.
• Clear criteria for what blocks a release vs what can be deferred.

6. Regression Strategy:

• Identify core regression test suite (critical business flows).
• Define regression cadence (run per sprint? per release? per environment?).
• Gradually automate regression to reduce manual effort.
• Track regression pass/fail trends over time.

7. Entry/Exit Criteria for Builds:

Entry to testing: "We will not begin testing a build unless: smoke tests pass, test environment is stable, test data is set up."

Exit from testing: "We recommend release when: 98% test cases pass, 0 open critical/high defects, DRE > 95%, performance benchmarks met."

Mentoring junior testers

8. Code/Test Case Reviews:

• Don't just correct — explain WHY the test case needs changing.
• Ask questions: "What happens if the user enters a number in this name field?"
• Encourage thinking beyond happy path.

9. Shadowing and Pair Testing:

• Have juniors shadow senior testers during exploratory sessions.
• Pair testing on complex features — observe and coach.
• Gradually give them ownership as skills develop.

10. Knowledge Transfer Sessions:

• Regular team sessions: New tool demos, domain knowledge sharing, testing technique workshops.
• Encourage team members to present — builds confidence and deepens their own knowledge.
• Document tribal knowledge: Application architecture, testing gotchas, domain-specific testing rules.

Stakeholder communication

11. Setting Expectations:

• Define clear SLAs for bug fix turnaround times.
• Communicate testing timelines realistically — don't over-promise.
• Provide regular status updates without being asked.
• Be transparent about risks — never hide quality concerns.

12. Advocating for Quality:

• Educate stakeholders that "testing more" without enough time just creates false confidence.
• Push back on unreasonable timelines with data: "Reducing testing from 5 days to 2 days for this feature increases production defect risk by approximately 30% based on our past data."
• Frame quality in business terms: "This critical defect in production would impact X customers and cost $Y in support."

Continuous improvement

13. Retrospectives:

• After each sprint/release, hold QA retrospectives.
• What went well in testing? What was challenging? What defects escaped? Why?
• Action items with owners and due dates.

14. Metrics-Driven Improvement:

• Track DRE, defect leakage, test pass rates over time.
• If DRE drops, investigate why — are requirements unclear? Is coverage insufficient? Regression gaps?
• Set targets and measure progress quarter over quarter.

14. How do you handle a situation where a developer says your bug is 'Not a Bug'?

First I listen to the developer's reasoning without arguing. Sometimes they are right — the behaviour is by design and I misread the requirement.

If I still believe it is a bug, I go back to the requirement document and find the specific section that defines the expected behaviour. I reopen the bug with a clear, fact-based comment: 'Per requirement section 3.2, the expected behaviour is X. The current behaviour is Y. Please advise if the requirement has changed.'

If the requirement is ambiguous, I do not argue — I escalate to the Business Analyst or Product Owner as the final authority on expected behaviour.

I treat every disagreement as a conversation about facts, not a personal dispute. The requirement document is the source of truth — not opinion on either side.

15. How do you report test status to non-technical stakeholders?

I use a simple traffic light system for executive communication: Green = on track, Amber = at risk with a plan, Red = blocked and needs decision.

I lead with the recommendation first: 'The product is ready for release' or 'I recommend we delay by X days to close Y critical issues.'

Then I back it up with simple numbers: 'We executed 450 of 460 test cases (98%). 6 open defects remain — 0 Critical, 2 High, 4 Medium. The 2 High defects have workarounds.'

I avoid technical jargon. I translate quality status into business impact — 'this defect could affect 15% of users at checkout' is more meaningful to a stakeholder than 'severity 2 defect in payment module'.

16. How do you mentor a junior tester who is writing poor test cases?

I first understand the root cause — are they unclear on the feature, or unclear on test case writing technique? These need different fixes.

I review 2–3 of their test cases together, ask them questions rather than just correcting: 'What happens if the user leaves this field empty?' — this builds their own thinking rather than creating dependency.

I share examples of well-written test cases from the project as reference standards.

I give feedback privately, framing it positively: 'These are good positive cases — let's strengthen the negative cases together.' I never criticise publicly.

I set a follow-up checkpoint: 'Write 5 more test cases for this feature and let's review them together on Thursday.' Progress, not perfection immediately.

Behavioural Questions (STAR Answers)

17. Tell me about a time you found a critical bug just before a release. What did you do? (STAR)

Situation: On a sales-management project, one day before a scheduled release, I found a critical defect — the system was allowing duplicate payment submissions, which could result in double-charging users.

Task: I needed to communicate this clearly, ensure it was addressed, and manage the team's expectations about the release timeline.

Action: I immediately documented the bug with full reproduction steps, a screen recording, and database evidence showing duplicate records. I raised it as Critical severity, High priority in Jira and personally notified the developer and QA Lead. I presented two options to the PM: delay release by one day to fix the issue, or deploy with a temporary UI-level workaround while the backend fix was prepared.

Result: The PM chose a one-day delay. The bug was fixed, verified, and the release went ahead the next day without issues. The client was informed of the short delay with a brief explanation — no escalation.

18. Tell me about yourself. (Answer template for QA with 4 years experience)

I am a QA engineer with 4 years of experience across multiple projects in [industry/domain]. I have worked at [Company A] and [Company B], where I was responsible for end-to-end manual testing, API testing using Postman, database validation, and contributing to test planning and documentation.

On my most recent projects — [Project A] and [Project B] at [Company A] — I was involved from requirement review through to test closure, working in Agile Scrum teams with 2-week sprints. I have hands-on experience with Jira for bug tracking, Postman for API testing, and SQL for database verification.

I am now looking for a role where I can continue to grow technically — particularly in automation — while contributing the strong manual and analytical testing skills I have built over 4 years.

19. Why do you want to leave your current company?

Always answer this positively — never speak negatively about your current or previous employer.

Good framework: 'I have had a great learning experience at [company]. I am now looking for [specific growth opportunity] which I believe this role offers. I want to [expand into automation / work on a larger-scale product / grow into a lead role].'

Example: 'At [Company A] I built strong manual testing and API testing skills across multiple projects. I am now looking for a role with greater automation involvement and exposure to a larger-scale application, which this position offers.'

20. Where do you see yourself in 3–5 years?

In 3 years, I want to have strong automation skills in addition to my manual testing foundation — contributing to both manual and automated test suites. I aim to be a senior QA engineer who can own test strategy for a product area.

In 5 years, I see myself in a QA Lead role — mentoring junior testers, designing test processes, and being a key quality voice in product decisions.

I am specifically interested in growing my knowledge of CI/CD integration and performance testing to become a more complete QA professional.

21. What is your biggest weakness?

Choose a real weakness that is not a core QA skill — and always follow with what you are doing about it.

Example: 'My biggest weakness is that I tend to be very thorough — sometimes spending more time than needed on edge cases when the core functionality still needs attention. I have been working on this by using risk-based prioritisation more deliberately — identifying and locking in high-risk test cases first, then adding edge cases within the time remaining.'

Avoid saying: 'I work too hard' (not believable) or 'I am a perfectionist' (overused). Pick something genuine and show growth.

22. What is the most critical bug you ever found?

Structure your answer using STAR format. The bug should be: discovered by you, critical in nature, and have a clear impact if it had reached production.

Example: 'On a sales-management project I discovered that the system was not validating session tokens on the payment confirmation endpoint. This meant that a user who knew the API structure could confirm a payment without actually completing the payment form — a potential payment bypass. I raised this as Critical severity, confirmed it with a Postman test, and escalated immediately to the security team. The fix was prioritised above all other sprint work and deployed within 24 hours.'

If you don't have an exact story, adapt a real bug you found to this structure.

23. What makes a great QA engineer vs a good one?

A good QA engineer executes test cases, finds bugs, and reports them clearly.

A great QA engineer does all of that AND: thinks about quality from the requirement stage (shift-left), uses data to drive decisions (metrics, defect trends), communicates risk clearly to non-technical stakeholders, mentors the team around them, advocates for testability in design and architecture, and treats every release as a business decision — not just a checklist.

A great QA engineer makes the entire team's output better — not just finds bugs in someone else's code.

24. Do you have any questions for us?

Always have 3–4 genuine questions prepared. Never say 'no I think you covered everything.'

Good questions: (1) What does the QA team structure look like — how many testers, what is the ratio to developers? (2) What does the test automation coverage look like today, and where do you want it to be? (3) What is the biggest quality challenge the team is currently facing? (4) How does the QA team involve in the requirement and design phase?

These questions show you are thinking about the role seriously, not just trying to get the offer. They also give you real information to decide if this is the right environment for you.

Senior Scenario Questions

25. How would you test a feature with no requirements document?

First I would not just start testing blindly. I would speak with the Product Owner, Business Analyst, or developer to understand the intended behaviour.

I would look for any existing documentation: user stories, design mockups, previous versions of the feature, competitor products, or acceptance criteria in Jira tickets.

I would then use exploratory testing with a structured charter approach — time-boxed sessions focused on discovering the feature's capabilities and boundaries.

I would also apply error guessing to test common failure points: null inputs, boundary values, concurrent access, and auth.

Finally I would document my findings as informal test scenarios and get them reviewed by the PO — converting them into the de facto requirement for future reference.

26. How would you test a search feature?

Positive: search returns relevant results; partial keyword returns results; case-insensitive search works; search with filters (category, date, price) returns filtered results.

Negative: search with no results shows 'no results' message (not blank page); special characters in search are handled; SQL injection in search field is escaped.

Performance: search with 1 character returns results in under 2 seconds; search on a database with 10 million records performs within SLA.

Edge cases: search with only spaces; search with exactly the maximum character limit; search with a term that matches ALL records.

UX: search suggestions/autocomplete works correctly; pagination works; sorting results (relevance, date, price) works; clear search resets correctly.

27. How would you test a file upload feature?

Positive: upload valid file types (PDF, JPG, PNG) within size limit → success; uploaded file is accessible/downloadable after upload; file name and metadata are preserved.

Negative: upload file exceeding size limit → clear error with limit specified; upload unsupported file type → clear rejection error; upload empty file → handled gracefully.

Security: upload executable files (.exe, .php, .js, .sh) → rejected; upload file with malicious content disguised as an image → rejected or sanitised; verify uploaded files are not accessible via direct URL guessing.

Edge cases: upload file with very long filename; upload file with special characters in filename; upload multiple files simultaneously; upload while on slow network; cancel mid-upload.

Performance: upload large file (near the limit) → completes within acceptable time; upload 10 files in parallel → server handles without error.

28. If production is down, what do you do as the senior QA on call?

First: check monitoring dashboards immediately — error rate, response times, server health. Identify the scope: is it total outage or partial (one feature, one region)?

Second: check what changed recently — was there a deployment in the last few hours? Check the CI/CD pipeline, recent commits, and deployment logs.

Third: attempt to reproduce the issue in staging using the same steps/data as the production report. Document what I find.

Fourth: escalate to the development team with a clear incident summary: what is broken, what changed, evidence (screenshots, logs, error codes), and impact on users.

Fifth: during the fix, monitor the incident channel, verify the fix in staging before it goes to production, and confirm the production issue is resolved after deployment.

Throughout: communicate status updates to stakeholders every 15–30 minutes — even if there is no resolution yet. Silence during an incident is unacceptable.

How to Prepare with 5 Years of Experience

• Bring numbers: defect leakage, DRE, release frequency, time saved by changes you led.
• Prepare four STAR stories: a critical bug, a disagreement, a process you improved and a person you mentored.
• Expect to design a test strategy on a whiteboard for a feature the interviewer describes.
• If you're moving toward automation, see the core manual testing questions alongside the manual-to-automation transition guide.