Toolmingo
Guides25 min read

50 QA Interview Questions (With Answers)

Top software testing and QA interview questions with clear answers — covering testing fundamentals, test design techniques, defect life cycle, API testing, automation, performance testing, and Agile QA.

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:

  1. Bug ID — Unique identifier
  2. Title — Clear, concise description
  3. Environment — OS, browser, version, device
  4. Steps to reproduce — Numbered, precise steps
  5. Expected result — What should happen
  6. Actual result — What actually happened
  7. Severity & Priority
  8. 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:

  1. Create Thread Group: 100 users, ramp-up 60s, 1 loop
  2. Add HTTP Request sampler
  3. Add Summary Report listener
  4. 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 Google 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?

  1. 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.

Keep reading

All Toolmingotools are free & run in your browser

No sign-up, no upload, no watermark. Your files never leave your device.

Browse all tools