QA interviews test your knowledge of testing principles, defect management, test design, automation tools, and Agile processes. This guide covers the 50 most common questions — with clear answers and real examples.
Quick reference
| Topic | Most asked questions |
|---|---|
| Testing fundamentals | types, levels, SDLC vs STLC |
| Test design | equivalence partitioning, boundary value, decision tables |
| Defect management | bug life cycle, severity vs priority |
| Test management | test plan, test case, test coverage |
| API testing | REST testing, Postman, status codes |
| Performance testing | load, stress, soak — JMeter |
| Automation | frameworks, Selenium, Playwright, Cypress |
| Mobile testing | native/hybrid, device farms |
| Agile QA | Scrum ceremonies, shift-left, BDD |
| Metrics | defect density, test coverage, MTTR |
Testing Fundamentals
1. What is software testing and why is it important?
Software testing is the process of evaluating a system or its components to find defects and verify it meets specified requirements.
Why it matters:
| Reason | Impact |
|---|---|
| Finds defects early | Cheaper to fix in development than production |
| Validates requirements | Ensures software does what users expect |
| Builds confidence | Stakeholders trust a well-tested release |
| Reduces risk | Prevents critical failures in production |
| Ensures quality | Performance, security, usability standards |
The cost of fixing a bug increases roughly 10× with each phase: development → testing → staging → production.
2. What are the different types of software testing?
| Type | What It Checks |
|---|---|
| Functional | Does the software do what it's supposed to? |
| Non-functional | Performance, security, usability, reliability |
| Manual | Tester executes tests without automation |
| Automated | Scripts execute tests — repeatable and fast |
| Black-box | Tests behaviour without knowing internal code |
| White-box | Tests internal logic/code paths (unit tests) |
| Grey-box | Partial knowledge of internals |
| Regression | Ensures new changes don't break existing functionality |
| Smoke | Quick sanity check on critical paths after a build |
| Sanity | Narrow, focused check on a specific change |
| Exploratory | Unscripted testing based on tester intuition |
| Acceptance (UAT) | End-users verify the system meets business needs |
3. What are the levels of software testing?
┌─────────────────────────────┐
│ Acceptance Testing (UAT) │ ← Business / user level
├─────────────────────────────┤
│ System Testing │ ← Whole system (E2E)
├─────────────────────────────┤
│ Integration Testing │ ← Component interactions
├─────────────────────────────┤
│ Unit Testing │ ← Individual functions/classes
└─────────────────────────────┘
| Level | Who Tests | Tools |
|---|---|---|
| Unit | Developers | Jest, JUnit, pytest, Vitest |
| Integration | Dev / QA | Supertest, REST Assured |
| System | QA | Selenium, Cypress, Playwright |
| Acceptance | Business / QA | Cucumber, FitNesse, manual |
4. What is the difference between SDLC and STLC?
| Aspect | SDLC (Software Development Life Cycle) | STLC (Software Testing Life Cycle) |
|---|---|---|
| Goal | Develop software | Test software |
| Phases | Planning → Design → Dev → Testing → Deploy | Requirement analysis → Planning → Design → Execution → Closure |
| Owner | Development team | QA/Testing team |
| Output | Working software | Test reports, defect logs |
| Relationship | STLC is a subset of SDLC | Runs in parallel with SDLC |
5. What is verification vs validation?
| Verification | Validation | |
|---|---|---|
| Question | Are we building the product right? | Are we building the right product? |
| Activity | Reviews, walkthroughs, inspections | Actual testing (running the software) |
| Phase | During development | After development |
| Example | Review design doc against requirements | Run user acceptance tests |
6. What is regression testing and when is it performed?
Regression testing re-runs previously passing tests to confirm that new code changes haven't broken existing functionality.
When to run:
- After every bug fix
- After every new feature addition
- After code refactoring
- Before every release
Types:
| Type | Description |
|---|---|
| Full regression | Run the complete test suite |
| Partial/selective | Run tests related to changed modules |
| Progressive | New tests added each iteration |
| Retest-all | Re-execute every test (expensive) |
Best practice: automate regression tests (faster, reliable, repeatable).
Test Design Techniques
7. What is Equivalence Partitioning?
Equivalence Partitioning (EP) divides input data into valid and invalid partitions where each value in a partition is expected to behave the same way.
Example — Age field (valid: 18–60):
| Partition | Values | Expected |
|---|---|---|
| Valid | 18–60 | Accepted |
| Invalid (too low) | < 18 | Rejected |
| Invalid (too high) | > 60 | Rejected |
Test one value per partition instead of testing every possible value.
8. What is Boundary Value Analysis?
Boundary Value Analysis (BVA) tests at the edges of partitions, where bugs are most likely.
For an input range 1–100:
| Boundary | Values to test |
|---|---|
| Lower boundary | 0 (invalid), 1 (valid min), 2 (just above min) |
| Upper boundary | 99 (just below max), 100 (valid max), 101 (invalid) |
BVA and EP are often used together.
9. What is a Decision Table?
A Decision Table maps combinations of input conditions to expected outputs. Used for complex business logic.
Example — Loan approval:
| Condition | T1 | T2 | T3 | T4 |
|---|---|---|---|---|
| Credit score ≥ 700 | Y | Y | N | N |
| Income ≥ $50k | Y | N | Y | N |
| Approve loan | ✓ | ✗ | ✗ | ✗ |
Each column is a test case.
10. What is State Transition Testing?
State Transition Testing is used when a system behaves differently depending on its current state.
Example — ATM PIN:
[Start] → Enter PIN →
Correct → [Logged In]
Wrong (1st) → [1 Attempt Used]
Wrong (2nd) → [2 Attempts Used]
Wrong (3rd) → [Card Blocked]
Test cases cover valid and invalid transitions between all states.
11. What is the difference between smoke testing and sanity testing?
| Aspect | Smoke Testing | Sanity Testing |
|---|---|---|
| Scope | Broad, shallow | Narrow, deep |
| Purpose | Verify build is testable | Verify specific fix/feature works |
| When | After every new build | After a specific change |
| Who | QA or dev | QA |
| If fails | Reject the build | Don't test that module |
| Scripted? | Yes | Often unscripted |
Analogy: Smoke test = "Does the car start?" Sanity test = "Is the new brake pad working?"
Defect Management
12. What is the defect/bug life cycle?
New → Assigned → Open → Fixed → Retest →
Pass → Closed
Fail → Reopened → Fixed → Retest → ...
Also possible:
New → Rejected (not a bug / duplicate)
New → Deferred (postponed)
| Status | Meaning |
|---|---|
| New | Bug reported, not yet reviewed |
| Assigned | Assigned to developer |
| Open | Developer is working on it |
| Fixed | Developer marked as resolved |
| Retest | QA is re-verifying the fix |
| Closed | Bug verified as fixed |
| Reopened | Bug still exists after fix |
| Rejected | Not a defect (works as designed) |
| Deferred | Postponed to a future release |
13. What is the difference between severity and priority?
| Severity | Priority | |
|---|---|---|
| Definition | Impact on system functionality | Order in which it should be fixed |
| Set by | QA / Tester | Product Manager / Business |
| Levels | Critical / High / Medium / Low | P1 / P2 / P3 / P4 |
| Example | High severity, low priority | Low severity, high priority |
Classic combinations:
| Scenario | Severity | Priority |
|---|---|---|
| App crashes on login | Critical | P1 |
| Typo in homepage logo | Low | P1 (brand impact) |
| Minor calculation error in admin report | High | P3 (few users affected) |
| UI alignment slightly off | Low | P4 |
14. What makes a good bug report?
A good bug report contains:
- Bug ID — Unique identifier
- Title — Clear, concise description
- Environment — OS, browser, version, device
- Steps to reproduce — Numbered, precise steps
- Expected result — What should happen
- Actual result — What actually happened
- Severity & Priority
- Attachments — Screenshots, videos, logs
Example title (bad): "Button broken"
Example title (good): "Submit button on checkout page does not respond on Safari 17 when cart has >10 items"
15. What is a test plan? What does it contain?
A test plan is a document that describes the testing scope, approach, resources, and schedule.
Key sections:
| Section | Contents |
|---|---|
| Test scope | What is/isn't being tested |
| Test approach | Manual, automated, types of testing |
| Resources | Team members, roles |
| Schedule | Milestones, timelines |
| Entry/exit criteria | When testing starts/ends |
| Risk & mitigation | What could go wrong |
| Deliverables | Test cases, reports, sign-off |
Test Management
16. What is a test case? What makes a good one?
A test case is a documented set of steps to verify a specific functionality.
Structure:
| Field | Example |
|---|---|
| Test Case ID | TC_LOGIN_001 |
| Title | Verify successful login with valid credentials |
| Preconditions | User has a registered account |
| Test Steps | 1. Go to /login, 2. Enter valid email, 3. Enter valid password, 4. Click Login |
| Expected Result | User is redirected to dashboard with welcome message |
| Actual Result | (filled during execution) |
| Status | Pass / Fail |
Good test case traits: atomic, independent, clear, traceable to a requirement.
17. What is the difference between test case and test scenario?
| Test Case | Test Scenario | |
|---|---|---|
| Detail | Detailed, step-by-step | High-level, what to test |
| Example | "Enter email 'test@mail.com', password 'Pass123', click Login → expect dashboard" | "Verify user can log in" |
| Usage | Execution | Planning |
One test scenario can have multiple test cases (e.g., valid login, invalid password, locked account).
18. What is test coverage and how is it measured?
Test coverage measures how much of the software has been tested.
| Type | Formula / Metric |
|---|---|
| Requirements coverage | % of requirements with test cases |
| Code coverage | % of code lines/branches executed by tests |
| Statement coverage | # statements executed / total statements × 100 |
| Branch coverage | # branches tested / total branches × 100 |
| Functional coverage | % of features tested |
Target: 80%+ code coverage is a common industry standard. 100% is unrealistic and often undesirable.
Tools: Istanbul/nyc (JS), pytest-cov (Python), JaCoCo (Java).
19. What are entry and exit criteria in testing?
Entry criteria — conditions that must be met before testing begins:
- Build deployed to test environment
- Test cases reviewed and approved
- Test environment configured and accessible
- All critical dependencies available
Exit criteria — conditions that signal testing is complete:
- 100% test cases executed
- 95% pass rate (adjust per project)
- All P1/P2 bugs closed
- No open critical/high severity defects
- Test summary report approved
20. What is exploratory testing?
Exploratory testing is simultaneous learning, test design, and execution — without pre-written test scripts. The tester explores the application based on intuition, domain knowledge, and creativity.
When to use:
- New feature with unclear requirements
- Time-boxed testing sessions
- Complement to scripted testing
- Discovering edge cases automated tests miss
Session-Based Test Management (SBTM): Organise exploratory testing in time-boxed sessions (e.g., 90 minutes) with a charter (goal).
API Testing
21. What is API testing and why is it important?
API testing validates that APIs work correctly — testing the business logic layer directly, without the UI.
Advantages over UI testing:
| Advantage | Detail |
|---|---|
| Faster | No rendering, no browser |
| More stable | No flaky UI selectors |
| Earlier feedback | Test before UI is built |
| Better coverage | Test edge cases the UI can't easily trigger |
| Language-independent | Test any language's API |
22. What HTTP methods do you typically test in API testing?
| Method | Purpose | Idempotent? |
|---|---|---|
| GET | Retrieve a resource | Yes |
| POST | Create a resource | No |
| PUT | Replace a resource | Yes |
| PATCH | Partially update a resource | No |
| DELETE | Remove a resource | Yes |
| HEAD | Like GET but no body | Yes |
| OPTIONS | What methods are supported | Yes |
23. What HTTP status codes do you check in API testing?
| Code | Meaning | Test check |
|---|---|---|
| 200 OK | Request succeeded | Default success |
| 201 Created | Resource created | POST success |
| 204 No Content | Success, no body | DELETE success |
| 400 Bad Request | Invalid input | Validation errors |
| 401 Unauthorized | Not authenticated | Missing/invalid token |
| 403 Forbidden | Authenticated but not allowed | Authorisation check |
| 404 Not Found | Resource doesn't exist | Invalid ID |
| 409 Conflict | State conflict | Duplicate creation |
| 422 Unprocessable Entity | Validation failed | Schema errors |
| 429 Too Many Requests | Rate limited | Load testing |
| 500 Internal Server Error | Server crashed | Error scenarios |
24. What do you validate in an API response?
Checklist for every API test:
- Status code — correct for the scenario
- Response time — within SLA (e.g., < 500ms)
- Response body — correct data, correct types
- Schema — response matches expected structure (JSON Schema)
- Headers — Content-Type, Cache-Control, CORS
- Error messages — descriptive and not leaking internals
- Authentication — 401/403 on unauthorised requests
- Pagination — correct metadata (total, page, hasNext)
25. How do you test API authentication?
| Auth Type | Tests |
|---|---|
| No auth | Request without token → 401 |
| Expired token | Request with expired JWT → 401 |
| Invalid token | Random string as bearer → 401 |
| Wrong role | Valid token, insufficient permissions → 403 |
| Valid auth | Correct token → 200 |
| SQL injection in token | Malformed token → 401 (not 500) |
Tools: Postman, REST Assured, pytest + requests, Insomnia.
Performance Testing
26. What is performance testing and what are its types?
Performance testing validates how a system behaves under various load conditions.
| Type | Goal | Scenario |
|---|---|---|
| Load testing | Behaviour under expected load | 1,000 concurrent users |
| Stress testing | Find breaking point | Keep increasing load until failure |
| Soak/Endurance | Stability over time | 72-hour run at normal load |
| Spike testing | Sudden load increase | Flash sale traffic burst |
| Volume testing | Large amounts of data | 10 million records in DB |
| Scalability testing | How well it scales | Add servers, does throughput increase? |
| Capacity testing | Maximum supported load | Find the ceiling before degradation |
27. What is the difference between response time, throughput, and latency?
| Metric | Definition | Target |
|---|---|---|
| Response time | Time from request to full response | < 2s (Google's standard) |
| Latency | Time from request to first byte | < 200ms for APIs |
| Throughput | Requests handled per second (RPS/TPS) | Depends on system |
| Error rate | % of failed requests | < 1% under load |
| Concurrent users | Simultaneous active users | Depends on system |
28. What is JMeter and how do you use it for performance testing?
Apache JMeter is an open-source performance testing tool.
Key JMeter concepts:
| Component | Purpose |
|---|---|
| Thread Group | Simulates virtual users |
| Sampler | Sends requests (HTTP, JDBC, FTP, etc.) |
| Config Element | HTTP defaults, CSV data sets |
| Listener | Results (Summary Report, Graph) |
| Timer | Delays between requests |
| Assertion | Validate responses |
| Pre/Post Processor | Extract data (JSON/Regex Extractor) |
Basic load test setup:
- Create Thread Group: 100 users, ramp-up 60s, 1 loop
- Add HTTP Request sampler
- Add Summary Report listener
- Run and check response times, error rates
Automation Testing
29. What is a test automation framework?
A test automation framework is a set of guidelines, tools, and libraries that standardise test development.
| Framework Type | Description | Best For |
|---|---|---|
| Linear/Record-Playback | Scripts recorded sequentially | Quick demos |
| Modular | Test scripts divided into modules | Medium projects |
| Data-Driven | Test data separated from scripts | Testing many input combinations |
| Keyword-Driven | Test steps described as keywords | Non-technical testers |
| Hybrid | Combination of above | Large projects |
| BDD | Gherkin syntax (Given/When/Then) | Cross-team collaboration |
| Page Object Model (POM) | UI interactions in separate classes | Web UI automation |
30. What is the Page Object Model (POM)?
Page Object Model is a design pattern where each web page has a corresponding class that encapsulates its elements and interactions.
# page_objects/login_page.py
class LoginPage:
def __init__(self, driver):
self.driver = driver
self.email_input = (By.ID, "email")
self.password_input = (By.ID, "password")
self.submit_btn = (By.CSS_SELECTOR, "button[type='submit']")
def login(self, email, password):
self.driver.find_element(*self.email_input).send_keys(email)
self.driver.find_element(*self.password_input).send_keys(password)
self.driver.find_element(*self.submit_btn).click()
# test_login.py
def test_valid_login(driver):
page = LoginPage(driver)
page.login("user@test.com", "password123")
assert "dashboard" in driver.current_url
Benefits: Maintainable (one place to update), readable, reusable.
31. What are the differences between Selenium, Cypress, and Playwright?
| Feature | Selenium | Cypress | Playwright |
|---|---|---|---|
| Language | Java/Python/C#/JS/Ruby | JavaScript/TypeScript | JS/TS/Python/Java/C# |
| Architecture | WebDriver over HTTP | Runs inside browser | CDP + WebSocket |
| Speed | Medium | Fast | Fast |
| Cross-browser | Chrome/Firefox/Safari/Edge | Chrome/Firefox/Edge | Chrome/Firefox/Safari/Edge |
| Auto-wait | Manual waits needed | Auto-wait built-in | Auto-wait built-in |
| iFrames | Supported | Limited | Supported |
| Network control | Via proxy | Built-in | Built-in |
| Parallel | Selenium Grid | Requires setup | Built-in |
| Best for | Large teams, multi-language | JS teams, component testing | Modern apps, multi-browser |
32. What are common challenges in test automation?
| Challenge | Solution |
|---|---|
| Flaky tests | Add explicit waits, fix test isolation, retry logic |
| Slow test suite | Parallelise, run smoke only on PR, full suite nightly |
| Brittle locators | Use stable attributes (data-testid), avoid CSS that changes |
| Test data management | Use factories/fixtures, clean up after each test |
| Maintenance overhead | Use POM, modular design |
| Environment differences | Use containers (Docker), consistent CI |
| Hard to assert UI | Visual regression tools (Percy, Playwright snapshots) |
Mobile Testing
33. What are the types of mobile applications?
| Type | Description | Testing Tools |
|---|---|---|
| Native | Built for specific OS (Swift/Kotlin) | XCUITest, Espresso, Appium |
| Hybrid | Web inside native wrapper | Appium, WebdriverIO |
| Mobile Web | Browser-based, responsive | Selenium, Cypress, BrowserStack |
| Progressive Web App (PWA) | Web app with native features | Lighthouse, browser devtools |
34. What is Appium?
Appium is an open-source mobile automation framework that tests native, hybrid, and mobile web apps on iOS and Android.
Key concepts:
| Concept | Detail |
|---|---|
| Client-server architecture | Client sends commands, Appium server translates to platform |
| Desired Capabilities | JSON config specifying device, platform, app |
| UIAutomator2 (Android) | Appium's Android driver |
| XCUITest (iOS) | Appium's iOS driver |
| Cross-platform | Same API for Android and iOS |
What to test on mobile:
- Touch gestures (swipe, pinch, tap)
- Device rotation (portrait/landscape)
- Push notifications
- Deep links
- Battery, memory usage
- Offline mode
- Different screen sizes
35. What is a device farm and why use it?
A device farm provides cloud access to real physical devices for mobile testing.
| Tool | Provider | Key Feature |
|---|---|---|
| BrowserStack | Commercial | 3000+ real devices |
| Sauce Labs | Commercial | Parallel execution |
| AWS Device Farm | AWS | Integration with CI/CD |
| Firebase Test Lab | Free tier, Android-focused |
Why use real devices vs emulators:
- Catch device-specific bugs
- Accurate performance metrics
- Test sensors (GPS, camera, NFC)
- Real carrier network testing
Agile QA
36. How does QA work in an Agile/Scrum team?
In Agile, QA is continuous — not a phase at the end.
QA activities per Scrum event:
| Event | QA Activity |
|---|---|
| Sprint Planning | Estimate testing effort, review acceptance criteria |
| Sprint | Write test cases, automate, find bugs daily |
| Daily Standup | Share test progress, blockers |
| Sprint Review | Demo tested features, show test results |
| Retrospective | Discuss quality issues, improve processes |
Key principle: QA is everyone's responsibility, not just the QA team's.
37. What is shift-left testing?
Shift-left testing moves testing activities earlier in the SDLC — catching bugs sooner when they're cheaper to fix.
Traditional: Develop → Develop → Develop → [TEST]
Shift-Left: [TEST] Develop [TEST] Develop [TEST] Deploy
Shift-left practices:
- Review requirements before development
- TDD (Test-Driven Development)
- Unit and integration tests written by developers
- Static code analysis in CI/CD
- Early performance testing
- Security testing from day one (DevSecOps)
38. What is BDD (Behaviour-Driven Development)?
BDD bridges the gap between business and technical teams using Gherkin syntax (Given/When/Then) for test scenarios.
Feature: User Login
Scenario: Successful login with valid credentials
Given the user is on the login page
When they enter email "user@test.com" and password "Pass123"
And they click the "Login" button
Then they should be redirected to the dashboard
And a welcome message should be displayed
Scenario: Login fails with wrong password
Given the user is on the login page
When they enter email "user@test.com" and password "wrongpass"
And they click the "Login" button
Then they should see the error "Invalid email or password"
Tools: Cucumber (Java), Behave (Python), SpecFlow (.NET), Cypress + Cucumber.
39. What is the test pyramid?
The test pyramid describes the ideal distribution of tests:
/\
/ \
/ E2E \ ← Few, slow, expensive
/────────\
/Integration\ ← Medium
/────────────\
/ Unit Tests \ ← Many, fast, cheap
/────────────────\
| Level | Count | Speed | Cost |
|---|---|---|---|
| Unit | ~70% | Milliseconds | Low |
| Integration | ~20% | Seconds | Medium |
| E2E/UI | ~10% | Minutes | High |
Anti-pattern: Ice cream cone (lots of E2E, few unit tests) — slow, expensive, brittle.
40. What is TDD vs BDD vs ATDD?
| TDD | BDD | ATDD | |
|---|---|---|---|
| Full name | Test-Driven Development | Behaviour-Driven Development | Acceptance Test-Driven Development |
| Written by | Developers | Dev + QA + Business | Dev + QA + Business |
| Focus | Code correctness | System behaviour | Acceptance criteria |
| Language | Code | Gherkin (Given/When/Then) | Acceptance criteria |
| Tools | JUnit, Jest, pytest | Cucumber, Behave | FitNesse, SpecFlow |
Security Testing
41. What is the difference between penetration testing and vulnerability scanning?
| Vulnerability Scanning | Penetration Testing | |
|---|---|---|
| Type | Automated | Manual + automated |
| Depth | Identifies vulnerabilities | Exploits vulnerabilities |
| Output | List of CVEs / issues | Proof of exploit, impact |
| Duration | Minutes to hours | Days to weeks |
| Goal | Discover known vulns | Simulate real attack |
| Tools | Nessus, OpenVAS, Qualys | Burp Suite, Metasploit |
42. What are the OWASP Top 10?
OWASP Top 10 (2021) — most critical web application security risks:
| Rank | Risk | Example |
|---|---|---|
| A01 | Broken Access Control | Accessing admin page as regular user |
| A02 | Cryptographic Failures | Storing passwords in plain text |
| A03 | Injection | SQL injection, XSS |
| A04 | Insecure Design | Missing rate limiting on login |
| A05 | Security Misconfiguration | Default passwords, open S3 buckets |
| A06 | Vulnerable Components | Using library with known CVE |
| A07 | Auth Failures | Weak session tokens, no MFA |
| A08 | Software/Data Integrity | Insecure CI/CD, unsigned packages |
| A09 | Logging Failures | No audit logs for admin actions |
| A10 | SSRF | Server fetching attacker-controlled URL |
QA should include basic security checks: SQL injection, XSS, authentication bypass.
QA Metrics
43. What are the most important QA metrics?
| Metric | Formula | Good sign |
|---|---|---|
| Defect density | Bugs / KLOC (1000 lines of code) | < 1 bug/KLOC |
| Test coverage | Tests passed / total test cases × 100 | > 90% |
| Defect detection efficiency | Bugs found in testing / total bugs × 100 | > 80% |
| Escaped defects | Bugs found in production | → 0 |
| Test execution rate | Tests run / tests planned × 100 | 100% |
| Pass rate | Tests passed / tests run × 100 | > 95% |
| MTTR | Mean time to repair (fix bugs) | Shorter |
| Defect removal efficiency (DRE) | Defects removed before release / total defects × 100 | > 99% |
44. What is MTTR vs MTBF?
| Metric | Full Name | Meaning |
|---|---|---|
| MTTR | Mean Time To Repair | Average time to fix an incident |
| MTBF | Mean Time Between Failures | Average time between failures |
| MTTF | Mean Time To Failure | Average time before first failure |
Goal: High MTBF + Low MTTR = reliable, quickly-recovered system.
Advanced Topics
45. What is usability testing?
Usability testing evaluates how easy and intuitive a product is to use — with real users performing real tasks.
Methods:
| Method | Description |
|---|---|
| Moderated | Facilitator guides user through tasks |
| Unmoderated | User tests alone (recorded) |
| Think-aloud | User verbalises thoughts while testing |
| A/B testing | Compare two versions |
| Card sorting | Users organise content into categories |
| Eye tracking | Track where users look |
Tools: UserTesting, Hotjar, Lookback, maze.
46. What is compatibility testing?
Compatibility testing verifies software works correctly across different environments.
| Type | What to Test |
|---|---|
| Browser | Chrome, Firefox, Safari, Edge, Opera |
| OS | Windows, macOS, Linux, iOS, Android |
| Device | Desktop, tablet, mobile, TV |
| Screen resolution | 1920×1080, 1366×768, 360×800 |
| Network | 4G, 3G, WiFi, offline |
| Database | MySQL, PostgreSQL, Oracle |
Tools: BrowserStack, CrossBrowserTesting, LambdaTest.
47. What is A/B testing vs multivariate testing?
| A/B Testing | Multivariate Testing | |
|---|---|---|
| Variables | 1 element changed | Multiple elements changed |
| Variants | A (control) vs B | All combinations |
| Traffic needed | Less | More |
| Complexity | Simple | Complex |
| Example | Button colour: red vs blue | Button colour + text + size |
Tools: Google Optimize (sunset), Optimizely, LaunchDarkly.
48. What is continuous testing in CI/CD?
Continuous testing means running tests automatically at every stage of the CI/CD pipeline.
Code push
→ Unit tests (< 1 min)
→ Integration tests (< 5 min)
→ Build artifact
→ E2E smoke tests (< 10 min)
→ Deploy to staging
→ Full regression (scheduled nightly)
→ Deploy to production
→ Post-deploy smoke
Key practices:
- Fast feedback: unit tests first
- Fail fast: break the build on test failure
- Test in parallel
- Separate nightly regression from PR checks
- Slack/email alerts on failure
49. What is the difference between functional and non-functional testing?
| Functional Testing | Non-Functional Testing | |
|---|---|---|
| What | Does it work? | How well does it work? |
| Examples | Login works, checkout completes | Page loads in <2s, supports 10k users |
| Types | Unit, integration, system, UAT | Performance, security, usability, reliability |
| Measures | Pass/Fail | Numbers (response time, throughput) |
50. How would you design a test strategy for a new e-commerce feature (e.g., cart)?
Scope: Shopping cart — add, remove, update quantity, apply coupon, checkout.
Test types:
| Type | What to test |
|---|---|
| Functional | Add item → cart count updates; Remove → item gone; Quantity update → total recalculated |
| Boundary | 0 items, max items (e.g., 999), decimal quantity |
| Negative | Invalid coupon, out-of-stock item, network failure during add |
| API | POST /cart, DELETE /cart/{id}, PATCH /cart/{id} — status codes, schema, auth |
| Performance | 1,000 users adding simultaneously — response time < 500ms |
| Security | XSS in product name, price manipulation via API |
| Usability | Easy to find cart, clear error messages, mobile-friendly |
| Regression | Existing checkout flow unaffected |
Common mistakes
| Mistake | Better approach |
|---|---|
| Testing only happy paths | Always test negative and edge cases |
| Writing tests after development | Shift-left: write tests with or before code |
| Not updating tests when code changes | Keep tests in sync — stale tests give false confidence |
| Over-relying on automation | Manual exploratory testing finds bugs automation misses |
| Ignoring non-functional testing | Performance and security matter as much as features |
| Poor bug reports | Always include steps to reproduce, expected vs actual |
| Testing in isolation | Test integrations between components |
| Skipping regression | New features can break existing functionality |
QA vs related roles
| Role | Focus |
|---|---|
| QA Engineer | Test strategy, test design, defect management |
| SDET (Software Dev Engineer in Test) | Automation frameworks, test infrastructure |
| QA Analyst | Manual testing, requirements analysis, bug reporting |
| Performance Engineer | Load/stress testing, performance optimisation |
| Security Tester / Penetration Tester | Security vulnerabilities, ethical hacking |
| DevOps Engineer | CI/CD pipelines (often includes test automation) |
FAQ
Q: Should QA know how to code?
It depends on the role. Manual QA doesn't require coding. SDET / automation QA roles require proficiency in at least one language (Python, Java, JavaScript). Knowing coding fundamentals helps any QA understand the system better and communicate with developers.
Q: What's the difference between QA and QC?
Quality Assurance (QA) is process-oriented — preventing defects by improving processes (like code reviews, test planning). Quality Control (QC) is product-oriented — finding defects through testing. QA is proactive; QC is reactive.
Q: How many test cases should I write per requirement?
There's no fixed number. Cover: happy path, alternative flows, error cases, boundary values. A complex requirement might need 10+ test cases; a simple one might need 2–3.
Q: What is the best automation framework for beginners?
For web: Playwright or Cypress (JS/TS, great DX, auto-wait). For Python projects: pytest + Playwright or pytest + Selenium. Start with one framework and master it before learning others.
Q: How do you handle flaky tests?
- Identify the root cause (timing, shared state, network, data). 2. Add proper waits (not
sleep). 3. Fix test isolation (each test owns its data). 4. Quarantine persistently flaky tests while fixing. 5. Monitor flakiness over time.
Q: What certifications are useful for QA?
ISTQB Foundation Level is the most widely recognised. Beyond that: Certified Selenium Professional, AWS Certified DevOps (for CI/CD), CSTE (Certified Software Test Engineer), or tool-specific certifications from BrowserStack/Sauce Labs.