QA & Testing interview questions

Software testing: evaluating software to find defects and confirm it meets requirements before delivery to users. Why it matters: - Cost multiplier: a bug in production costs 10x-100x more to fix than one found in development - User trust: production defects damage brand reputation and retention - Safety: in banking, healthcare, aviation — bugs cause financial loss or physical harm - Compliance: BFSI, healthcare, and government products have regulatory testing requirements Two core goals: - Verification: "are we building the product right?" — does code match the spec? - Validation: "are we building the right product?" — does it solve the real user problem? Beyond finding bugs, testing also: - Gives confidence to deploy safely - Documents expected system behaviour - Acts as a regression safety net during refactoring Principle: the earlier defects are found, the cheaper they are to fix. A defect found at requirements stage costs ~1x; at production it costs ~100x. This drives shift-left testing.

Four main testing levels, from narrowest to broadest: 1. Unit Testing - Tests a single function/method/class in isolation - Dependencies are mocked or stubbed - Runs fast (milliseconds), developers write them - Tools: JUnit, NUnit, Jest, PyTest 2. Integration Testing - Tests how multiple units/modules work together - Catches interface mismatches, DB/API interaction bugs - Strategies: big bang, top-down, bottom-up, sandwich - Tools: Postman, RestAssured, Spring Test 3. System Testing - Tests the entire application end-to-end as a whole - Verifies functional + non-functional requirements - Run by QA team on a staging environment - Includes: functional, performance, security, usability 4. Acceptance Testing (UAT) - Validates software meets business requirements - Run by end users or product team - Types: Alpha (internal), Beta (external), Contract, Regulatory - Uses real production-like data Progression: unit catches logic bugs early and cheaply; acceptance confirms real-world fitness. All four levels are needed — skipping early levels makes later levels slower and more expensive.

The test pyramid (coined by Mike Cohn) describes the ideal ratio of tests across three layers: Top (small) — End-to-End tests - Test the full stack via a real browser/API - Slow (seconds to minutes), brittle, expensive to maintain - Run: a small critical-path subset (e.g., login, checkout) Middle — Integration / Service tests - Test component interactions (service + DB, API contracts) - Faster than E2E, more stable - Cover inter-module contracts Base (wide) — Unit tests - Test individual functions in isolation - Fast (milliseconds), cheap, developer-owned - Cover all logic branches and edge cases Ideal ratio: ~70% unit, ~20% integration, ~10% E2E Why it matters: - Inverted pyramid (mostly E2E) = slow CI, brittle suite, expensive fixes - Pure unit tests miss integration bugs - Following the pyramid gives: fast feedback, stable suite, full coverage Anti-pattern: "ice cream cone" — tiny base of unit tests, massive E2E suite. This makes CI slow and fragile.

Three classifications based on visibility into the system under test: Black-box testing: - Tester has NO knowledge of internal code or architecture - Tests based only on inputs/outputs and requirements - Who: QA testers, end users - Techniques: equivalence partitioning, boundary value analysis, decision tables - Good for: functional testing, UAT White-box testing (Glass-box / Clear-box): - Tester has FULL access to source code - Tests cover internal paths, branches, loops, conditions - Who: developers - Techniques: statement coverage, branch coverage, path coverage - Good for: unit testing, security testing, code optimization Grey-box testing: - Tester has PARTIAL knowledge (e.g., knows the DB schema, APIs, but not internal logic) - Combines both approaches - Who: QA with partial access to architecture docs / API specs - Good for: integration testing, API testing, web application testing Summary: - Black-box → spec-driven, user perspective - White-box → code-driven, developer perspective - Grey-box → architecture-aware, practical balance

Regression testing: re-running existing tests after a code change to verify that previously working functionality has not broken. When to run: - After any bug fix (confirm the fix doesn't break other areas) - After new feature addition (new code may have side effects) - After refactoring (behaviour should remain identical) - After dependency upgrades (third-party changes can break integrations) - Before every release Types: - Full regression: run the entire test suite. Comprehensive but slow. - Partial/selective regression: run only tests related to the changed modules. Faster, requires good impact analysis. - Progressive regression: add new tests for each new feature on top of existing regression suite. How to make it practical: - Automate regression suite (Selenium, Cypress, JUnit) - Prioritize: smoke tests first, then critical path, then full suite - Run in CI/CD on every commit (unit + integration) and nightly (full E2E) Without regression testing, teams unknowingly re-introduce old bugs — known as bug regression. A good automated suite catches these instantly.

Both are quick, focused test types but serve different purposes: Smoke Testing: - Also called "build verification testing" - Purpose: verify the basic, critical functions work after a new build - Scope: BROAD but SHALLOW — covers all major features at surface level - When: immediately after a new build is deployed to test environment - Goal: decide if the build is stable enough for deeper testing - If smoke fails: build is rejected, returned to developers Sanity Testing: - Also called "sanity check" - Purpose: verify a specific bug fix or new feature works correctly - Scope: NARROW but DEEP — focused on one area - When: after a minor change or bug fix, before regression - Goal: confirm the change didn't break anything in that specific area - If sanity fails: the fix didn't work; build goes back Key difference table: | | Smoke | Sanity | | Scope | Full app (shallow) | Specific area (deep) | | When | New build | After bug fix | | Done by | QA or automation | Tester familiar with area | | Documented? | Sometimes | Rarely scripted | Analogy: smoke test = power on a computer and check if the screen lights up; sanity test = check if the broken USB port now works after repair.

The defect life cycle (bug life cycle) tracks the state of a defect from discovery to closure: Stages: 1. New: tester finds a bug, logs it in the tracking tool (JIRA, Bugzilla) 2. Assigned: team lead assigns it to a developer 3. Open: developer acknowledges and starts investigation 4. In Progress / Fixed: developer fixes the bug and marks it ready for retesting 5. Retest: QA retests the specific bug fix 6. Closed: QA confirms the fix works; bug is closed 7. Reopen: if the fix doesn't work, QA reopens it → goes back to Open 8. Deferred: bug is valid but won't be fixed in the current release (low priority / no time) 9. Rejected: developer or PM determines it's not a bug (expected behaviour, duplicate, or cannot reproduce) 10. Duplicate: same bug already logged; closed as duplicate Key states: New → Assigned → Open → Fixed → Retest → Closed → Reopen (if fix fails) → Deferred / Rejected Good defect report includes: - Summary, Steps to reproduce, Expected vs actual result - Environment (OS, browser, version), Severity + Priority, Screenshots/logs Severity (impact on system) vs Priority (urgency to fix) can differ. A typo on homepage: low severity, high priority (visible to everyone).

Both are black-box test design techniques to choose effective test cases without testing every possible input. Equivalence Partitioning (EP): - Divide input data into groups (partitions) where all values in a group behave the same - Test one value from each partition instead of all values - Partitions: valid and invalid Example: Age field accepts 18-60 - Valid partition: 18-60 (test with e.g. 30) - Invalid partition 1: <18 (test with e.g. 10) - Invalid partition 2: >60 (test with e.g. 70) - Invalid partition 3: non-numeric (test with "abc") Boundary Value Analysis (BVA): - Bugs cluster at the edges of partitions - Test the exact boundary values: at, just below, just above - Usually done in combination with EP Example for age 18-60: - Just below lower: 17 - At lower: 18 - Just above lower: 19 - Just below upper: 59 - At upper: 60 - Just above upper: 61 Combined approach: EP tells you WHAT to test, BVA tells you WHERE the boundaries are. Together they give maximum coverage with minimum test cases — critical for large input domains.

TDD: a development practice where you write a failing test BEFORE writing the production code. The Red-Green-Refactor cycle: 1. RED: Write a failing test for a small piece of new functionality. Run it — it must fail (proves the test is valid). 2. GREEN: Write the minimal production code to make the test pass. Don't over-engineer; just make it pass. 3. REFACTOR: Clean up both the production code and test code — remove duplication, improve naming, extract methods. Tests must still pass after refactoring. Repeat for each new feature or behaviour. Benefits: - Forces clear thinking about API/interface before implementation - Tests act as living documentation - High confidence to refactor (tests catch regressions instantly) - Leads to loosely coupled, testable code by design - Prevents over-engineering (you only write code to pass tests) Challenges: - Steep learning curve — requires discipline - UI testing with TDD is harder - Can feel slow initially TDD vs writing tests after: - Tests written after code tend to confirm what the code does, not what it should do - TDD tests define behaviour from the consumer's perspective Most effective for: business logic, algorithms, service layers. Less practical for: exploratory UI features, rapid prototyping.

BDD: an extension of TDD that focuses on behaviour from the user's perspective and uses a shared language (Gherkin) understandable by business stakeholders, QA, and developers. Core idea: describe behaviour in plain language before writing code. Gherkin syntax: Feature: User login Scenario: Successful login Given the user is on the login page When they enter valid credentials Then they should be redirected to the dashboard How it works: 1. Product/QA writes Gherkin scenarios collaboratively with business 2. Developers implement step definitions that map Gherkin steps to test code 3. Tests run automatically — feature files become living documentation Tools: Cucumber (Java/JS), SpecFlow (.NET), Behave (Python) BDD vs TDD: | Aspect | TDD | BDD | | Focus | Implementation units | User/business behaviour | | Language | Technical test code | Natural language (Gherkin) | | Who writes | Developer | Dev + QA + Business | | Scope | Unit level | Feature/scenario level | | Goal | Code correctness | Behaviour correctness | TDD answers: "does this function work correctly?" BDD answers: "does this feature do what the business needs?" Both can coexist: BDD defines high-level scenarios, TDD drives the underlying implementation.

Selenium WebDriver: an open-source browser automation framework that lets you control browsers programmatically via code (Java, Python, JS, C#). Architecture: 1. Test code → calls Selenium API (e.g., driver.findElement(), driver.click()) 2. Selenium client library serializes commands into HTTP requests (W3C WebDriver Protocol, previously JSON Wire Protocol) 3. HTTP requests sent to the browser driver (ChromeDriver, GeckoDriver, etc.) 4. Browser driver communicates with the browser via browser's native automation API 5. Browser executes the command (click, navigate, type) 6. Response travels back through the chain Components: - Selenium Client (language bindings): Java/Python/JS/C# library - WebDriver API: standardized interface for browser commands - Browser Drivers: ChromeDriver, GeckoDriver, EdgeDriver — translate WebDriver commands to browser-specific automation - Browser: Chrome, Firefox, Edge, Safari Key classes in Java: WebDriver driver = new ChromeDriver(); driver.get("https://example.com"); WebElement button = driver.findElement(By.id("submit")); button.click(); driver.quit(); Selenium 4 changes: - W3C WebDriver standard (replaced JSON Wire Protocol) - Native Chrome DevTools Protocol (CDP) support - Relative locators (e.g., toRightOf, above) - Improved Grid architecture Limitations: no built-in reporting, slow E2E tests, requires browser drivers installed.

Page Object Model: a design pattern where each web page (or component) is represented as a class. The class encapsulates locators and actions for that page; test scripts use the page objects instead of direct element references. Without POM: @Test public void loginTest() { driver.findElement(By.id("username")).sendKeys("user@test.com"); driver.findElement(By.id("password")).sendKeys("pass123"); driver.findElement(By.id("loginBtn")).click(); } // If the id "loginBtn" changes → update every test that uses it With POM: public class LoginPage { @FindBy(id = "username") WebElement usernameField; @FindBy(id = "password") WebElement passwordField; @FindBy(id = "loginBtn") WebElement loginButton; public void login(String user, String pass) { usernameField.sendKeys(user); passwordField.sendKeys(pass); loginButton.click(); } } @Test public void loginTest() { LoginPage loginPage = new LoginPage(driver); loginPage.login("user@test.com", "pass123"); } Benefits: - Maintainability: UI change → update only the page class, not every test - Reusability: same page object used across multiple tests - Readability: tests read like a spec, not XPath soup - Separation of concerns: test logic vs page interaction logic Best practice: page object methods return the next page object (fluent API), enabling chaining like: loginPage.login().dashboard().goToSettings()