SoftwareTestPilot
38 Q&A · Pillar · Freshers → Senior

Software Testing Interview Questions and Answers (2026)

The complete pillar: 38 top interview questions across fundamentals, manual, automation, API + SQL, SDET, Agile/CI-CD and scenario-based rounds.

  • 40 min read
  • Difficulty: Mixed (Easy → Hard)
  • Freshers · 1–10+ YOE
  • Updated July 2026
  • Avinash Kamble
Browse All Q&A Hubs
Avinash Kamble
Founder & QA Engineer at SoftwareTestPilot
Published:
0 / 172 reviewed
0%

1. Fresher (0–1 yrs)

Medium Very Common 1 minQ1 / 172

Q1.What is software testing?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

Interviewers open with "software testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Software testing is the process of evaluating a software application to detect defects, verify it meets specified requirements, and validate it satisfies real user needs. It reduces production risk, protects brand reputation, and lowers the cost of change by finding issues early.

It combines verification (are we building it right?) and validation (are we building the right thing?).

Tips to remember
  • Open with a one-sentence definition of software testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise software testing cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ3
Q2 →
Easy Very Common 1 minQ2 / 172

Q2.Why is software testing important?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

"Why" questions on software testing important probe your reasoning, not your memory. Strong candidates connect the choice to a business or reliability outcome — flaky tests, slower feedback loop, or missed defects — instead of parroting a rule.

Detailed explanation

Testing prevents costly production failures, ensures compliance in regulated industries (banking, healthcare), protects user data, and validates that features match business intent. Studies (IBM Systems Sciences Institute) show a defect found in production costs 100× more to fix than one caught during design.

Tips to remember
  • Tie the "why" for software testing important back to a measurable outcome — flake rate, execution time, defect leakage — instead of an opinion.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise software testing important cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ4
← Q1Q3 →
Easy Very Common 1 minQ3 / 172

Q3.What is the difference between verification and validation?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Interviewers open with "difference between verification and validation" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Verification checks the product is built to specification — reviews, walkthroughs, inspections, static analysis. Validation checks the product meets user needs — functional testing, UAT, beta testing. Verification = right process; validation = right product.

Tips to remember
  • Open with a one-sentence definition of difference between verification and validation, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise difference between verification and validation cleanly.
RelatedQ1Q5
← Q2Q4 →
Easy Very Common 1 minQ4 / 172

Q4.What is the difference between quality assurance, quality control, and testing?

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Interviewers open with "difference between quality assurance, quality control, and testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

QA is process-focused and preventive (standards, audits, methodology). QC is product-focused and corrective (inspection, defect identification). Testing is one activity inside QC that executes the software to uncover defects.

Tips to remember
  • Open with a one-sentence definition of difference between quality assurance, quality control, and testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise difference between quality assurance, quality control, and testing cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ2Q6
← Q3Q5 →
Easy Very Common 1 minQ5 / 172

Q5.What is a test case?

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

Interviewers open with "test case" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

A test case is a documented set of steps, inputs, preconditions, and expected results used to verify a specific feature or requirement. A well-written test case is atomic, repeatable, traceable to a requirement, and independent of other cases.

Tips to remember
  • Open with a one-sentence definition of test case, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise test case cleanly.
  • Say who reads the report and what decision it drives — evidence-for-humans framing beats a tool name list.
RelatedQ3Q7
← Q4Q6 →
Easy Very Common 1 minQ6 / 172

Q6.What is a test scenario?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

Interviewers open with "test scenario" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

A test scenario is a high-level description of what to test — one sentence per business flow (e.g., "verify a user can add an item to cart"). One scenario expands into many test cases covering positive, negative, and edge inputs.

Tips to remember
  • Open with a one-sentence definition of test scenario, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise test scenario cleanly.
  • Apply the technique live to a small example (a login field, an age input) instead of only naming it.
RelatedQ4Q8
← Q5Q7 →
Easy Very Common 1 minQ7 / 172

Q7.What is a test plan?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

Interviewers open with "test plan" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

A test plan is a formal document that defines scope, approach, resources, schedule, entry/exit criteria, risks, and deliverables for a testing project. IEEE 829 is the classic template; modern teams condense it into a one-page Confluence brief.

Tips to remember
  • Open with a one-sentence definition of test plan, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise test plan cleanly.
RelatedQ5Q9
← Q6Q8 →
Easy Very Common 1 minQ8 / 172

Q8.What is the difference between static and dynamic testing?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

Interviewers open with "difference between static and dynamic testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Static testing examines artifacts without executing code — reviews, walkthroughs, static analysis (SonarQube). Dynamic testing executes the code with inputs and observes behavior — unit, integration, system, UAT.

Tips to remember
  • Open with a one-sentence definition of difference between static and dynamic testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise difference between static and dynamic testing cleanly.
RelatedQ6Q10
← Q7Q9 →
Easy Very Common 1 minQ9 / 172

Q9.What is SDLC?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

Interviewers open with "SDLC" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

The Software Development Life Cycle covers all phases of building software: Requirements → Design → Implementation → Testing → Deployment → Maintenance. Common models include Waterfall, V-Model, Iterative, Spiral, and Agile.

Tips to remember
  • Open with a one-sentence definition of SDLC, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise SDLC cleanly.
  • Anchor the answer to a ceremony and an artefact (definition of done, story acceptance criteria) from a team you worked in.
RelatedQ7Q11
← Q8Q10 →
Easy Very Common 1 minQ10 / 172

Q10.What is STLC?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

Interviewers open with "STLC" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

The Software Testing Life Cycle is the sequence of QA activities: Requirement Analysis → Test Planning → Test Case Design → Test Environment Setup → Test Execution → Test Closure. Each phase has entry and exit criteria.

Tips to remember
  • Open with a one-sentence definition of STLC, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise STLC cleanly.
  • Explain setup/teardown ordering and what runs per-test vs per-suite; ordering mistakes are the follow-up question.
RelatedQ8Q12
← Q9Q11 →
Easy Very Common 1 minQ11 / 172

Q11.What is the difference between SDLC and STLC?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Interviewers open with "difference between SDLC and STLC" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

SDLC covers the full software build, of which testing is one phase. STLC zooms into only the QA activities and runs in parallel with the SDLC's test phase, but with its own planning, design, execution, and closure steps.

Tips to remember
  • Open with a one-sentence definition of difference between SDLC and STLC, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise difference between SDLC and STLC cleanly.
  • Call out test isolation and shared-state risk (data, sessions, ports) before you talk about worker counts.
RelatedQ9Q13
← Q10Q12 →
Easy Very Common 1 minQ12 / 172

Q12.Explain the V-Model.

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Open-ended "explain V-Model" prompts test how you structure a technical answer under pressure. Panels look for a clear opening definition, one worked example, and a closing sentence on the pitfall they were about to ask about next.

Detailed explanation

The V-Model pairs each development phase with a corresponding test level: requirements ↔ acceptance testing, system design ↔ system testing, architecture ↔ integration testing, module design ↔ unit testing. Testing activities begin as early as requirements are written.

Tips to remember
  • Use a 3-part frame for V-Model: what it is → how it works → one gotcha you've hit in a real Software Testing project.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise V-Model cleanly.
RelatedQ10Q14
← Q11Q13 →
Easy Very Common 1 minQ13 / 172

Q13.What is Agile testing?

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

Interviewers open with "Agile testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Agile testing is continuous testing embedded in sprints — testers pair with developers on story acceptance, write automated checks each sprint, and rely on techniques like BDD (Given-When-Then), TDD, and exploratory testing. There is no separate "test phase."

Tips to remember
  • Open with a one-sentence definition of Agile testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Agile testing cleanly.
  • Anchor the answer to a ceremony and an artefact (definition of done, story acceptance criteria) from a team you worked in.
RelatedQ11Q15
← Q12Q14 →
Easy Very Common 1 minQ14 / 172

Q14.What are entry and exit criteria?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

Interviewers open with "entry and exit criteria" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Entry criteria define what must be true before a phase can start (e.g., "unit test coverage ≥ 80% before system testing"). Exit criteria define what must be true before it can end (e.g., "zero P1 open, ≤ 5 P2 open").

Tips to remember
  • Open with a one-sentence definition of entry and exit criteria, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise entry and exit criteria cleanly.
RelatedQ12Q16
← Q13Q15 →
Easy Very Common 1 minQ15 / 172

Q15.What is boundary value analysis?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

Interviewers open with "boundary value analysis" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Boundary Value Analysis (BVA) tests values at the edges of valid ranges — the minimum, maximum, just-below-min, and just-above-max. For an age field accepting 18–60, tests use 17, 18, 60, 61. Bugs cluster at boundaries.

Tips to remember
  • Open with a one-sentence definition of boundary value analysis, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise boundary value analysis cleanly.
  • Apply the technique live to a small example (a login field, an age input) instead of only naming it.
RelatedQ13Q17
← Q14Q16 →
Easy Very Common 1 minQ16 / 172

Q16.What is equivalence partitioning?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

Interviewers open with "equivalence partitioning" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Equivalence Partitioning (EP) divides input data into partitions where the system is expected to behave the same, then tests one representative from each. For age 18–60: one value from <18 (invalid), 18–60 (valid), >60 (invalid) — three tests instead of 100.

Tips to remember
  • Open with a one-sentence definition of equivalence partitioning, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise equivalence partitioning cleanly.
  • Apply the technique live to a small example (a login field, an age input) instead of only naming it.
RelatedQ14Q18
← Q15Q17 →
Easy Very Common 1 minQ17 / 172

Q17.What is decision table testing?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

Interviewers open with "decision table testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

A decision table captures combinations of inputs and expected outputs in a matrix — used when business rules have multiple conditions (e.g., loan approval based on age, income, credit score). Every column becomes one test case, guaranteeing full logical coverage.

Tips to remember
  • Open with a one-sentence definition of decision table testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise decision table testing cleanly.
  • Apply the technique live to a small example (a login field, an age input) instead of only naming it.
RelatedQ15Q19
← Q16Q18 →
Easy Very Common 1 minQ18 / 172

Q18.What is state transition testing?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

Interviewers open with "state transition testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

State transition testing models the system as states (Logged-Out, Logged-In, Locked) and transitions (login, logout, 3 failed attempts). Tests cover valid paths, invalid transitions, and boundary states — ideal for authentication, workflows, and finite state machines.

Tips to remember
  • Open with a one-sentence definition of state transition testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise state transition testing cleanly.
  • Cover token expiry and refresh in your answer; most candidates only describe the happy-path login.
RelatedQ16Q20
← Q17Q19 →
Easy Very Common 1 minQ19 / 172

Q19.What is use case testing?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Interviewers open with "use case testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Use case testing derives test cases from actor-system interactions. Each use case has a main flow and alternate/exception flows; each flow becomes at least one test. Useful for validating end-to-end business scenarios during UAT.

Tips to remember
  • Open with a one-sentence definition of use case testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise use case testing cleanly.
  • Apply the technique live to a small example (a login field, an age input) instead of only naming it.
RelatedQ17Q21
← Q18Q20 →
Easy Very Common 1 minQ20 / 172

Q20.What is exploratory testing?

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Interviewers open with "exploratory testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Exploratory testing is simultaneous learning, test design, and execution — the tester uses domain knowledge and heuristics to probe the system without scripted steps. Structured via session-based test management (SBTM) with charters and time-boxed sessions.

Tips to remember
  • Open with a one-sentence definition of exploratory testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise exploratory testing cleanly.
  • Apply the technique live to a small example (a login field, an age input) instead of only naming it.
RelatedQ18Q22
← Q19Q21 →
Easy Very Common 1 minQ21 / 172

Q21.What is ad-hoc testing?

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

Interviewers open with "ad-hoc testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Ad-hoc testing is informal, unscripted testing without a plan or documentation — the tester randomly explores the app to find defects. Unlike exploratory testing, it has no charter and is not reproducible.

Tips to remember
  • Open with a one-sentence definition of ad-hoc testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise ad-hoc testing cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ19Q23
← Q20Q22 →
Easy Very Common 1 minQ22 / 172

Q22.What is error guessing?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

Interviewers open with "error guessing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Error guessing is an experience-based technique where testers use domain knowledge to predict likely defect locations — empty fields, zero values, special characters, session timeouts. It complements formal techniques like BVA and EP.

Tips to remember
  • Open with a one-sentence definition of error guessing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise error guessing cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ20Q24
← Q21Q23 →
Easy Very Common 1 minQ23 / 172

Q23.What is a defect (bug)?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

Interviewers open with "defect (bug)" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

A defect is any deviation of the software from expected behavior — a missing feature, wrong result, crash, or usability issue. Formally: a variance between actual and expected result.

Tips to remember
  • Open with a one-sentence definition of defect (bug), then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise defect (bug) cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ21Q25
← Q22Q24 →
Easy Very Common 1 minQ24 / 172

Q24.Explain the defect life cycle.

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

Open-ended "explain defect life cycle" prompts test how you structure a technical answer under pressure. Panels look for a clear opening definition, one worked example, and a closing sentence on the pitfall they were about to ask about next.

Detailed explanation

Standard flow: New → Assigned → Open → Fixed → Retest → Verified → Closed. Alternate states: Rejected (not a defect), Deferred (fix later), Duplicate, Reopened (regression after fix). Tracked in Jira, Azure DevOps, or Bugzilla.

Tips to remember
  • Use a 3-part frame for defect life cycle: what it is → how it works → one gotcha you've hit in a real Software Testing project.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise defect life cycle cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ22Q26
← Q23Q25 →
Easy Very Common 1 minQ25 / 172

Q25.What is the difference between severity and priority?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

Interviewers open with "difference between severity and priority" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Severity = impact on the system (Critical → Cosmetic). Priority = urgency of fix (P1 → P4). A company logo missing on the homepage is low severity but high priority; a crash on a rarely used admin screen is high severity but low priority.

Tips to remember
  • Open with a one-sentence definition of difference between severity and priority, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise difference between severity and priority cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ23Q27
← Q24Q26 →
Easy Very Common 1 minQ26 / 172

Q26.What information should a good bug report contain?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on What information should a good bug report contain and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

A quality bug report includes: title, environment (browser, OS, build), preconditions, exact reproduction steps, actual result, expected result, severity, priority, screenshots/videos, console/network logs, and reproducibility rate. Assume the developer has never seen the feature.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on What information should a good bug report contain over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise What information should a good bug report contain cleanly.
  • Say who reads the report and what decision it drives — evidence-for-humans framing beats a tool name list.
RelatedQ24Q28
← Q25Q27 →
Easy Very Common 1 minQ27 / 172

Q27.What is a critical defect vs a blocker?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Interviewers open with "critical defect vs a blocker" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

A blocker stops further testing (login broken, environment down). A critical defect causes major functionality failure or data loss but testing can continue on other modules. Blockers get immediate escalation.

Tips to remember
  • Open with a one-sentence definition of critical defect vs a blocker, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise critical defect vs a blocker cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ25Q29
← Q26Q28 →
Easy Very Common 1 minQ28 / 172

Q28.What is a defect leakage?

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Interviewers open with "defect leakage" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Defect leakage is a defect that escapes to a later stage — for example, a bug missed in system testing found by the customer in UAT or production. QA metrics track leakage % to measure test effectiveness.

Tips to remember
  • Open with a one-sentence definition of defect leakage, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise defect leakage cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ26Q30
← Q27Q29 →
Easy Very Common 1 minQ29 / 172

Q29.What is the difference between smoke and sanity testing?

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

Interviewers open with "difference between smoke and sanity testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Smoke testing is a shallow, wide check on a new build — do the core flows work? Runs first, before regression. Sanity testing is a narrow, deep check on a specific area after a bug fix or small change. Both are subsets of regression testing.

Tips to remember
  • Open with a one-sentence definition of difference between smoke and sanity testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise difference between smoke and sanity testing cleanly.
RelatedQ27Q31
← Q28Q30 →
Easy Very Common 1 minQ30 / 172

Q30.What is regression testing?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

Interviewers open with "regression testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Regression testing re-runs existing test cases after a code change to confirm nothing that used to work is now broken. It is the primary use case for automation because it repeats every release.

Tips to remember
  • Open with a one-sentence definition of regression testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise regression testing cleanly.
  • Apply the technique live to a small example (a login field, an age input) instead of only naming it.
RelatedQ28Q32
← Q29Q31 →
Easy Very Common 1 minQ31 / 172

Q31.What is functional vs non-functional testing?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

Interviewers open with "functional vs non-functional testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Functional testing verifies what the system does — features, business rules, error handling. Non-functional testing verifies how well it does it — performance, security, usability, reliability, compatibility.

Tips to remember
  • Open with a one-sentence definition of functional vs non-functional testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise functional vs non-functional testing cleanly.
  • Use percentiles (P90/P95) and a concrete SLA rather than averages — averages hide the failures interviewers care about.
RelatedQ29Q33
← Q30Q32 →
Easy Very Common 1 minQ32 / 172

Q32.What is black-box, white-box, and grey-box testing?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

Interviewers open with "black-box, white-box, and grey-box testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Black-box tests based on inputs and outputs without seeing code (functional QA). White-box tests based on code structure (unit tests, code coverage). Grey-box combines both — tester knows internals but tests from the outside (API + DB testing).

Tips to remember
  • Open with a one-sentence definition of black-box, white-box, and grey-box testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise black-box, white-box, and grey-box testing cleanly.
RelatedQ30Q34
← Q31Q33 →
Easy Very Common 1 minQ33 / 172

Q33.What is UAT (User Acceptance Testing)?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

Interviewers open with "UAT (User Acceptance Testing)" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

UAT is the final phase where actual end users or business stakeholders validate the product against real-world scenarios and business requirements. Two forms: Alpha (in-house users) and Beta (external users in production-like environment).

Tips to remember
  • Open with a one-sentence definition of UAT (User Acceptance Testing), then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise UAT (User Acceptance Testing) cleanly.
RelatedQ31Q35
← Q32Q34 →
Easy Very Common 1 minQ34 / 172

Q34.What is performance testing?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

Interviewers open with "performance testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Performance testing measures response time, throughput, and stability under load. Sub-types: Load (expected load), Stress (beyond capacity), Spike (sudden burst), Endurance/Soak (sustained load over hours). Tools: JMeter, k6, Gatling.

Tips to remember
  • Open with a one-sentence definition of performance testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise performance testing cleanly.
  • Use percentiles (P90/P95) and a concrete SLA rather than averages — averages hide the failures interviewers care about.
RelatedQ32Q36
← Q33Q35 →
Easy Very Common 1 minQ35 / 172

Q35.What is security testing?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Interviewers open with "security testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Security testing uncovers vulnerabilities that could allow unauthorized access, data theft, or service disruption. Covers OWASP Top 10 (SQL injection, XSS, CSRF, broken auth), penetration testing, and static/dynamic analysis (SAST/DAST).

Tips to remember
  • Open with a one-sentence definition of security testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise security testing cleanly.
  • Reference the specific OWASP category and the check you automate for it, not "we do security testing".
RelatedQ33Q37
← Q34Q36 →
Easy Very Common 1 minQ36 / 172

Q36.What is automation testing?

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Interviewers open with "automation testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Automation testing uses scripts and tools to execute tests automatically, compare actual vs expected results, and report outcomes. Best for regression suites, data-driven scenarios, and load testing. Not a replacement for exploratory or usability testing.

Tips to remember
  • Open with a one-sentence definition of automation testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise automation testing cleanly.
  • Use percentiles (P90/P95) and a concrete SLA rather than averages — averages hide the failures interviewers care about.
RelatedQ34Q38
← Q35Q37 →
Easy Very Common 1 minQ37 / 172

Q37.What is the difference between manual and automation testing?

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

Interviewers open with "difference between manual and automation testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Manual testing is human-driven, slow but flexible — ideal for exploratory, UX, and one-off validation. Automation is script-driven, fast and repeatable — ideal for regression, smoke, and load. Modern teams use both: automate stable flows, manually explore new features.

Tips to remember
  • Open with a one-sentence definition of difference between manual and automation testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise difference between manual and automation testing cleanly.
RelatedQ35Q39
← Q36Q38 →
Easy Very Common 1 minQ38 / 172

Q38.Which tests should be automated?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

Listing questions on Which tests should be automated look easy but trap candidates who rattle off names without depth. Interviewers score higher when you group the items, mention which you use most, and add one line of context per item.

Detailed explanation

Automate: stable and frequently-repeated tests (regression), data-driven tests, load and performance tests, smoke and sanity suites, and tests hard to do manually (concurrency, precise timing). Don't automate one-off tests, UX/look-and-feel checks, or tests for unstable features.

Tips to remember
  • Group the items into 2–3 categories before listing — panels remember structure, not raw counts.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Which tests should be automated cleanly.
  • Use percentiles (P90/P95) and a concrete SLA rather than averages — averages hide the failures interviewers care about.
RelatedQ36Q40
← Q37Q39 →
Easy Very Common 1 minQ39 / 172

Q39.What is Selenium?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

Interviewers open with "Selenium" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Selenium is an open-source suite (WebDriver, Grid, IDE) for automating web browsers. Supports Java, Python, C#, JavaScript. Selenium 4 added relative locators, Chrome DevTools Protocol access, and Grid 4 with Docker-native scaling.

Tips to remember
  • Open with a one-sentence definition of Selenium, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Selenium cleanly.
  • Mention pinned browser images and cleanup of containers between runs — panels look for CI cost awareness.
RelatedQ37Q41
← Q38Q40 →
Easy Very Common 1 minQ40 / 172

Q40.What is Playwright?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

Interviewers open with "Playwright" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Playwright is Microsoft's modern browser automation framework (TypeScript, JS, Python, .NET, Java). Ships with auto-waiting, network interception, trace viewer, and parallel execution out of the box — no separate Grid needed.

Tips to remember
  • Open with a one-sentence definition of Playwright, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Playwright cleanly.
  • State that you never mix wait strategies and never use a hard sleep, then give the timeout value you actually run in CI.
RelatedQ38Q42
← Q39Q41 →
Easy Very Common 1 minQ41 / 172

Q41.Should I learn Selenium or Playwright first?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Should I learn Selenium or Playwright first and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Learn Selenium first if you're targeting enterprise Java roles or teams with existing Grid suites. Learn Playwright first for greenfield TypeScript stacks or modern startups. Most senior SDETs know both — Selenium for job breadth, Playwright for developer experience.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Should I learn Selenium or Playwright first over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Should I learn Selenium or Playwright first cleanly.
  • Mention capability matrix and cost/queue trade-offs — that's the operational angle panels probe next.
RelatedQ39Q43
← Q40Q42 →
Easy Very Common 1 minQ42 / 172

Q42.What is the objective of software testing?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

Interviewers open with "objective of software testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Primary objectives: (1) find defects, (2) verify the product meets requirements, (3) validate it meets user needs, (4) provide risk information to stakeholders, (5) prevent defects through early involvement, (6) build confidence in a release.

Tips to remember
  • Open with a one-sentence definition of objective of software testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise objective of software testing cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ40Q44
← Q41Q43 →
Easy Very Common 1 minQ43 / 172

Q43.What is the difference between QA, QC, and testing?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Interviewers open with "difference between QA, QC, and testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

QA is process-oriented and preventive (audits, reviews, standards). QC is product-oriented and corrective (inspection, testing). Testing is one activity inside QC that executes the software to detect defects.

Tips to remember
  • Open with a one-sentence definition of difference between QA, QC, and testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise difference between QA, QC, and testing cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ41Q45
← Q42Q44 →
Easy Very Common 1 minQ44 / 172

Q44.What is the difference between error, defect, bug, and failure?

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Interviewers open with "difference between error, defect, bug, and failure" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Error = human mistake in code or logic. Defect (bug/fault) = the flaw in the software introduced by the error. Failure = the observable incorrect behavior when the defect is triggered. Not every defect leads to failure (dead code, unreachable paths).

Tips to remember
  • Open with a one-sentence definition of difference between error, defect, bug, and failure, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise difference between error, defect, bug, and failure cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ42Q46
← Q43Q45 →
Easy Very Common 1 minQ45 / 172

Q45.Principle 1: Testing shows the presence of defects, not their absence.

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Principle 1: Testing shows the presence of defects, not their absence and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Testing can prove defects exist, but never that none remain. Even after extensive testing, undiscovered defects may still exist. This is why we use risk-based coverage and continue monitoring in production.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Principle 1: Testing shows the presence of defects, not their absence over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Principle 1: Testing shows the presence of defects, not their absence cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ43Q47
← Q44Q46 →
Easy Very Common 1 minQ46 / 172

Q46.Principle 2: Exhaustive testing is impossible.

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Principle 2: Exhaustive testing is impossible and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Testing every input, path, and combination is infeasible except for trivial systems. Instead, we use risk analysis, test design techniques (BVA, EP, decision tables), and prioritization to focus effort where impact is highest.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Principle 2: Exhaustive testing is impossible over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Principle 2: Exhaustive testing is impossible cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ44Q48
← Q45Q47 →
Easy Very Common 1 minQ47 / 172

Q47.Principle 3: Early testing saves time and money.

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Principle 3: Early testing saves time and money and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Involve QA from requirements — review specs, add acceptance criteria, and unit-test as code is written. Defects found in requirements cost ~1×; in design ~5×; in coding ~10×; in production ~100× (Boehm's curve).

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Principle 3: Early testing saves time and money over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Principle 3: Early testing saves time and money cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ45Q49
← Q46Q48 →
Easy Very Common 1 minQ48 / 172

Q48.Principle 4: Defect clustering.

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Principle 4: Defect clustering and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

The Pareto rule applies: ~80% of defects come from ~20% of modules. Track defects per module across releases; concentrate testing effort on hotspot areas rather than spreading uniformly.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Principle 4: Defect clustering over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Principle 4: Defect clustering cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ46Q50
← Q47Q49 →
Easy Very Common 1 minQ49 / 172

Q49.Principle 5: Pesticide paradox.

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Principle 5: Pesticide paradox and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Repeating the same tests over time stops finding new defects — the code has been "immunized" against them. Refresh test cases regularly with new inputs, edge cases, and exploratory sessions.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Principle 5: Pesticide paradox over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Principle 5: Pesticide paradox cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ47Q51
← Q48Q50 →
Easy Very Common 1 minQ50 / 172

Q50.Principle 6: Testing is context-dependent.

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Principle 6: Testing is context-dependent and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Testing a banking app (regulated, high risk) differs from testing a game (usability-driven). Techniques, coverage, tools, and rigor should match the domain, risk profile, and lifecycle model.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Principle 6: Testing is context-dependent over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Principle 6: Testing is context-dependent cleanly.
RelatedQ48Q52
← Q49Q51 →
Easy Very Common 1 minQ51 / 172

Q51.Principle 7: Absence-of-errors fallacy.

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Principle 7: Absence-of-errors fallacy and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

A bug-free product that doesn't meet user needs is still a failure. Testing must validate business value and usability, not just verify against a spec.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Principle 7: Absence-of-errors fallacy over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Principle 7: Absence-of-errors fallacy cleanly.
RelatedQ49Q53
← Q50Q52 →
Easy Very Common 1 minQ52 / 172

Q52.What are the 4 levels of testing?

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Interviewers open with "4 levels of testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Unit — developers test individual functions. Integration — interactions between modules. System — end-to-end product against requirements. Acceptance — business stakeholders / users validate for production. Each level has entry/exit criteria and different owners.

Tips to remember
  • Open with a one-sentence definition of 4 levels of testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise 4 levels of testing cleanly.
RelatedQ50Q54
← Q51Q53 →
Easy Very Common 1 minQ53 / 172

Q53.What is unit testing?

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

Interviewers open with "unit testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Unit testing validates the smallest testable part of code (function, method) in isolation using stubs/mocks. Owned by developers. Frameworks: JUnit, NUnit, pytest, Jest. Target coverage: 70–80% of business logic.

Tips to remember
  • Open with a one-sentence definition of unit testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise unit testing cleanly.
  • Say when you'd mock versus hit the real dependency; unconditional mocking is a red flag for integration coverage.
RelatedQ51Q55
← Q52Q54 →
Easy Very Common 1 minQ54 / 172

Q54.What is integration testing and its approaches?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

Interviewers open with "integration testing and its approaches" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Integration testing verifies interactions between modules. Approaches: Big Bang (all at once), Top-Down (stubs for lower modules), Bottom-Up (drivers for upper modules), Sandwich (both), Incremental (module-by-module).

Tips to remember
  • Open with a one-sentence definition of integration testing and its approaches, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise integration testing and its approaches cleanly.
  • Say when you'd mock versus hit the real dependency; unconditional mocking is a red flag for integration coverage.
RelatedQ52Q56
← Q53Q55 →
Easy Very Common 1 minQ55 / 172

Q55.What is system testing?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

Interviewers open with "system testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

System testing validates the complete, integrated system against specified requirements end-to-end. Includes functional + non-functional (performance, security, usability). Owned by QA team.

Tips to remember
  • Open with a one-sentence definition of system testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise system testing cleanly.
  • Use percentiles (P90/P95) and a concrete SLA rather than averages — averages hide the failures interviewers care about.
RelatedQ53Q57
← Q54Q56 →
Easy Very Common 1 minQ56 / 172

Q56.What is the difference between functional and non-functional testing?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

Interviewers open with "difference between functional and non-functional testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Functional verifies what the system does (features, business rules, error handling). Non-functional verifies how well it does it (performance, security, usability, reliability, compatibility).

Tips to remember
  • Open with a one-sentence definition of difference between functional and non-functional testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise difference between functional and non-functional testing cleanly.
  • Use percentiles (P90/P95) and a concrete SLA rather than averages — averages hide the failures interviewers care about.
RelatedQ54Q58
← Q55Q57 →
Easy Very Common 1 minQ57 / 172

Q57.What is smoke vs sanity testing?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

Interviewers open with "smoke vs sanity testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Smoke testing — shallow, wide check on a new build (do core flows work?); runs first, before regression. Sanity testing — narrow, deep check on a specific area after a bug fix or small change. Both are subsets of regression testing.

Tips to remember
  • Open with a one-sentence definition of smoke vs sanity testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise smoke vs sanity testing cleanly.
RelatedQ55Q59
← Q56Q58 →
Easy Very Common 1 minQ58 / 172

Q58.What is boundary value analysis (BVA)?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

Interviewers open with "boundary value analysis (BVA)" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

BVA tests values at the edges of input ranges — min, min-1, min+1, max, max-1, max+1. For a text field accepting 5–15 chars: test 4, 5, 6, 14, 15, 16 characters. Bugs cluster at boundaries where developers use wrong operators (< vs ≤).

Tips to remember
  • Open with a one-sentence definition of boundary value analysis (BVA), then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise boundary value analysis (BVA) cleanly.
  • Apply the technique live to a small example (a login field, an age input) instead of only naming it.
RelatedQ56Q60
← Q57Q59 →
Easy Very Common 1 minQ59 / 172

Q59.What is equivalence partitioning (EP)?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Interviewers open with "equivalence partitioning (EP)" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

EP divides inputs into partitions where behavior should be identical, then tests one representative per partition. For age 18–60: one value from <18 (invalid), 18–60 (valid), >60 (invalid) — three tests instead of dozens.

Tips to remember
  • Open with a one-sentence definition of equivalence partitioning (EP), then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise equivalence partitioning (EP) cleanly.
  • Apply the technique live to a small example (a login field, an age input) instead of only naming it.
RelatedQ57Q61
← Q58Q60 →
Easy Very Common 1 minQ60 / 172

Q60.Explain the Waterfall model.

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Open-ended "explain Waterfall model" prompts test how you structure a technical answer under pressure. Panels look for a clear opening definition, one worked example, and a closing sentence on the pitfall they were about to ask about next.

Detailed explanation

Waterfall is a sequential model where each phase must complete before the next begins. Rigid, easy to manage, but poor at handling changing requirements. Testing happens only after development. Best for well-defined, stable requirements (regulated systems).

Tips to remember
  • Use a 3-part frame for Waterfall model: what it is → how it works → one gotcha you've hit in a real Software Testing project.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Waterfall model cleanly.
RelatedQ58Q62
← Q59Q61 →
Easy Very Common 1 minQ61 / 172

Q61.Explain the bug life cycle.

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

Open-ended "explain bug life cycle" prompts test how you structure a technical answer under pressure. Panels look for a clear opening definition, one worked example, and a closing sentence on the pitfall they were about to ask about next.

Detailed explanation

Standard flow: New → Assigned → Open → In Progress → Fixed → Retest → Verified → Closed. Alternate states: Rejected, Deferred, Duplicate, Not-Reproducible, Reopened. Tracked in Jira, Azure DevOps, or Bugzilla.

Tips to remember
  • Use a 3-part frame for bug life cycle: what it is → how it works → one gotcha you've hit in a real Software Testing project.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise bug life cycle cleanly.
RelatedQ59Q63
← Q60Q62 →
Easy Very Common 1 minQ62 / 172

Q62.What is a test environment (test bed)?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

Interviewers open with "test environment (test bed)" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

A test environment is the combination of hardware, software, network, OS, browser, database, and test data configured for running tests. Common environments: DEV, QA, STAGING, UAT, PROD.

Tips to remember
  • Open with a one-sentence definition of test environment (test bed), then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise test environment (test bed) cleanly.
  • Say how you clean up or roll back the data you touch — DB questions are really data-hygiene questions.
RelatedQ60Q64
← Q61Q63 →
Easy Very Common 1 minQ63 / 172

Q63.What is a test suite vs test plan?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

Interviewers open with "test suite vs test plan" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Test plan = strategy document (scope, schedule, resources, risks). Test suite = actual collection of test cases grouped by feature or release. One test plan governs many test suites.

Tips to remember
  • Open with a one-sentence definition of test suite vs test plan, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise test suite vs test plan cleanly.
  • Apply the technique live to a small example (a login field, an age input) instead of only naming it.
RelatedQ61Q65
← Q62Q64 →
Easy Very Common 1 minQ64 / 172

Q64.What is a Requirement Traceability Matrix (RTM)?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

Interviewers open with "Requirement Traceability Matrix (RTM)" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

An RTM maps requirements → test cases → defects → business objectives. Proves 100% coverage, exposes untested requirements, and simplifies impact analysis when requirements change.

Tips to remember
  • Open with a one-sentence definition of Requirement Traceability Matrix (RTM), then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Requirement Traceability Matrix (RTM) cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ62Q66
← Q63Q65 →
Confidence check

If you can confidently answer the Fresher (0–1 yrs) questions above, you're well prepared for this section of your interview. Move on, or rehearse the trickier ones aloud with our AI mock interviewer.

2. Mid-level (2–4 yrs)

Medium Very Common 1 minQ65 / 172

Q65.Walk me through your current test process end-to-end.

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Walk me through your current test process end-to-end and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Structure: Requirement analysis (attend refinement, raise ambiguities, add acceptance criteria) → Test planning (risk-based prioritization, effort estimate, environment needs) → Test design (BVA, EP, decision tables, exploratory charters) → Execution (smoke → regression → new-feature) → Defect triage (daily standup with dev + PO) → UAT support → Test closure report (leakage %, coverage %, lessons learned). At 3 YOE you're expected to own a sprint's QA from refinement to closure.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Walk me through your current test process end-to-end over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Walk me through your current test process end-to-end cleanly.
  • Say who reads the report and what decision it drives — evidence-for-humans framing beats a tool name list.
RelatedQ63Q67
← Q64Q66 →
Easy Very Common 1 minQ66 / 172

Q66.How do you estimate testing effort for a new feature?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

Hands-on "how would you estimate testing effort for a new feature" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Break the feature into user stories → identify test types needed (functional, API, integration, non-functional) → estimate per story using historical velocity (e.g., 20 test cases/day, 4 hours per automation script) → add 20–30% buffer for defect fix retest + regression + environment setup. Present in ideal hours, then convert to sprint capacity.

Tips to remember
  • Walk through estimate testing effort for a new feature as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise estimate testing effort for a new feature cleanly.
  • Explain setup/teardown ordering and what runs per-test vs per-suite; ordering mistakes are the follow-up question.
RelatedQ64Q68
← Q65Q67 →
Easy Very Common 1 minQ67 / 172

Q67.What is a Requirement Traceability Matrix (RTM) and why does it matter at 3 YOE?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Interviewers open with "Requirement Traceability Matrix (RTM) and why does it matter at 3 YOE" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

An RTM maps requirements → test cases → defects → business objectives. At 3 YOE you own the RTM for your module — it proves 100% coverage in audits, exposes untested requirements early, and simplifies impact analysis when a requirement changes mid-sprint.

Tips to remember
  • Open with a one-sentence definition of Requirement Traceability Matrix (RTM) and why does it matter at 3 YOE, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Requirement Traceability Matrix (RTM) and why does it matter at 3 YOE cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ65Q69
← Q66Q68 →
Easy Very Common 1 minQ68 / 172

Q68.How do you decide risk-based test prioritization?

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Hands-on "how would you decide risk-based test prioritization" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Risk = Probability × Impact. Rank features by combined risk (payments, auth, and data-mutation flows are always high; static pages are low). Exhaustively test high-risk paths (BVA + EP + negative + non-functional); sample low-risk paths. Publish the risk matrix and get PO sign-off before sprint start.

Tips to remember
  • Walk through decide risk-based test prioritization as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise decide risk-based test prioritization cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ66Q70
← Q67Q69 →
Easy Common 1 minQ69 / 172

Q69.How do you handle changing requirements mid-sprint?

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

Hands-on "how would you handle changing requirements mid-sprint" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Log the change in Jira with impact analysis (test cases affected, automation scripts to update, regression scope). Renegotiate scope with PO — either extend sprint or de-scope another item. Never absorb silently; documented change control protects the team.

Tips to remember
  • Walk through handle changing requirements mid-sprint as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise handle changing requirements mid-sprint cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ67Q71
← Q68Q70 →
Easy Common 1 minQ70 / 172

Q70.How do you handle testing when requirements are unclear or missing?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

Hands-on "how would you handle testing when requirements are unclear or missing" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Reach out in writing to PO/BA, refer to related user stories, competitor products, or industry standards. Write assumptions in the test plan, get sign-off, log clarifications in a shared doc. If still ambiguous, run exploratory charters and file clarification tickets — never guess silently, undocumented assumptions cause leakage.

Tips to remember
  • Walk through handle testing when requirements are unclear or missing as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise handle testing when requirements are unclear or missing cleanly.
RelatedQ68Q72
← Q69Q71 →
Easy Common 1 minQ71 / 172

Q71.How do you decide when to stop testing?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

Hands-on "how would you decide when to stop testing" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Combine: (1) all planned test cases executed with pass rate ≥ target, (2) exit criteria met (zero P1, ≤ N P2 open), (3) risk-based coverage complete, (4) defect-arrival rate flattens over 2–3 days, (5) deadline reached with stakeholder sign-off. Never stop on a single metric.

Tips to remember
  • Walk through decide when to stop testing as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise decide when to stop testing cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ69Q73
← Q70Q72 →
Easy Common 1 minQ72 / 172

Q72.How do you write and manage a test strategy at 3 YOE?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

Hands-on "how would you write and manage a test strategy at 3 YOE" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Test strategy = project-agnostic policy (e.g., all APIs get contract tests, all UIs get smoke automation, all releases get performance regression). Test plan = project-specific execution of that strategy. At 3 YOE you often draft the test plan and get the QA lead to sign off.

Tips to remember
  • Walk through write and manage a test strategy at 3 YOE as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise write and manage a test strategy at 3 YOE cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ70Q74
← Q71Q73 →
Medium Common 1 minQ73 / 172

Q73.Walk me through the automation framework you've built or maintained.

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Walk me through the automation framework you've built or maintained and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Answer template: (1) tech stack — Selenium/Playwright + Java/Python/TS + TestNG/Pytest + Maven/Gradle. (2) pattern — POM + data-driven via CSV/Excel/JSON. (3) config — env-driven properties (dev/qa/staging/prod). (4) reporting — Allure + screenshots/videos on failure. (5) CI/CD — Jenkins/GitHub Actions with parallel execution. (6) coverage today vs baseline. Ready to sketch the folder structure on whiteboard.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Walk me through the automation framework you've built or maintained over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Walk me through the automation framework you've built or maintained cleanly.
  • Add one sentence on what does NOT belong in a page object (assertions, test data) — that boundary is what separates mid from senior answers.
RelatedQ71Q75
← Q72Q74 →
Easy Common 1 minQ74 / 172

Q74.Compare Page Object Model vs Screenplay pattern.

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

Comparison questions like this test whether you understand Compare Page Object Model vs Screenplay pattern at a design level — not just that both exist, but when to pick one over the other. Panels use it to see if you can defend a trade-off with a real project example.

Detailed explanation

POM — each page/component has a class exposing methods; hides locators; easy for teams new to automation. Screenplay — actors perform tasks, using abilities and asking questions; more testable, reads like BDD, but steeper learning curve. Enterprise Java teams still default to POM in 2026.

Tips to remember
  • Structure the answer as a small table in your head: dimension, option A, option B — and close with "I'd pick X when Y".
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Compare Page Object Model vs Screenplay pattern cleanly.
  • Add one sentence on what does NOT belong in a page object (assertions, test data) — that boundary is what separates mid from senior answers.
RelatedQ72Q76
← Q73Q75 →
Easy Common 1 minQ75 / 172

Q75.How do you integrate automation into CI/CD?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Hands-on "how would you integrate automation into CI/CD" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Trigger via GitHub Actions/Jenkins/GitLab CI. Pipeline: checkout → install deps → smoke on PR (5 min) → full regression on merge to main (30 min, parallel) → publish Allure report → notify Slack. Tag tests (@smoke, @regression, @perf) to control scope per stage. Fail the build on smoke failure only, warn on regression flake.

Tips to remember
  • Walk through integrate automation into CI/CD as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise integrate automation into CI/CD cleanly.
  • Call out test isolation and shared-state risk (data, sessions, ports) before you talk about worker counts.
RelatedQ73Q77
← Q74Q76 →
Easy Common 1 minQ76 / 172

Q76.How do you handle a flaky test at 3 YOE?

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Hands-on "how would you handle a flaky test at 3 YOE" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Root-cause first — is it wait, data, environment, timing, or third-party? Fix implicit waits with explicit conditions, replace unstable selectors with data-testid, isolate test data (unique UUID per run), mock third parties, stabilize animations. Retry 2× in CI (test.retries). If still flaky, quarantine + file a bug + own the fix within the sprint.

Tips to remember
  • Walk through handle a flaky test at 3 YOE as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise handle a flaky test at 3 YOE cleanly.
  • State that you never mix wait strategies and never use a hard sleep, then give the timeout value you actually run in CI.
RelatedQ74Q78
← Q75Q77 →
Easy Common 1 minQ77 / 172

Q77.What is your parallel-execution strategy?

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

Interviewers open with "your parallel-execution strategy" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

TestNG parallel="methods" with thread-count tuned to CI runner cores; ThreadLocal WebDriver for isolation; unique test data per thread; per-thread screenshot/log folders. Playwright: projects + workers. Cypress: parallelization via Dashboard. Always verify with -DthreadCount=10 locally before pushing.

Tips to remember
  • Open with a one-sentence definition of your parallel-execution strategy, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise your parallel-execution strategy cleanly.
  • Call out test isolation and shared-state risk (data, sessions, ports) before you talk about worker counts.
RelatedQ75Q79
← Q76Q78 →
Easy Common 1 minQ78 / 172

Q78.What design patterns do you use in automation?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on What design patterns do you use in automation and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Page Object, Singleton (driver factory), Factory (browser/env factory), Builder (test data builder), Strategy (data-source strategy), Fluent Interface (chainable page methods), Facade (business-flow wrapper).

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on What design patterns do you use in automation over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise What design patterns do you use in automation cleanly.
  • Add one sentence on what does NOT belong in a page object (assertions, test data) — that boundary is what separates mid from senior answers.
RelatedQ76Q80
← Q77Q79 →
Easy Common 1 minQ79 / 172

Q79.How do you handle test data at 3 YOE?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

Hands-on "how would you handle test data at 3 YOE" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Three tiers: (1) static data in JSON/CSV per env, (2) generated data with Faker/JavaFaker per test run, (3) API-seeded data (call setup APIs to create fixtures, tear down after). Never share mutable state across tests. Store secrets in Vault/Secrets Manager, never in Git.

Tips to remember
  • Walk through handle test data at 3 YOE as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise handle test data at 3 YOE cleanly.
  • Explain setup/teardown ordering and what runs per-test vs per-suite; ordering mistakes are the follow-up question.
RelatedQ77Q81
← Q78Q80 →
Easy Common 1 minQ80 / 172

Q80.What is your approach to cross-browser testing?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

Interviewers open with "your approach to cross-browser testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Local: Selenium Grid 4 in Docker Compose or Playwright's built-in projects (chromium, firefox, webkit). Cloud: BrowserStack/Sauce Labs/LambdaTest for real device + version matrix. Run cross-browser as a nightly job, not per PR — too slow for fast feedback loops.

Tips to remember
  • Open with a one-sentence definition of your approach to cross-browser testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise your approach to cross-browser testing cleanly.
  • Mention pinned browser images and cleanup of containers between runs — panels look for CI cost awareness.
RelatedQ78Q82
← Q79Q81 →
Easy Common 1 minQ81 / 172

Q81.How do you test APIs at 3 YOE?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

Hands-on "how would you test APIs at 3 YOE" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Postman collections + Newman in CI for smoke; RestAssured/Playwright APIRequestContext for regression. Validate: status code, response time, headers, body (JSON schema, JSONPath), error handling (4xx/5xx), auth/authz, idempotency, and rate limiting. Add contract tests (Pact) between consumer and provider services.

Tips to remember
  • Walk through test APIs at 3 YOE as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise test APIs at 3 YOE cleanly.
  • Assert status, schema and business payload — naming all three signals you test contracts, not just happy paths.
RelatedQ79Q83
← Q80Q82 →
Easy Common 1 minQ82 / 172

Q82.What is contract testing and when do you use it?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

Interviewers open with "contract testing and when do you use it" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Contract testing (Pact, Spring Cloud Contract) validates that a consumer and provider agree on request/response shape. The provider runs consumer-generated contract tests in its pipeline. Use it in microservice architectures where E2E is too slow/flaky to gate every merge.

Tips to remember
  • Open with a one-sentence definition of contract testing and when do you use it, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise contract testing and when do you use it cleanly.
  • Quote a real flake-rate number before and after your fix; measured outcomes score far higher than "we added retries".
RelatedQ80Q84
← Q81Q83 →
Easy Common 1 minQ83 / 172

Q83.How do you test a database at 3 YOE?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Hands-on "how would you test a database at 3 YOE" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

SQL validation post-transaction: run selects with joins and aggregate against expected values; verify referential integrity, constraints, triggers. Use snapshots for regression; rollback via transaction wrappers in test. Never write to prod. Tools: JDBC in RestAssured, Cypress DB tasks, pytest-postgres.

Tips to remember
  • Walk through test a database at 3 YOE as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise test a database at 3 YOE cleanly.
  • Say how you clean up or roll back the data you touch — DB questions are really data-hygiene questions.
RelatedQ81Q85
← Q82Q84 →
Easy Common 1 minQ84 / 172

Q84.What is service virtualization and when do you use it?

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Interviewers open with "service virtualization and when do you use it" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Service virtualization simulates unstable, expensive, or restricted third-party APIs (payment gateway, mainframe, partner service). Tools: WireMock, MockServer, Hoverfly. Use when the dependency is rate-limited, costs money per call, or unavailable in lower environments.

Tips to remember
  • Open with a one-sentence definition of service virtualization and when do you use it, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise service virtualization and when do you use it cleanly.
  • Finish by saying you always return to the default content after frame work — forgetting that is the classic failure this question hunts for.
RelatedQ82Q86
← Q83Q85 →
Easy Common 1 minQ85 / 172

Q85.How do you validate a message-queue-based system (Kafka/RabbitMQ)?

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

Hands-on "how would you validate a message-queue-based system (Kafka/RabbitMQ)" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Consumer test: produce a test event, assert consumer processes it and writes expected DB state. Producer test: trigger the app action, assert the correct event lands on the topic with expected schema. Use ephemeral test topics + testcontainers for isolation.

Tips to remember
  • Walk through validate a message-queue-based system (Kafka/RabbitMQ) as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise validate a message-queue-based system (Kafka/RabbitMQ) cleanly.
  • Mention pinned browser images and cleanup of containers between runs — panels look for CI cost awareness.
RelatedQ83Q87
← Q84Q86 →
Easy Common 1 minQ86 / 172

Q86.What is JWT and how do you validate it in API tests?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

Interviewers open with "JWT and how do you validate it in API tests" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

JWT = header.payload.signature encoded token. In tests, decode payload (Base64), assert claims (sub, exp, roles). Never hardcode secrets in tests; use env-injected signing key. Test negative cases: expired token, tampered signature, missing scopes, wrong audience.

Tips to remember
  • Open with a one-sentence definition of JWT and how do you validate it in API tests, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise JWT and how do you validate it in API tests cleanly.
  • Cover token expiry and refresh in your answer; most candidates only describe the happy-path login.
RelatedQ84Q88
← Q85Q87 →
Easy Common 1 minQ87 / 172

Q87.How do you work with developers in Agile at 3 YOE?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

Hands-on "how would you work with developers in Agile at 3 YOE" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Pair on story acceptance criteria during refinement, review PRs for testability (data-testid, seams for mocking), pair on test-writing for critical logic, and co-own defect triage. Shift-left mindset — bugs caught in review or unit tests are 10× cheaper than in system testing.

Tips to remember
  • Walk through work with developers in Agile at 3 YOE as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise work with developers in Agile at 3 YOE cleanly.
  • Say when you'd mock versus hit the real dependency; unconditional mocking is a red flag for integration coverage.
RelatedQ85Q89
← Q86Q88 →
Easy Common 1 minQ88 / 172

Q88.What is Shift-Left and Shift-Right testing?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

Interviewers open with "Shift-Left and Shift-Right testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Shift-Left — testing activities move earlier: static analysis in IDE, unit tests, contract tests, TDD, story-level acceptance in refinement. Shift-Right — testing in production: canary releases, feature flags, synthetic monitoring, chaos engineering, A/B tests.

Tips to remember
  • Open with a one-sentence definition of Shift-Left and Shift-Right testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Shift-Left and Shift-Right testing cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ86Q90
← Q87Q89 →
Easy Common 1 minQ89 / 172

Q89.What is your role in production incidents?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

Interviewers open with "your role in production incidents" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Join war-room; help reproduce; capture logs, traces, DB state; identify why QA missed it (test gap? environment gap? unclear requirement?). File a follow-up test + regression + monitor alert as the RCA action item. Never blame; own the leakage.

Tips to remember
  • Open with a one-sentence definition of your role in production incidents, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise your role in production incidents cleanly.
  • Say who reads the report and what decision it drives — evidence-for-humans framing beats a tool name list.
RelatedQ87Q91
← Q88Q90 →
Easy Common 1 minQ90 / 172

Q90.How do you handle feature flags in testing?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

Hands-on "how would you handle feature flags in testing" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Test both states (flag on / flag off) in the regression suite; parameterize via env var. Coordinate with dev on flag lifecycle — remove stale flags to prevent combinatorial explosion. Automate flag toggling in CI where the SDK allows.

Tips to remember
  • Walk through handle feature flags in testing as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise handle feature flags in testing cleanly.
  • Explain how you test asynchronous flows (polling, consumer assertions, timeouts) rather than treating it as a sync call.
RelatedQ88Q92
← Q89Q91 →
Easy Common 1 minQ91 / 172

Q91.How do you collaborate with the Product Owner at 3 YOE?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Hands-on "how would you collaborate with the Product Owner at 3 YOE" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Attend refinement + planning; challenge ambiguous acceptance criteria; suggest edge cases the PO may have missed; own the definition-of-done checklist for QA (functional + non-functional + accessibility). Publish sprint-end quality summary to keep PO informed.

Tips to remember
  • Walk through collaborate with the Product Owner at 3 YOE as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise collaborate with the Product Owner at 3 YOE cleanly.
  • Anchor the answer to a ceremony and an artefact (definition of done, story acceptance criteria) from a team you worked in.
RelatedQ89Q93
← Q90Q92 →
Easy Common 1 minQ92 / 172

Q92.What is DevOps from a tester's viewpoint?

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Interviewers open with "DevOps from a tester's viewpoint" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

DevOps = fast, safe, frequent releases via automation and shared ownership. Tester contribution: fast automated feedback in CI (smoke < 5 min), IaC-based test envs, observability of tests (report, trend, flake dashboard), and blameless post-mortems on leakage.

Tips to remember
  • Open with a one-sentence definition of DevOps from a tester's viewpoint, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise DevOps from a tester's viewpoint cleanly.
  • Say who reads the report and what decision it drives — evidence-for-humans framing beats a tool name list.
RelatedQ90Q94
← Q91Q93 →
Easy Common 1 minQ93 / 172

Q93.What quality metrics do you track and why?

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on What quality metrics do you track and why and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Test execution %, pass rate, defect leakage %, defect density, MTTD/MTTR, automation coverage, requirements coverage, flaky-test rate. Track trends over releases, not absolute numbers; publish monthly to leadership.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on What quality metrics do you track and why over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise What quality metrics do you track and why cleanly.
  • Quote a real flake-rate number before and after your fix; measured outcomes score far higher than "we added retries".
RelatedQ91Q95
← Q92Q94 →
Easy Common 1 minQ94 / 172

Q94.What is defect leakage and how do you reduce it?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

Interviewers open with "defect leakage and how do you reduce it" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Defect leakage = defects that escape to a later stage or production. Formula: leaked ÷ total × 100. Target < 5%. Reduce by: RCA every leak, add regression tests, close environment/data gaps, tighten exit criteria, and shift-left with dev pairing on risky changes.

Tips to remember
  • Open with a one-sentence definition of defect leakage and how do you reduce it, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise defect leakage and how do you reduce it cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ92Q96
← Q93Q95 →
Easy Common 1 minQ95 / 172

Q95.How do you handle a critical bug reported in production?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

Hands-on "how would you handle a critical bug reported in production" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Acknowledge → reproduce → capture logs + DB state → escalate to on-call dev + PO → coordinate hotfix. Post-fix: add regression test, add monitor/alert, run RCA in blameless post-mortem, publish process improvement. Update the risk matrix so future releases test similar surfaces.

Tips to remember
  • Walk through handle a critical bug reported in production as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise handle a critical bug reported in production cleanly.
  • Say who reads the report and what decision it drives — evidence-for-humans framing beats a tool name list.
RelatedQ93Q97
← Q94Q96 →
Easy Common 1 minQ96 / 172

Q96.What is Root Cause Analysis (RCA) and how do you conduct one?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

Interviewers open with "Root Cause Analysis (RCA) and how do you conduct one" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

RCA uses techniques like 5 Whys or Fishbone to trace an incident to its root — not the symptom. Conduct: gather facts (logs, timeline, code diff), ask 5 Whys, agree on root cause, agree on preventive action (test, monitor, process), publish + track to closure. Blameless, always.

Tips to remember
  • Open with a one-sentence definition of Root Cause Analysis (RCA) and how do you conduct one, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Root Cause Analysis (RCA) and how do you conduct one cleanly.
  • Say who reads the report and what decision it drives — evidence-for-humans framing beats a tool name list.
RelatedQ94Q98
← Q95Q97 →
Easy Common 1 minQ97 / 172

Q97.How do you handle a P1 defect the developer says 'can't reproduce'?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

Hands-on "how would you handle a P1 defect the developer says 'can't reproduce'" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Reproduce with them in a call, share exact steps + env + video. If truly intermittent, add logging around suspected code paths and re-test. Capture the intermittent nature in the ticket (frequency, conditions). Escalate to eng lead if repeatedly closed as 'not reproducible' without RCA.

Tips to remember
  • Walk through handle a P1 defect the developer says 'can't reproduce' as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise handle a P1 defect the developer says 'can't reproduce' cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ95Q99
← Q96Q98 →
Easy Common 1 minQ98 / 172

Q98.What is your approach to reducing regression cycle time?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

Interviewers open with "your approach to reducing regression cycle time" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Parallelize (Grid/Playwright workers); tag and split (smoke vs full regression); test-impact analysis (run only tests affected by the diff); mock unstable third parties; move slow E2E to API/component level; prune duplicate tests quarterly.

Tips to remember
  • Open with a one-sentence definition of your approach to reducing regression cycle time, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise your approach to reducing regression cycle time cleanly.
  • Call out test isolation and shared-state risk (data, sessions, ports) before you talk about worker counts.
RelatedQ96Q100
← Q97Q99 →
Medium Common 1 minQ99 / 172

Q99.Tell me about the toughest bug you found (STAR format).

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Tell me about the toughest bug you found (STAR format) and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Situation — payment webhook occasionally credited wrong amount in staging. Task — reproduce and root-cause before release. Action — added structured logs, ran 100 concurrent requests, isolated a race condition in webhook handler; paired with dev on a mutex fix; added regression + concurrency test. Result — released on-time, zero leakage, added standard concurrency test pattern for team.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Tell me about the toughest bug you found (STAR format) over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Tell me about the toughest bug you found (STAR format) cleanly.
  • Explain setup/teardown ordering and what runs per-test vs per-suite; ordering mistakes are the follow-up question.
RelatedQ97Q101
← Q98Q100 →
Easy Common 1 minQ100 / 172

Q100.Tell me about a time you disagreed with a developer.

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Tell me about a time you disagreed with a developer and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

STAR — the developer said an accessibility issue was low priority; I disagreed because it blocked screen-reader users on a payment flow. Shared WCAG 2.1 spec + screen-reader recording. Escalated to PO with impact estimate. Result — fix was pulled into the same release; team added accessibility to definition-of-done.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Tell me about a time you disagreed with a developer over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Tell me about a time you disagreed with a developer cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ98Q102
← Q99Q101 →
Easy Common 1 minQ101 / 172

Q101.Tell me about a time you missed a bug that reached production.

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Tell me about a time you missed a bug that reached production and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

STAR — a currency conversion bug shipped to prod because the test data covered only USD. Owned the leakage in retro; added multi-currency test data provider; created currency regression pack; published RCA. Result — zero currency defects in next 6 releases; team adopted the data-provider pattern.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Tell me about a time you missed a bug that reached production over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Tell me about a time you missed a bug that reached production cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ99Q103
← Q100Q102 →
Easy Common 1 minQ102 / 172

Q102.Tell me about a time you improved a QA metric.

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Tell me about a time you improved a QA metric and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

STAR — regression suite was 4 hours, blocking daily releases. Analyzed slow tests, moved 60% of UI tests to API level, parallelized remainder across 8 workers. Result — regression cut to 25 minutes, release frequency doubled, flake rate dropped from 8% to 2%.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Tell me about a time you improved a QA metric over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Tell me about a time you improved a QA metric cleanly.
  • Call out test isolation and shared-state risk (data, sessions, ports) before you talk about worker counts.
RelatedQ100Q104
← Q101Q103 →
Easy Common 1 minQ103 / 172

Q103.Tell me about a time you mentored a junior tester.

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Tell me about a time you mentored a junior tester and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

STAR — junior struggled with bug reports being closed as 'insufficient info.' Pair-tested for a week, gave a bug-report template + video-recording tool, reviewed their first 10 reports. Result — junior's bug acceptance rate went from 40% to 90% in 3 weeks; template adopted team-wide.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Tell me about a time you mentored a junior tester over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Tell me about a time you mentored a junior tester cleanly.
  • Say who reads the report and what decision it drives — evidence-for-humans framing beats a tool name list.
RelatedQ101Q105
← Q102Q104 →
Easy Common 1 minQ104 / 172

Q104.Why should we hire you for this 3-YOE role?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

"Why" questions on should we hire you for this 3-YOE role probe your reasoning, not your memory. Strong candidates connect the choice to a business or reliability outcome — flaky tests, slower feedback loop, or missed defects — instead of parroting a rule.

Detailed explanation

Focus on: (1) breadth — manual + automation + API + basic performance, (2) ownership — you've run a sprint's QA end-to-end, (3) measurable impact — quantify one metric improvement, (4) alignment — one thing about the JD/company that excites you specifically. Keep to 60 seconds, follow with a question about their biggest QA pain point.

Tips to remember
  • Tie the "why" for should we hire you for this 3-YOE role back to a measurable outcome — flake rate, execution time, defect leakage — instead of an opinion.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise should we hire you for this 3-YOE role cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ102Q106
← Q103Q105 →
Confidence check

If you can confidently answer the Mid-level (2–4 yrs) questions above, you're well prepared for this section of your interview. Move on, or rehearse the trickier ones aloud with our AI mock interviewer.

3. Senior / SDET (5+ yrs)

Medium Common 1 minQ105 / 172

Q105.How do you design a test strategy for a program with 8 teams and 3 microservice tiers?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

Hands-on "how would you design a test strategy for a program with 8 teams and 3 microservice tiers" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Start from risk, not tools. (1) Map business risk per service (payments and auth = P0; static content = P3). (2) Set the test pyramid contract per tier — unit > component > contract > API > UI. (3) Define quality gates for each stage (PR gate = smoke + unit, merge gate = component + contract, nightly = full regression + non-functional). (4) Assign ownership — each team owns tests up to contract; the platform team owns cross-service E2E, perf and security. (5) Publish RACI + SLOs + review cadence. Present as a 1-page document leadership can approve.

Tips to remember
  • Walk through design a test strategy for a program with 8 teams and 3 microservice tiers as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise design a test strategy for a program with 8 teams and 3 microservice tiers cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ103Q107
← Q104Q106 →
Easy Common 1 minQ106 / 172

Q106.What quality SLOs do you set at senior level?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on What quality SLOs do you set at senior level and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Publish 5 SLOs: escape rate < 3% per release, P1 MTTR < 4 hours, flake rate < 1% per suite, PR smoke feedback < 8 min, regression coverage > 80% of P0/P1 flows. Track weekly, alert on breach, review monthly with engineering leadership. SLOs turn quality from 'testing team's job' into a shared engineering commitment.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on What quality SLOs do you set at senior level over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise What quality SLOs do you set at senior level cleanly.
RelatedQ104Q108
← Q105Q107 →
Easy Common 1 minQ107 / 172

Q107.How do you decide manual vs automated for a mature product?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Comparison questions like this test whether you understand decide manual vs automated for a mature product at a design level — not just that both exist, but when to pick one over the other. Panels use it to see if you can defend a trade-off with a real project example.

Detailed explanation

Automate anything repeated, stable and high-value (regression, smoke, data-integrity, contracts). Keep manual for exploratory, visual/UX judgement, usability, one-off migrations, and early alpha where UI churn kills ROI. Publish the decision matrix (frequency × stability × business impact) so juniors don't automate low-value paths.

Tips to remember
  • Structure the answer as a small table in your head: dimension, option A, option B — and close with "I'd pick X when Y".
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise decide manual vs automated for a mature product cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ105Q109
← Q106Q108 →
Medium Common 1 minQ108 / 172

Q108.How do you drive shift-left across an organisation that has never done it?

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Hands-on "how would you drive shift-left across an organisation that has never done it" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Six-month rollout: (1) get engineering leadership sponsorship with a leakage baseline. (2) pilot with one squad — pair QA + dev on story acceptance and PR review. (3) add PR-level smoke + contract gates. (4) publish before/after metrics (leakage down, cycle time down). (5) roll out to 3 more squads with the pilot's playbook. (6) make shift-left part of the definition-of-done. Change management > tooling.

Tips to remember
  • Walk through drive shift-left across an organisation that has never done it as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise drive shift-left across an organisation that has never done it cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ106Q110
← Q107Q109 →
Easy Common 1 minQ109 / 172

Q109.How do you run a QA governance review?

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

Hands-on "how would you run a QA governance review" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Monthly cadence, 45 minutes: (1) leakage trend + top 3 root causes, (2) automation coverage vs target per team, (3) flake and MTTR trend, (4) infra spend vs budget, (5) top 3 risks for next month + owners. Publish minutes and action items in a shared doc; close every action by the next review. Governance without follow-through is theatre.

Tips to remember
  • Walk through run a QA governance review as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise run a QA governance review cleanly.
RelatedQ107Q111
← Q108Q110 →
Medium Common 1 minQ110 / 172

Q110.How do you build a risk-based release checklist for a regulated product (BFSI / healthcare)?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

Hands-on "how would you build a risk-based release checklist for a regulated product (BFSI / healthcare)" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Anchor on regulation (RBI / HIPAA / SOX). Checklist per release: (1) traceability from requirement → test → evidence, (2) audit trail for every test run (who, when, env, data), (3) sign-offs on P0 flows, (4) data-privacy tests (masking, PII isolation), (5) security scan results (SAST, DAST, SCA), (6) rollback rehearsal. Never release without every box green + regulator-visible evidence.

Tips to remember
  • Walk through build a risk-based release checklist for a regulated product (BFSI / healthcare) as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise build a risk-based release checklist for a regulated product (BFSI / healthcare) cleanly.
  • Reference the specific OWASP category and the check you automate for it, not "we do security testing".
RelatedQ108Q112
← Q109Q111 →
Medium Common 1 minQ111 / 172

Q111.How do you handle a release when 5 P1 defects are still open and the business wants to ship?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

Hands-on "how would you handle a release when 5 P1 defects are still open and the business wants to ship" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Frame it as a business decision, not a QA veto. Present: (1) exact user impact per P1 (workflows blocked, users affected, revenue at risk), (2) rollback plan and monitors, (3) mitigation options (feature flag off, communication, hotfix ETA). Ask leadership to sign the risk acceptance. Document the decision. Never say 'no' alone; never say 'yes' silently.

Tips to remember
  • Walk through handle a release when 5 P1 defects are still open and the business wants to ship as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise handle a release when 5 P1 defects are still open and the business wants to ship cleanly.
  • Finish by saying you always return to the default content after frame work — forgetting that is the classic failure this question hunts for.
RelatedQ109Q113
← Q110Q112 →
Medium Common 1 minQ112 / 172

Q112.What does 'quality is everyone's responsibility' mean at senior level?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on What does 'quality is everyone's responsibility' mean at senior level and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

It means the org's incentives, tooling and processes make quality the default, not the QA team's private effort. Concretely: devs write unit + contract tests, PRs gate on smoke, definition-of-done includes non-functional, on-call is shared, RCAs are blameless, and QA owns strategy + platform tooling, not just test execution. If quality still sits only with QA, the strategy has failed.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on What does 'quality is everyone's responsibility' mean at senior level over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise What does 'quality is everyone's responsibility' mean at senior level cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ110Q114
← Q111Q113 →
Medium Common 1 minQ113 / 172

Q113.Walk me through the architecture of an automation framework you designed.

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Walk me through the architecture of an automation framework you designed and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Answer in layers, not tools: Config layer (env, secrets, feature flags), Driver/API layer (Playwright/Selenium/RestAssured with a factory), Page/Service layer (Page Objects, API service clients), Business-flow layer (reusable domain flows — checkout, onboarding), Test layer (declarative tests, data providers), Reporting layer (Allure/ReportPortal + trend + flake analytics), CI layer (parallel + sharding + retries + gating). Ready to sketch the diagram and justify every choice.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Walk me through the architecture of an automation framework you designed over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Walk me through the architecture of an automation framework you designed cleanly.
  • Add one sentence on what does NOT belong in a page object (assertions, test data) — that boundary is what separates mid from senior answers.
RelatedQ111Q115
← Q112Q114 →
Medium Common 1 minQ114 / 172

Q114.How do you evaluate Playwright vs Selenium in 2026 for a new project?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

Comparison questions like this test whether you understand evaluate Playwright vs Selenium in 2026 for a new project at a design level — not just that both exist, but when to pick one over the other. Panels use it to see if you can defend a trade-off with a real project example.

Detailed explanation

Default to Playwright for web unless the team is deep in Selenium or needs Grid + real-device farms tightly integrated. Playwright wins on speed, auto-wait, tracing, network mocking and TypeScript ergonomics. Selenium still wins on browser breadth via Grid, legacy IE/Edge scenarios, and existing Java ecosystems. Pick per team + product, not per hype.

Tips to remember
  • Structure the answer as a small table in your head: dimension, option A, option B — and close with "I'd pick X when Y".
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise evaluate Playwright vs Selenium in 2026 for a new project cleanly.
  • State that you never mix wait strategies and never use a hard sleep, then give the timeout value you actually run in CI.
RelatedQ112Q116
← Q113Q115 →
Medium Common 1 minQ115 / 172

Q115.How do you scale a suite from 100 tests to 10,000 without exploding the runtime?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Hands-on "how would you scale a suite from 100 tests to 10,000 without exploding the runtime" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

(1) Enforce the test pyramid — push work down from UI to API/component/unit. (2) Parallelise with shards + workers; target < 15 min for the full suite. (3) Selective execution — run only tests touching the changed code (test-impact analysis via git diff + affected modules). (4) Kill duplicates quarterly. (5) Isolate test data per worker. (6) Move slow browser tests to headless containers with tuned CPU/RAM. (7) Cache dependencies. (8) Track suite duration as an SLO.

Tips to remember
  • Walk through scale a suite from 100 tests to 10,000 without exploding the runtime as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise scale a suite from 100 tests to 10,000 without exploding the runtime cleanly.
  • Call out test isolation and shared-state risk (data, sessions, ports) before you talk about worker counts.
RelatedQ113Q117
← Q114Q116 →
Medium Common 1 minQ116 / 172

Q116.How do you handle flake at scale (say, 1% flake across 5,000 tests)?

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Hands-on "how would you handle flake at scale (say, 1% flake across 5,000 tests)" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Root-cause categorisation is the senior move: build a flake dashboard tagging every failure (timing, data, third-party, env). Attack the top category first. Fix > retry: retries hide real bugs. Auto-quarantine tests exceeding a flake budget, assign owner, un-quarantine only after RCA. Publish a weekly flake report. Treat flake as tech debt with a budget, not as inevitable noise.

Tips to remember
  • Walk through handle flake at scale (say, 1% flake across 5,000 tests) as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise handle flake at scale (say, 1% flake across 5,000 tests) cleanly.
  • Say who reads the report and what decision it drives — evidence-for-humans framing beats a tool name list.
RelatedQ114Q118
← Q115Q117 →
Medium Common 1 minQ117 / 172

Q117.What is your approach to framework migration (e.g., Selenium → Playwright) without stopping delivery?

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

Interviewers open with "your approach to framework migration (e.g., Selenium → Playwright) without stopping delivery" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Strangler-fig pattern: (1) run both frameworks side by side in CI. (2) all new tests written in Playwright from day one. (3) migrate high-value / high-flake tests first (biggest ROI). (4) delete migrated Selenium tests same PR. (5) track migration % as a KPI. (6) sunset Selenium infra only after 100% migration + 2 stable release cycles. Never big-bang.

Tips to remember
  • Open with a one-sentence definition of your approach to framework migration (e.g., Selenium → Playwright) without stopping delivery, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise your approach to framework migration (e.g., Selenium → Playwright) without stopping delivery cleanly.
  • Bring numbers: what percentage sits at unit/API/UI and how long the suite takes — strategy answers need a shape.
RelatedQ115Q119
← Q116Q118 →
Easy Common 1 minQ118 / 172

Q118.How do you build reusability across multiple product teams' test suites?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

Hands-on "how would you build reusability across multiple product teams' test suites" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Publish a shared library (npm/Maven) with: reusable Page Object base classes, API service clients, auth helpers, data factories, custom assertions, and reporting hooks. Version it semver, gate breaking changes with an RFC. Product teams consume via package manager, contribute back via PRs. Governance > copy-paste.

Tips to remember
  • Walk through build reusability across multiple product teams' test suites as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise build reusability across multiple product teams' test suites cleanly.
  • Add one sentence on what does NOT belong in a page object (assertions, test data) — that boundary is what separates mid from senior answers.
RelatedQ116Q120
← Q117Q119 →
Easy Common 1 minQ119 / 172

Q119.How do you handle test data at enterprise scale?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

Hands-on "how would you handle test data at enterprise scale" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Three tiers: (1) synthetic factories (Faker + builders) for isolated tests, (2) seeded data via setup APIs with tear-down (test owns lifecycle), (3) anonymised prod snapshots for perf/regression on PII-masked datasets. Never rely on shared mutable state. Test-data service becomes a first-class platform product with SLAs.

Tips to remember
  • Walk through handle test data at enterprise scale as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise handle test data at enterprise scale cleanly.
  • Explain setup/teardown ordering and what runs per-test vs per-suite; ordering mistakes are the follow-up question.
RelatedQ117Q121
← Q118Q120 →
Medium Common 1 minQ120 / 172

Q120.How do you design test observability?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

Hands-on "how would you design test observability" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Every run publishes: results (Allure/ReportPortal), trace (Playwright trace / Selenium video), logs (structured, correlation-id-linked to app logs), metrics (duration, flake, coverage) into a time-series store (Grafana). Dashboards for suite health, flake trend and coverage. Alerts on SLO breach. Observability is the senior differentiator between 'we run tests' and 'we understand our tests'.

Tips to remember
  • Walk through design test observability as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise design test observability cleanly.
  • Say who reads the report and what decision it drives — evidence-for-humans framing beats a tool name list.
RelatedQ118Q122
← Q119Q121 →
Medium Common 1 minQ121 / 172

Q121.How do you design a CI pipeline for a monorepo with 40 services?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

Hands-on "how would you design a CI pipeline for a monorepo with 40 services" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Bazel or Nx-style affected-graph: on PR, detect which services changed via git diff + dependency graph, run only their unit + component + contract tests + smoke of downstream consumers. On merge to main, run full regression on changed services + integration on affected boundaries. Nightly: full E2E + non-functional. Parallelise per service; cache aggressively. Target < 10 min PR feedback.

Tips to remember
  • Walk through design a CI pipeline for a monorepo with 40 services as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise design a CI pipeline for a monorepo with 40 services cleanly.
  • Call out test isolation and shared-state risk (data, sessions, ports) before you talk about worker counts.
RelatedQ119Q123
← Q120Q122 →
Medium Common 1 minQ122 / 172

Q122.How do you run tests in Docker/Kubernetes at scale?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

Hands-on "how would you run tests in Docker/Kubernetes at scale" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Containerise the test runner + browser images (mcr.microsoft.com/playwright, selenium/standalone-chrome). Use K8s Jobs for on-demand runs; auto-scale via HPA on queue depth. Each job gets isolated env vars, secrets from Vault, ephemeral namespace. Pods stream logs + artefacts to S3. Right-size CPU/memory per test type — perf tests need more, unit needs less. Kill zombie pods aggressively.

Tips to remember
  • Walk through run tests in Docker/Kubernetes at scale as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise run tests in Docker/Kubernetes at scale cleanly.
  • Mention pinned browser images and cleanup of containers between runs — panels look for CI cost awareness.
RelatedQ120Q124
← Q121Q123 →
Easy Common 1 minQ123 / 172

Q123.What is your CI/CD gating strategy?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Interviewers open with "your CI/CD gating strategy" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Layered gates: Pre-commit — lint + unit locally. PR — unit + component + contract + smoke (must pass, < 10 min). Merge to main — full regression + integration (must pass). Pre-release — perf + security + a11y + manual sign-off on P0. Post-deploy — canary + synthetic monitors. Never let a broken main last more than 30 minutes.

Tips to remember
  • Open with a one-sentence definition of your CI/CD gating strategy, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise your CI/CD gating strategy cleanly.
  • Describe the pipeline stage order and what makes the build fail — a vague "we run tests in CI" answer stalls here.
RelatedQ121Q125
← Q122Q124 →
Medium Common 1 minQ124 / 172

Q124.How do you decide between self-hosted CI runners and cloud (BrowserStack, Sauce Labs, LambdaTest)?

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Hands-on "how would you decide between self-hosted CI runners and cloud (BrowserStack, Sauce Labs, LambdaTest)" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Cost + control trade-off. Self-hosted Docker/K8s wins on cost at > 500 test-hours/month and gives full control over browser versions, network and data. Cloud farms win on real device matrix (iOS, Android, real Safari), regulatory constraints (no infra to maintain), and low volume. Most mature teams end up hybrid: self-hosted for the bulk, cloud for real-device nightly and long-tail browsers.

Tips to remember
  • Walk through decide between self-hosted CI runners and cloud (BrowserStack, Sauce Labs, LambdaTest) as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise decide between self-hosted CI runners and cloud (BrowserStack, Sauce Labs, LambdaTest) cleanly.
  • Mention pinned browser images and cleanup of containers between runs — panels look for CI cost awareness.
RelatedQ122Q126
← Q123Q125 →
Easy Common 1 minQ125 / 172

Q125.How do you handle secrets, credentials and test data privacy in CI?

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

Hands-on "how would you handle secrets, credentials and test data privacy in CI" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Secrets in Vault / AWS Secrets Manager / GitHub Actions encrypted secrets — never in code, never in logs. Rotate quarterly. PII: mask before use, generate synthetic where possible, never copy prod PII into lower envs without legal + security sign-off. Add pre-commit hooks + secret-scanning in CI to block leaks.

Tips to remember
  • Walk through handle secrets, credentials and test data privacy in CI as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise handle secrets, credentials and test data privacy in CI cleanly.
  • Describe the pipeline stage order and what makes the build fail — a vague "we run tests in CI" answer stalls here.
RelatedQ123Q127
← Q124Q126 →
Easy Common 1 minQ126 / 172

Q126.What is your approach to blue/green and canary release testing?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

Interviewers open with "your approach to blue/green and canary release testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Blue/green: run the full smoke + P0 regression against green before cutover; keep blue warm for instant rollback. Canary: automate 1% → 5% → 25% → 100% rollout with synthetic monitors + real-user-monitoring gates between steps. QA owns the canary rules and the rollback trigger. Test in production is a first-class strategy at senior level.

Tips to remember
  • Open with a one-sentence definition of your approach to blue/green and canary release testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise your approach to blue/green and canary release testing cleanly.
RelatedQ124Q128
← Q125Q127 →
Easy Common 1 minQ127 / 172

Q127.How do you build a performance testing strategy at senior level?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

Hands-on "how would you build a performance testing strategy at senior level" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Define SLOs (p95 latency, throughput, error rate) with product. Baseline every release with k6/JMeter/Gatling in CI. Load, stress, soak and spike tests as separate suites, run nightly. Correlate results with APM (Datadog, New Relic) traces. Publish a perf regression alert on SLO breach. Perf isn't a phase — it's a continuous gate.

Tips to remember
  • Walk through build a performance testing strategy at senior level as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise build a performance testing strategy at senior level cleanly.
  • Use percentiles (P90/P95) and a concrete SLA rather than averages — averages hide the failures interviewers care about.
RelatedQ125Q129
← Q126Q128 →
Easy Common 1 minQ128 / 172

Q128.How do you integrate security testing into the SDLC?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

Hands-on "how would you integrate security testing into the SDLC" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Shift-left across four layers: SAST (SonarQube, Semgrep) in PR, SCA (Snyk, Dependabot) daily, DAST (OWASP ZAP) in staging nightly, and manual pentest quarterly. Every P0/P1 CVE has an SLA to fix. Integrate with security team's ticketing so it's one workflow. Add auth/authz/rate-limit/PII negative tests to the API regression suite.

Tips to remember
  • Walk through integrate security testing into the SDLC as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise integrate security testing into the SDLC cleanly.
  • Reference the specific OWASP category and the check you automate for it, not "we do security testing".
RelatedQ126Q130
← Q127Q129 →
Easy Occasional 1 minQ129 / 172

Q129.What is your accessibility (a11y) strategy?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

Interviewers open with "your accessibility (a11y) strategy" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Automated: axe-core / pa11y in every UI test run, gate on new violations. Manual: keyboard-only + screen-reader (NVDA / VoiceOver) audit per major release. Contract with product: WCAG 2.2 AA is definition-of-done. Track violation count as a quality metric. A11y isn't optional — it's regulatory in EU / US public sector.

Tips to remember
  • Open with a one-sentence definition of your accessibility (a11y) strategy, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise your accessibility (a11y) strategy cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ127Q131
← Q128Q130 →
Medium Occasional 1 minQ130 / 172

Q130.How do you approach chaos engineering from a QA lens?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

Hands-on "how would you approach chaos engineering from a QA lens" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Start with a hypothesis (e.g., 'checkout survives payment-gateway 500ms latency'). Use Gremlin / Chaos Mesh / Litmus to inject failures (latency, packet loss, pod kill, disk-fill) in staging. Assert observability catches it (alerts fire, dashboards show, on-call paged), then assert user impact (graceful degradation, retry, fallback). Progress from staging to production game-days.

Tips to remember
  • Walk through approach chaos engineering from a QA lens as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise approach chaos engineering from a QA lens cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ128Q132
← Q129Q131 →
Medium Occasional 1 minQ131 / 172

Q131.How do you test data pipelines (Spark, Airflow, Kafka)?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Hands-on "how would you test data pipelines (Spark, Airflow, Kafka)" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Layered: Unit — pure transform functions with Great Expectations / pytest. Contract — schema registry (Avro, JSON Schema) tests for producers and consumers. Integration — testcontainers spinning up ephemeral Kafka + DB, assert end-to-end row parity. Data-quality — nightly Great Expectations / dbt tests on prod for freshness, uniqueness, distribution drift. QA co-owns data-quality SLOs.

Tips to remember
  • Walk through test data pipelines (Spark, Airflow, Kafka) as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise test data pipelines (Spark, Airflow, Kafka) cleanly.
  • Mention pinned browser images and cleanup of containers between runs — panels look for CI cost awareness.
RelatedQ129Q133
← Q130Q132 →
Medium Occasional 1 minQ132 / 172

Q132.How do you validate an event-driven architecture (Kafka + microservices)?

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Hands-on "how would you validate an event-driven architecture (Kafka + microservices)" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Contract-first: publish AsyncAPI / Avro schemas, gate schema changes with Pact-for-Kafka. Test producers by asserting emitted event shape; test consumers by feeding synthetic events and asserting side effects. Add lineage tests (event A must eventually trigger DB state B within N seconds). Never test the full chain via UI at scale — it's slow and flaky; test contracts and side effects.

Tips to remember
  • Walk through validate an event-driven architecture (Kafka + microservices) as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise validate an event-driven architecture (Kafka + microservices) cleanly.
  • Quote a real flake-rate number before and after your fix; measured outcomes score far higher than "we added retries".
RelatedQ130Q134
← Q131Q133 →
Easy Occasional 1 minQ133 / 172

Q133.How do you interview and hire senior QA / SDET engineers?

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

Hands-on "how would you interview and hire senior QA / SDET engineers" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

4-round loop: (1) recruiter screen + resume signal, (2) coding + framework design (60 min), (3) system-design or scenario ('scale to 10k tests', 'design a flake-detection service'), (4) behavioural + collaboration. Calibrate every interviewer. Score on evidence, not gut. Aim for false-negative > false-positive — a bad senior hire compounds.

Tips to remember
  • Walk through interview and hire senior QA / SDET engineers as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise interview and hire senior QA / SDET engineers cleanly.
RelatedQ131Q135
← Q132Q134 →
Medium Occasional 1 minQ134 / 172

Q134.How do you mentor a mid-level tester into a senior role?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

Hands-on "how would you mentor a mid-level tester into a senior role" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

90-day plan: (1) give them ownership of a cross-cutting initiative (framework upgrade, flake budget), (2) shadow senior meetings — architecture, planning, RCAs, (3) pair on writing an RFC or governance doc, (4) sponsor them for a talk or blog post, (5) publish a quarterly growth review with concrete promotion criteria. Mentorship > task assignment.

Tips to remember
  • Walk through mentor a mid-level tester into a senior role as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise mentor a mid-level tester into a senior role cleanly.
RelatedQ132Q136
← Q133Q135 →
Medium Occasional 1 minQ135 / 172

Q135.How do you handle an underperforming team member?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

Hands-on "how would you handle an underperforming team member" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Structured, documented, kind: (1) private 1:1 — describe specific behaviour + impact, agree on written goals with dates. (2) weekly check-ins with progress notes. (3) if no improvement after 60 days, formal PIP with HR. (4) if PIP fails, exit respectfully. Never surprise, never public, never emotional. Protect the team's morale while giving the individual a real chance.

Tips to remember
  • Walk through handle an underperforming team member as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise handle an underperforming team member cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ133Q137
← Q134Q136 →
Easy Occasional 1 minQ136 / 172

Q136.How do you present QA metrics to engineering leadership?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

Hands-on "how would you present QA metrics to engineering leadership" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Three slides max: (1) trend chart of escape rate + release velocity, (2) top 3 risks + owners + ETAs, (3) 1 ask (headcount, budget, exec sponsorship). Speak in business language — revenue at risk, hours saved, spend avoided. Never dump tool trivia on leadership; they need decisions, not data.

Tips to remember
  • Walk through present QA metrics to engineering leadership as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise present QA metrics to engineering leadership cleanly.
RelatedQ134Q138
← Q135Q137 →
Easy Occasional 1 minQ137 / 172

Q137.How do you handle a peer engineering manager who disagrees with your quality gate?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

Hands-on "how would you handle a peer engineering manager who disagrees with your quality gate" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Meet 1:1 first, understand their constraint (velocity pressure, headcount). Bring data — leakage cost, incident hours, customer impact. Propose a compromise (e.g., gate on P0 flows only, allow P2 flake). Escalate to shared skip-level only if genuinely blocked, framed as 'help us align', not as 'they're wrong'. Preserve the relationship.

Tips to remember
  • Walk through handle a peer engineering manager who disagrees with your quality gate as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise handle a peer engineering manager who disagrees with your quality gate cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ135Q139
← Q136Q138 →
Easy Occasional 1 minQ138 / 172

Q138.What does a senior QA / SDET's first 90 days look like at a new company?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on What does a senior QA / SDET's first 90 days look like at a new company and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Days 1–30 — listen: shadow releases, read RCAs, meet dev + PM + SRE leads, baseline metrics. Days 31–60 — one small win (fix top flake source, land a smoke pipeline, kill one duplicate suite). Days 61–90 — publish a 6-month quality roadmap with SLOs, owners, and asks. Never propose big change before day 30. Never coast past day 60.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on What does a senior QA / SDET's first 90 days look like at a new company over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise What does a senior QA / SDET's first 90 days look like at a new company cleanly.
  • Describe the pipeline stage order and what makes the build fail — a vague "we run tests in CI" answer stalls here.
RelatedQ136Q140
← Q137Q139 →
Medium Occasional 1 minQ139 / 172

Q139.Tell me about the biggest production incident you owned as senior QA (STAR).

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Tell me about the biggest production incident you owned as senior QA (STAR) and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Situation — payment webhook stopped processing for 40 minutes during peak, $180k revenue at risk. Task — coordinate war-room, RCA, and prevention. Action — pulled logs + traces, identified consumer-lag from a schema mismatch missed by contract tests (the consumer test used stale fixtures). Coordinated hotfix + replay, then owned RCA: added dynamic-fixture contract testing, alert on consumer-lag > 30 s, quarterly schema drift review. Result — zero payment incidents in 6 months; pattern adopted org-wide for all Kafka consumers.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Tell me about the biggest production incident you owned as senior QA (STAR) over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Tell me about the biggest production incident you owned as senior QA (STAR) cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ137Q141
← Q138Q140 →
Medium Occasional 1 minQ140 / 172

Q140.Tell me about a time you changed a team's quality culture (STAR).

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Tell me about a time you changed a team's quality culture (STAR) and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Situation — new team, escape rate at 18%, QA seen as gatekeeper. Task — reduce leakage and shift-left ownership. Action — ran a blameless leakage retro, published a shift-left playbook (PR gates, contract tests, story-level acceptance), paired 1:1 with each dev on their first contract test, and made escape rate a shared team OKR. Result — leakage down to 3% in 2 quarters, devs writing 60% of new automated tests, QA time freed for perf + exploratory.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Tell me about a time you changed a team's quality culture (STAR) over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Tell me about a time you changed a team's quality culture (STAR) cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ138Q142
← Q139Q141 →
Medium Occasional 1 minQ141 / 172

Q141.Tell me about a time you disagreed with your engineering director (STAR).

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Tell me about a time you disagreed with your engineering director (STAR) and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Situation — director wanted to ship a payment feature without perf testing 'because it's low traffic'. Task — protect the release without stonewalling. Action — brought data on similar 'low traffic' features that spiked 30× at launch, offered a 4-hour k6 baseline instead of a 2-day full perf, and volunteered to run it overnight. Result — perf found a DB connection-pool exhaustion at 200 concurrent users; fixed pre-release; feature launched successfully at 8× projected load. Director now defaults to including QA in launch reviews.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Tell me about a time you disagreed with your engineering director (STAR) over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Tell me about a time you disagreed with your engineering director (STAR) cleanly.
RelatedQ139Q143
← Q140Q142 →
Medium Occasional 1 minQ142 / 172

Q142.Tell me about a time you scaled a QA team (STAR).

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Tell me about a time you scaled a QA team (STAR) and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Situation — company grew from 1 to 5 product squads in 9 months; QA team of 3. Task — scale quality without linear headcount growth. Action — reorganised: 1 SDET embedded per squad (hired 2), central platform-QA team of 3 owning framework + CI + non-functional. Published governance model, shared library, weekly office hours. Result — squads shipped independently, escape rate held at 4% across 5 squads with 1.6× headcount instead of 5× — a measurable leverage win for leadership.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Tell me about a time you scaled a QA team (STAR) over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Tell me about a time you scaled a QA team (STAR) cleanly.
RelatedQ140Q144
← Q141Q143 →
Medium Occasional 1 minQ143 / 172

Q143.Tell me about a time you had to say 'no' to a launch (STAR).

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Tell me about a time you had to say 'no' to a launch (STAR) and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Situation — SDK release with an unfixed security CVE (medium severity, active exploit in the wild). Task — decide whether to gate. Action — presented CVE details, customer exposure and 2-day patch ETA to product, engineering and security. Recommended a 48-hour delay with a written risk-acceptance if leadership disagreed. Result — leadership accepted the delay; patched CVE shipped with the SDK; no customer incident. Established a monthly CVE-triage that now runs org-wide.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Tell me about a time you had to say 'no' to a launch (STAR) over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Tell me about a time you had to say 'no' to a launch (STAR) cleanly.
  • Reference the specific OWASP category and the check you automate for it, not "we do security testing".
RelatedQ141Q145
← Q142Q144 →
Medium Occasional 1 minQ144 / 172

Q144.Why should we hire you at senior level over an internal promotion candidate?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

"Why" questions on should we hire you at senior level over an internal promotion candidate probe your reasoning, not your memory. Strong candidates connect the choice to a business or reliability outcome — flaky tests, slower feedback loop, or missed defects — instead of parroting a rule.

Detailed explanation

Frame it in three parts: (1) outside pattern-library — you've shipped X frameworks, seen Y architectures fail, hired Z SDETs across N companies; (2) specific alignment — one thing on their engineering blog or JD you can start attacking day one (e.g., their public post about flaky CI); (3) humility — you'll spend the first 30 days listening before proposing. Never disparage internal candidates; position yourself as complementary, not competing.

Tips to remember
  • Tie the "why" for should we hire you at senior level over an internal promotion candidate back to a measurable outcome — flake rate, execution time, defect leakage — instead of an opinion.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise should we hire you at senior level over an internal promotion candidate cleanly.
  • Finish by saying you always return to the default content after frame work — forgetting that is the classic failure this question hunts for.
RelatedQ142Q146
← Q143Q145 →
Confidence check

If you can confidently answer the Senior / SDET (5+ yrs) questions above, you're well prepared for this section of your interview. Move on, or rehearse the trickier ones aloud with our AI mock interviewer.

4. Software Testing Fundamentals

Medium Occasional 1 minQ145 / 172

Q145.What are the 7 principles of testing?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

Interviewers open with "7 principles of testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

(1) Testing shows the presence of defects, not their absence. (2) Exhaustive testing is impossible. (3) Early testing saves time and money. (4) Defects cluster together. (5) The pesticide paradox — same tests stop finding bugs. (6) Testing is context-dependent. (7) Absence-of-errors is a fallacy — a bug-free app that solves the wrong problem still fails.

Tips to remember
  • Open with a one-sentence definition of 7 principles of testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise 7 principles of testing cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ143Q147
← Q144Q146 →
Easy Occasional 1 minQ146 / 172

Q146.What is severity vs priority?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

Interviewers open with "severity vs priority" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Severity = business impact (Critical/High/Medium/Low). Priority = urgency to fix (P1/P2/P3/P4). A misspelled company name on the homepage is low severity but high priority; a crash on a rarely used admin feature is high severity but low priority.

Tips to remember
  • Open with a one-sentence definition of severity vs priority, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise severity vs priority cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ144Q148
← Q145Q147 →
Confidence check

If you can confidently answer the Software Testing Fundamentals questions above, you're well prepared for this section of your interview. Move on, or rehearse the trickier ones aloud with our AI mock interviewer.

5. Manual Testing Essentials

Easy Occasional 1 minQ147 / 172

Q147.How do you write a good test case?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Hands-on "how would you write a good test case" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Unique ID, clear title, precondition, atomic steps, single expected result, traceability to a requirement, priority, no dependency on other tests. Rule of thumb: another tester should reproduce it exactly from your steps alone. See our Manual Testing Q&A hub for 42 more.

Tips to remember
  • Walk through write a good test case as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise write a good test case cleanly.
  • Say who reads the report and what decision it drives — evidence-for-humans framing beats a tool name list.
RelatedQ145Q149
← Q146Q148 →
Easy Occasional 1 minQ148 / 172

Q148.What information should a bug report contain?

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on What information should a bug report contain and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Title, environment (browser/OS/build/device), preconditions, exact repro steps, actual vs expected result, severity, priority, screenshots/video, console + network logs, reproducibility %, and a link to the failing test case.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on What information should a bug report contain over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise What information should a bug report contain cleanly.
  • Say who reads the report and what decision it drives — evidence-for-humans framing beats a tool name list.
RelatedQ146Q150
← Q147Q149 →
Confidence check

If you can confidently answer the Manual Testing Essentials questions above, you're well prepared for this section of your interview. Move on, or rehearse the trickier ones aloud with our AI mock interviewer.

6. Automation Testing Essentials

Easy Occasional 1 minQ149 / 172

Q149.When should you automate a test?

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

Timing questions like this check whether you understand the trade-offs of automate a test. Interviewers want to hear the specific signals in a project that make you pick it over the alternative, plus one case where it's the wrong choice.

Detailed explanation

Automate when the test is (1) repeatable across builds, (2) stable in requirements, (3) high-value (top revenue flows), and (4) low-flake in the target environment. Do NOT automate one-off exploratory checks, UX-subjective screens, or captchas.

Tips to remember
  • Answer in the form "Use automate a test when …, avoid it when …" so the interviewer hears both sides in one breath.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise automate a test cleanly.
RelatedQ147Q151
← Q148Q150 →
Medium Occasional 1 minQ150 / 172

Q150.What is the Page Object Model (POM)?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

Interviewers open with "Page Object Model (POM)" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

POM encapsulates a page's locators and actions in a class. Tests call loginPage.loginAs(user) instead of raw driver.findElement(...). Benefits: single point of change when the UI shifts, reusable actions, cleaner tests. See Automation Q&A.

Tips to remember
  • Open with a one-sentence definition of Page Object Model (POM), then a concrete Software Testing example — never start with history or theory.
  • Be ready to whiteboard the Page Object Model (POM) snippet live — panels often ask you to type it, not describe it.
  • Add one sentence on what does NOT belong in a page object (assertions, test data) — that boundary is what separates mid from senior answers.
RelatedQ148Q152
← Q149Q151 →
Easy Occasional 1 minQ151 / 172

Q151.Selenium vs Playwright — which should I pick in 2026?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

Comparison questions like this test whether you understand Selenium vs Playwright — which should I pick in 2026 at a design level — not just that both exist, but when to pick one over the other. Panels use it to see if you can defend a trade-off with a real project example.

Detailed explanation

Playwright wins for new projects: built-in auto-waits, first-class trace viewer, parallel by default, network stubbing, cross-browser without Grid. Selenium still wins for legacy suites, IE/older browsers, and Selenium Grid infra investments. See Playwright vs Selenium 2026.

Tips to remember
  • Structure the answer as a small table in your head: dimension, option A, option B — and close with "I'd pick X when Y".
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Selenium vs Playwright — which should I pick in 2026 cleanly.
  • State that you never mix wait strategies and never use a hard sleep, then give the timeout value you actually run in CI.
RelatedQ149Q153
← Q150Q152 →
Easy Occasional 1 minQ152 / 172

Q152.What is a good test pyramid?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

Interviewers open with "good test pyramid" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

~70% unit + component tests (fast, cheap), ~20% API/integration tests (medium), ~10% end-to-end UI tests (slow, brittle). Inverting the pyramid ('ice-cream cone') is the #1 cause of flaky, slow CI pipelines.

Tips to remember
  • Open with a one-sentence definition of good test pyramid, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise good test pyramid cleanly.
  • Quote a real flake-rate number before and after your fix; measured outcomes score far higher than "we added retries".
RelatedQ150Q154
← Q151Q153 →
Easy Occasional 1 minQ153 / 172

Q153.How do you handle flaky tests?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

Hands-on "how would you handle flaky tests" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Diagnose the root cause (timing, test data, environment, order-dependence) before retrying. Use explicit waits, isolate test data per run, reset state via API (not UI), pin browser versions, and quarantine chronically flaky tests instead of hiding them behind retries.

Tips to remember
  • Walk through handle flaky tests as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise handle flaky tests cleanly.
  • State that you never mix wait strategies and never use a hard sleep, then give the timeout value you actually run in CI.
RelatedQ151Q155
← Q152Q154 →
Medium Occasional 1 minQ154 / 172

Q154.What is data-driven testing?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

Interviewers open with "data-driven testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Same test logic runs against multiple data sets from CSV/JSON/DB/Excel. Frameworks: TestNG @DataProvider, JUnit 5 @ParameterizedTest, Playwright test.describe.parallel with a data array. Keeps test code DRY and expands coverage cheaply.

Tips to remember
  • Open with a one-sentence definition of data-driven testing, then a concrete Software Testing example — never start with history or theory.
  • Be ready to whiteboard the data-driven testing snippet live — panels often ask you to type it, not describe it.
  • Call out test isolation and shared-state risk (data, sessions, ports) before you talk about worker counts.
RelatedQ152Q156
← Q153Q155 →
Confidence check

If you can confidently answer the Automation Testing Essentials questions above, you're well prepared for this section of your interview. Move on, or rehearse the trickier ones aloud with our AI mock interviewer.

7. API & Database Testing

Easy Occasional 1 minQ155 / 172

Q155.What is API testing?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Interviewers open with "API testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

API testing validates requests and responses at the service layer — status codes, headers, payload schema, business rules, auth, and performance. Tools: Postman, REST Assured, Playwright, k6, Karate. See API Q&A hub.

Tips to remember
  • Open with a one-sentence definition of API testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise API testing cleanly.
  • Assert status, schema and business payload — naming all three signals you test contracts, not just happy paths.
RelatedQ153Q157
← Q154Q156 →
Easy Occasional 1 minQ156 / 172

Q156.What are the common HTTP status codes testers must know?

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Interviewers open with "common HTTP status codes testers must know" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

2xx success (200 OK, 201 Created, 204 No Content). 3xx redirect (301, 304). 4xx client (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 429 Too Many Requests). 5xx server (500 Internal Server Error, 502, 503, 504).

Tips to remember
  • Open with a one-sentence definition of common HTTP status codes testers must know, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise common HTTP status codes testers must know cleanly.
  • Assert status, schema and business payload — naming all three signals you test contracts, not just happy paths.
RelatedQ154Q158
← Q155Q157 →
Easy Occasional 1 minQ157 / 172

Q157.Difference between PUT, POST and PATCH?

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

Comparison questions like this test whether you understand PUT, POST vs PATCH at a design level — not just that both exist, but when to pick one over the other. Panels use it to see if you can defend a trade-off with a real project example.

Detailed explanation

POST creates a resource (not idempotent). PUT replaces a resource fully (idempotent). PATCH partially updates specific fields (idempotent when applied to the same state).

Tips to remember
  • Structure the answer as a small table in your head: dimension, option A, option B — and close with "I'd pick X when Y".
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise PUT, POST vs PATCH cleanly.
RelatedQ155Q159
← Q156Q158 →
Easy Occasional 1 minQ158 / 172

Q158.What is contract testing?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

Interviewers open with "contract testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Verifies that the API request/response contract between consumer and provider holds — even when either evolves independently. Tools: Pact (consumer-driven), Spring Cloud Contract. Prevents 'my service works but breaks yours' incidents in microservices.

Tips to remember
  • Open with a one-sentence definition of contract testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise contract testing cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ156Q160
← Q157Q159 →
Easy Occasional 1 minQ159 / 172

Q159.What SQL joins do QA engineers need to know?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on What SQL joins do QA engineers need to know and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

INNER JOIN — matching rows in both tables. LEFT JOIN — all left + matched right. RIGHT JOIN — reverse. FULL OUTER JOIN — all rows from both, nulls where no match. SELF JOIN — table joined to itself. See SQL Q&A for testers.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on What SQL joins do QA engineers need to know over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise What SQL joins do QA engineers need to know cleanly.
  • Say how you clean up or roll back the data you touch — DB questions are really data-hygiene questions.
RelatedQ157Q161
← Q158Q160 →
Medium Occasional 1 minQ160 / 172

Q160.How do you validate data in the database after a UI action?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

Hands-on "how would you validate data in the database after a UI action" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

(1) Capture the primary key returned by the UI/API. (2) Run a SELECT against the target table with that key. (3) Assert row exists, column values match input, audit columns populated (created_at, updated_by). (4) Clean up test data or run inside a transaction rolled back at teardown.

Tips to remember
  • Walk through validate data in the database after a UI action as numbered steps and call out the tool, command, or API used at each step.
  • Be ready to whiteboard the validate data in the database after a UI action snippet live — panels often ask you to type it, not describe it.
  • Say how you clean up or roll back the data you touch — DB questions are really data-hygiene questions.
RelatedQ158Q162
← Q159Q161 →
Confidence check

If you can confidently answer the API & Database Testing questions above, you're well prepared for this section of your interview. Move on, or rehearse the trickier ones aloud with our AI mock interviewer.

8. SDET, Agile & CI/CD

Easy Occasional 1 minQ161 / 172

Q161.What is an SDET?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

Interviewers open with "SDET" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

SDET (Software Development Engineer in Test) writes production-grade test code, frameworks, tooling, and CI/CD pipelines. Expected to code fluently in one language (Java/Python/JS), design frameworks, review PRs, and own quality end-to-end. See SDET Q&A hub.

Tips to remember
  • Open with a one-sentence definition of SDET, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise SDET cleanly.
  • Describe the pipeline stage order and what makes the build fail — a vague "we run tests in CI" answer stalls here.
RelatedQ159Q163
← Q160Q162 →
Easy Occasional 1 minQ162 / 172

Q162.What is shift-left testing?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

Interviewers open with "shift-left testing" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

Involving QA earlier in SDLC — requirement grooming, story-point estimation, unit-test reviews, contract definition. Cuts defect-fix cost by 6–10× (bug found in prod vs bug found in design).

Tips to remember
  • Open with a one-sentence definition of shift-left testing, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise shift-left testing cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ160Q164
← Q161Q163 →
Easy Occasional 1 minQ163 / 172

Q163.How does QA fit into Agile / Scrum?

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Hands-on "how would you QA fit into Agile / Scrum" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

QA is embedded in the squad, not a downstream gate. Participates in refinement (adds acceptance criteria), sprint planning (test estimates), daily standups (blocker calls), and demos (validation). Definition-of-Done includes automated tests + no P1/P2 open.

Tips to remember
  • Walk through QA fit into Agile / Scrum as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise QA fit into Agile / Scrum cleanly.
  • Anchor the answer to a ceremony and an artefact (definition of done, story acceptance criteria) from a team you worked in.
RelatedQ161Q165
← Q162Q164 →
Easy Occasional 1 minQ164 / 172

Q164.What is CI/CD from a QA lens?

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

Interviewers open with "CI/CD from a QA lens" to confirm you can define the concept in one crisp line before going deeper. In Software Testing rounds this filters out candidates who only remember syntax and can't articulate the underlying idea to a non-expert teammate.

Detailed explanation

CI = every commit is built + unit + component + API tested automatically. CD = every green build is deployable (Continuous Delivery) or auto-deployed (Continuous Deployment). QA owns pipeline gates: unit → API → smoke UI → full regression → performance.

Tips to remember
  • Open with a one-sentence definition of CI/CD from a QA lens, then a concrete Software Testing example — never start with history or theory.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise CI/CD from a QA lens cleanly.
  • Describe the pipeline stage order and what makes the build fail — a vague "we run tests in CI" answer stalls here.
RelatedQ162Q166
← Q163Q165 →
Easy Occasional 1 minQ165 / 172

Q165.What metrics do you track in QA?

Asked byAmazonCapgeminiTCSMicrosoft
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on What metrics do you track in QA and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Defect density, defect leakage %, escaped-defect trend, automation coverage %, mean-time-to-detect, mean-time-to-fix, flaky-test %, CI green-build %, sprint acceptance-criteria pass rate.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on What metrics do you track in QA over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise What metrics do you track in QA cleanly.
  • Quote a real flake-rate number before and after your fix; measured outcomes score far higher than "we added retries".
RelatedQ163Q167
← Q164Q166 →
Easy Occasional 1 minQ166 / 172

Q166.How do you decide test coverage is 'enough' to ship?

Asked byWiproAmazonCapgeminiTCS
Why interviewers ask this

Hands-on "how would you decide test coverage is 'enough' to ship" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Risk-based: cover every P0/P1 acceptance criterion, top-5 revenue flows, top-5 defect-density modules, and any changed code. 100% coverage is a myth — aim for coverage of business risk, not lines of code.

Tips to remember
  • Walk through decide test coverage is 'enough' to ship as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise decide test coverage is 'enough' to ship cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ164Q168
← Q165Q167 →
Confidence check

If you can confidently answer the SDET, Agile & CI/CD questions above, you're well prepared for this section of your interview. Move on, or rehearse the trickier ones aloud with our AI mock interviewer.

9. Scenario-Based & Behavioral

Easy Occasional 1 minQ167 / 172

Q167.A build fails only in the CI environment but passes locally. How do you debug?

Asked byTCSMicrosoftAccentureInfosys
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on A build fails only in the CI environment but passes locally. How do you debug and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Compare env vars, browser version, screen resolution, network policy, test data isolation, timezone, and race conditions with parallel workers. Reproduce inside the same Docker image CI uses. Capture Playwright trace / Selenium video from CI to see the exact failure step.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on A build fails only in the CI environment but passes locally. How do you debug over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise A build fails only in the CI environment but passes locally. How do you debug cleanly.
  • Call out test isolation and shared-state risk (data, sessions, ports) before you talk about worker counts.
RelatedQ165Q169
← Q166Q168 →
Easy Occasional 1 minQ168 / 172

Q168.You have 500 regression tests and only 2 hours in the release window. What do you cut?

Asked byCapgeminiTCSMicrosoftAccenture
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on You have 500 regression tests and only 2 hours in the release window. What do you cut and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Keep: (1) top revenue flows, (2) recently changed modules, (3) tests protecting past P1 defects. Cut: duplicates, deprecated features, low-risk cosmetic checks. Run the trimmed set in parallel to fit the window and schedule the full suite post-release.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on You have 500 regression tests and only 2 hours in the release window. What do you cut over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise You have 500 regression tests and only 2 hours in the release window. What do you cut cleanly.
  • Call out test isolation and shared-state risk (data, sessions, ports) before you talk about worker counts.
RelatedQ166Q170
← Q167Q169 →
Easy Occasional 1 minQ169 / 172

Q169.The developer says a bug is 'not reproducible'. What do you do?

Asked byAccentureInfosysCognizantWipro
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on The developer says a bug is 'not reproducible'. What do you do and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Re-verify in a clean environment with exact steps, capture video + logs + HAR, share back. If still disagreed, escalate with the requirement reference and a screen recording — never argue on Slack without evidence.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on The developer says a bug is 'not reproducible'. What do you do over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise The developer says a bug is 'not reproducible'. What do you do cleanly.
RelatedQ167Q171
← Q168Q170 →
Easy Occasional 1 minQ170 / 172

Q170.A stakeholder asks for 100% automation. How do you respond?

Asked byMicrosoftAccentureInfosysCognizant
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on A stakeholder asks for 100% automation. How do you respond and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Explain that automation ROI drops after ~80% because remaining tests are exploratory, visual, subjective, or one-off. Propose a target of 70–80% automated regression + 100% CI gating on smoke, backed by defect-leakage metrics — not a raw automation-% target.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on A stakeholder asks for 100% automation. How do you respond over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise A stakeholder asks for 100% automation. How do you respond cleanly.
  • Give the severity-vs-priority example from your own project — generic definitions score the lowest on this one.
RelatedQ168Q172
← Q169Q171 →
Easy Occasional 1 minQ171 / 172

Q171.How do you test a login page? (open-ended)

Asked byCognizantWiproAmazonCapgemini
Why interviewers ask this

Hands-on "how would you test a login page? (open-ended)" questions reveal whether you've actually shipped Software Testing code or only read about it. Interviewers listen for concrete steps, the tools you'd reach for first, and the failure mode you'd guard against.

Detailed explanation

Positive (valid creds), negative (invalid password, empty fields, SQL injection, XSS), boundary (max username length), security (rate-limit, brute-force, forgot-password token expiry), session (concurrent logins, remember-me), accessibility (keyboard-only, screen reader), performance (100 concurrent logins), API-layer (401/403 responses).

Tips to remember
  • Walk through test a login page? (open-ended) as numbered steps and call out the tool, command, or API used at each step.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise test a login page? (open-ended) cleanly.
  • Cover token expiry and refresh in your answer; most candidates only describe the happy-path login.
RelatedQ169
← Q170Q172 →
Easy Occasional 1 minQ172 / 172

Q172.Tell me about a bug you're proud of finding.

Asked byInfosysCognizantWiproAmazon
Why interviewers ask this

This Software Testing question checks whether you can go beyond textbook knowledge on Tell me about a bug you're proud of finding and reason about it the way a working QA engineer does — with a definition, an example, and the edge case that usually comes up next.

Detailed explanation

Use STAR: Situation (context and stakes), Task (what you owned), Action (how you designed the test / spotted the anomaly), Result (impact avoided, in $ or user reach). Pick a bug with data — 'prevented a $40K refund incident' beats 'found a payment bug'.

Tips to remember
  • Anchor the answer in a real Software Testing project — panels reward specificity on Tell me about a bug you're proud of finding over textbook wording.
  • Keep the answer to 60–90 seconds; anything longer signals you can't summarise Tell me about a bug you're proud of finding cleanly.
  • Tie contract checks to the consumer/provider workflow and where the contract is stored — that's the senior detail panels wait for.
RelatedQ170
← Q171
Confidence check

If you can confidently answer the Scenario-Based & Behavioral questions above, you're well prepared for this section of your interview. Move on, or rehearse the trickier ones aloud with our AI mock interviewer.

Quick revision

  1. Q1: What is software testing — Software testing is the process of evaluating a software application to detect defects, verify it meets specified requirements, and validate it satisfies real user needs.
  2. Q2: Why is software testing important — Testing prevents costly production failures, ensures compliance in regulated industries (banking, healthcare), protects user data, and validates that features match business intent
  3. Q3: What is the difference between verification and validation — Verification checks the product is built to specification — reviews, walkthroughs, inspections, static analysis.
  4. Q4: What is the difference between quality assurance, quality control, and testing — QA is process-focused and preventive (standards, audits, methodology).
  5. Q5: What is a test case — A test case is a documented set of steps, inputs, preconditions, and expected results used to verify a specific feature or requirement.

Frequently asked questions

1.What are the most asked software testing interview questions in 2026?
The 2026 shortlist: SDLC vs STLC, severity vs priority, bug life cycle, boundary value analysis, smoke vs sanity, regression vs retesting, POM, API status codes, joins in SQL, and a real defect you found — every one is answered on this page.
2.How should I prepare for a software testing interview?
Split prep into 5 tracks: (1) fundamentals + ISTQB glossary, (2) one automation tool (Selenium or Playwright), (3) API testing with Postman, (4) SQL joins + aggregates, (5) 8–10 STAR behavioral stories. Rehearse out loud with an AI mock interviewer for pace and clarity.
3.Which topics have the highest weight in QA interviews?
For 0–3 YOE: manual fundamentals (30%), automation basics (25%), API + SQL (25%), behavioral (20%). For 4+ YOE: framework design (30%), CI/CD + parallelism (20%), test strategy (20%), leadership + scenarios (30%).
4.How many rounds are typical in a QA interview?
Startups: 2–3 (screen, tech, culture). Product companies: 4–6 (screen, coding, framework design, system design for QA, behavioral, bar-raiser). Service companies: 2–4 (aptitude, tech, manager, HR).
5.Is manual testing still relevant in 2026?
Yes — 45% of open QA roles still list manual/exploratory testing, especially in BFSI, healthcare, insurance, and government. Domain-heavy testing, UAT, accessibility auditing, and usability cannot be fully automated.
6.What is the salary range for QA engineers in 2026?
India: Freshers ₹3.5–5 LPA, mid-level ₹8–15 LPA, senior ₹18–35 LPA. USA: junior $70–95K, mid $95–130K, senior $130–180K. SDETs at FAANG-tier: $180K–280K total comp.
7.What is the difference between QA, tester and SDET?
QA owns quality process end-to-end (planning, metrics, sign-off). Tester primarily executes tests (manual or automated). SDET writes production-grade test code, frameworks, and CI/CD pipelines — closer to a software engineer specialised in quality.
8.Can I clear a QA interview without coding?
Yes for pure manual/functional roles at service companies. No for SDET, automation engineer, or product-company QA roles — expect a coding round (Python/Java/JS) plus a framework or system-design discussion.
9.What are the most asked software testing interview questions for freshers?
The 2026 fresher shortlist includes: What is software testing, difference between verification and validation, SDLC vs STLC, severity vs priority, bug life cycle, boundary value analysis, equivalence partitioning, smoke vs sanity testing, regression testing, and difference between manual and automation testing. All 10 are covered on this page with sample answers.
10.How should a fresher prepare for a QA interview in 2026?
Master fundamentals (SDLC, STLC, test design), write 5 real test cases for an app you use daily, learn basic SQL and one automation tool (Selenium or Playwright), practice bug reports, and rehearse the top 40 Q&A on this page against our free AI Mock Interview.
11.Do freshers need to know automation to get a QA job?
Not always — many entry-level manual QA roles hire freshers with strong test-design skills. But knowing basic Selenium or Playwright adds 20–30% to fresher salary offers in 2026 and unlocks SDET tracks.
12.What is the salary for a fresher software tester in India (2026)?
Entry-level manual QA freshers earn ₹3.5–5 LPA in Tier-1 cities; automation-aware freshers with Selenium or Playwright earn ₹5–7 LPA; SDET-track freshers in product companies earn ₹8–12 LPA.
13.Which certification helps a fresher tester most?
ISTQB Foundation Level (CTFL) is the most recognized entry certification — it maps directly to fresher interview vocabulary (severity, priority, test design, defect life cycle). Pair it with a hands-on Selenium or Playwright course.
14.What is the difference between QA and testing?
Quality Assurance is a process-oriented activity that prevents defects (reviews, standards, audits). Testing is a product-oriented activity that detects defects by executing the software. QA is proactive; testing is reactive.

Software Testing jobs hiring now

Live, indexable Software Testing openings — updated daily in Jobs Radar.

Browse all QA jobs on Jobs Radar

Loading current openings…

Home