Launch offer
Business website $150 USD Custom plugin $200 USD Ready in 5 days
Get a quote
malekimtiyajmca@gmail.com
QA Testing

QA Testing Complete Tutorial (112 Topics with Manual, Automation & Final Project)

Complete QA testing tutorial covering STLC, test design, web/API/mobile testing, Selenium/Playwright automation, tools, interview prep, and a final web application QA project.

August 21, 2026 By malekimtiyajmca@gmail.com 18 min read

This complete QA Testing tutorial covers 112 topics — from STLC and test design to web/API/mobile testing, security and performance basics, Selenium/Playwright automation, and a final web application QA project.

Course roadmap

1. Introduction to Software Testing

Software testing finds defects early, reduces risk, and builds confidence that software meets requirements. This series covers manual and automation testing, APIs, performance, security basics, tools, and a complete QA project.

  1. Learn testing fundamentals and STLC.
  2. Practice test cases, bugs, and execution.
  3. Automate critical flows and finish the final project.

Learning path

SDLC/STLC + test design
Test types + bug lifecycle
Web/mobile/API/DB testing
Tools (Jira, Postman, Selenium…)
Automation frameworks
Final web app QA project

2. What is Software Testing?

Testing is not only “finding bugs” — it provides information about quality, risk, and readiness for release.

Testing goals

Verify requirements
Find defects early
Reduce release risk
Improve confidence
Support better decisions

3. QA vs QC vs Testing

QA is process-focused prevention; QC is product-focused detection; Testing is a QC activity that executes checks.

Quick compare

QA → prevent defects (process)
QC → detect defects (product)
Testing → execute checks / find issues

4. Software Development Life Cycle (SDLC)

Common models include Waterfall, Agile/Scrum, and hybrid. Earlier testing involvement reduces cost of defects.

SDLC phases (typical)

Requirements → Design → Build → Test → Deploy → Maintain
Agile: continuous testing each sprint

5. Software Testing Life Cycle (STLC)

STLC organizes testing work: plan, design, environment, execute, report, and close.

STLC phases

Requirement analysis
Test planning
Test case design
Environment setup
Test execution
Cycle closure

6. Types of Software Testing

Choose types based on risk — not every project needs every technique at the same depth.

Type map

By method: Manual / Automation
By knowledge: Black / White / Grey
By level: Unit / Integration / System / UAT
By quality: Functional / Non-functional

7. Manual Testing

Manual testing remains essential for usability, exploratory testing, and early feature validation.

Manual strengths

Fast feedback on new UI
Exploratory insight
Usability judgment
Good when UI is unstable

8. Automation Testing

Automate what is repetitive and stable; keep exploratory/manual for changing or judgment-heavy areas.

Automate when

Regression suites
Smoke packs
API contracts
Data-heavy checks
NOT every one-off UI experiment

9. Functional Testing

Functional tests ask: does the system do what it should for valid and invalid inputs?

Functional focus

Requirements coverage
Business rules
Input/output behavior
Error handling

10. Non-Functional Testing

Non-functional quality often decides production success even when features “work”.

NFT examples

Performance
Security
Usability
Compatibility
Reliability

11. Black Box Testing

Ideal for validating requirements and user behavior independently of implementation.

Black box techniques

BVA
Equivalence partitioning
Decision tables
State transition
Error guessing

12. White Box Testing

Common in unit/integration testing by developers; QA may review coverage and risk areas.

White box focus

Statement/branch coverage
Path testing
Loop testing
Internal error handling

13. Grey Box Testing

Useful for integration, API, and security-informed tests where architecture context helps.

Grey box tip

Know APIs/DB schema lightly
Still validate from user/API contracts
Target risky integrations

14. Test Case

Good test cases are unambiguous, atomic where practical, and easy for others to execute.

Test case fields

ID, Title, Preconditions
Steps
Test data
Expected result
Priority / type

15. Test Scenario

Scenarios help coverage brainstorming; cases add executable detail.

Scenario example

Scenario: User can reset password via email link
Cases: valid token, expired token, reused token...

16. Test Condition

Conditions are the “things that can be verified”; cases cover them with steps.

Condition idea

Requirement: discount max 20%
Conditions: 0%, 20%, 21% rejected, missing coupon...

17. Test Data

Poor test data hides bugs. Manage privacy for production-like data.

Data types

Valid / invalid
Boundary
Blank / null
Duplicate
Role-based datasets

18. Test Plan

A test plan aligns stakeholders on what will/won’t be tested and how risk is handled.

Plan contents

Scope / out of scope
Strategy & types
Environment
Roles
Schedule
Entry/exit criteria
Risks

19. Test Strategy

Strategy is broader than a single plan — tooling standards, environments, automation policy.

Strategy themes

Test levels policy
Automation guidelines
Environments
Defect process
Metrics

20. Test Execution

Execute in priority order; blockers first; keep evidence (screenshots/logs).

Execution tips

Smoke first
Priority order
Log defects ASAP
Retest fixes
Update status in tool

21. Test Results

Results should help decide go/no-go — not only show percentages.

Result report

Executed vs planned
Pass/fail/blocked
Open defects by severity
Risks & recommendations

22. Bug / Defect / Issue

In practice teams say “bug”; formally a defect is a deviation from expected behavior/requirements.

Terms

Error → human mistake
Defect/bug → in product
Failure → observed incorrect behavior
Issue → tracked work item

23. Bug Life Cycle

Common states: New → Assigned → Open → Fixed → Retest → Verified → Closed (or Reopened/Rejected).

Typical states

New
Assigned
In Progress
Fixed
Retest
Verified / Closed
Reopened / Rejected / Deferred

24. Severity vs Priority

A cosmetic bug can be high priority before a marketing launch; a severe bug in a rare path may be lower priority.

Examples

High sev / high pri: payment broken
High sev / low pri: crash in rare admin tool
Low sev / high pri: logo wrong on homepage launch day

25. Bug Reporting

Great reports include environment, steps, expected vs actual, data, and attachments.

Bug report template

Title (clear + specific)
Environment / build
Preconditions
Steps
Expected vs Actual
Severity/Priority
Attachments (shot/video/logs)

26. Bug Tracking Tools

Use fields consistently so metrics and triage stay meaningful.

Tool habits

One workflow for team
Required fields
Link to stories/cases
Avoid duplicate filing

27. Smoke Testing

If smoke fails, stop — don’t waste cycle time on a broken build.

Smoke pack idea

App launches
Login works
Core create/view flow
Critical payment/nav path

28. Sanity Testing

Sanity is narrower than smoke — verify a specific area is “sane” enough to continue.

Sanity vs smoke

Smoke → broad critical paths on new build
Sanity → narrow check after small fix

29. Regression Testing

Prioritize regression by risk; automate stable regression candidates.

Regression tip

Risk-based selection
Automate stable flows
Include integrations
Run before release

30. Retesting

Retesting is confirmation of a fix; regression checks for collateral damage.

Retest rule

Same steps + data that failed
Mark verified only if expected result passes
Then consider nearby regression

31. Integration Testing

Catch contract mismatches, data mapping errors, and timing issues between components.

Integration focus

API contracts
DB + service
Third-party callbacks
Message queues

32. System Testing

System testing is end-to-end at product level before UAT.

System testing includes

Functional E2E
Key NFT checks
Business workflows
Environment close to prod

33. Unit Testing

QA benefits from strong unit tests: fewer trivial bugs reach system test.

Unit testing note

Fast + isolated
Mocks for dependencies
High volume in CI
Supports refactoring

34. Acceptance Testing

May be formal against contracts/AC; often overlaps with UAT in Agile.

Acceptance idea

Given / When / Then criteria
Business sign-off
Ready for release decision

35. User Acceptance Testing (UAT)

UAT focuses on business fitness, not finding every technical edge case.

UAT tips

Real user roles
Production-like data
Business scenarios
Sign-off checklist

36. Exploratory Testing

Exploratory testing finds surprising bugs automation misses — document notes/timeboxes.

Session idea

Charter: Explore checkout with coupon edge cases (60m)
Notes + bugs + follow-ups

37. Ad-Hoc Testing

Ad-hoc can find issues quickly but is weak for coverage proof; prefer structured exploratory sessions.

Use carefully

Good for quick gut-checks
Weak for audit/coverage
Convert finds into formal cases

38. End-to-End Testing

Keep E2E suites lean — they are powerful but slower and more brittle.

E2E example

Register → verify email → login → purchase → invoice email → admin order visible

39. Positive Testing

Positive tests prove happy paths; pair with negative tests for resilience.

Positive example

Valid login credentials → dashboard loads

40. Negative Testing

Negative tests protect data integrity and UX under misuse.

Negative examples

Wrong password
SQL-like input in fields
Submit blank required fields
Expired session actions

41. Boundary Value Analysis

For range 1–100, test 0,1,2 and 99,100,101 (as applicable).

BVA example

Field: age 18–60
Test: 17, 18, 19, 59, 60, 61

42. Equivalence Partitioning

EP reduces cases while keeping coverage of behavior classes.

EP example

Valid ages 18–60 → one value (e.g. 30)
Invalid <18 → one value
Invalid >60 → one value

43. Decision Table Testing

Decision tables shine when multiple combinations drive different outcomes.

Decision table tip

List conditions
List actions
Fill True/False combinations
Derive cases from columns

44. State Transition Testing

Great for orders, tickets, workflows, and login lockout states.

State example

Order: New → Paid → Shipped → Delivered
Illegal: Delivered → New without admin override

45. Error Guessing

Complement structured techniques — don’t rely on guessing alone.

Guess targets

Empty uploads
Copy-paste whitespace
Double submit
Timezone edges
Currency rounding

46. Requirement Analysis for QA

Ask clarifying questions early; untestable requirements become untestable products.

Review checklist

Clear acceptance criteria?
Ambiguous words (fast, user-friendly)?
Missing error cases?
Dependencies noted?

47. Requirement Traceability Matrix (RTM)

RTM helps answer: are we testing everything important, and what’s still open?

RTM columns

Req ID
Description
Test scenario/case IDs
Status
Defect IDs

48. Test Case Design

Balance depth vs time; cover critical paths first.

Design tips

One primary objective per case
Reusable steps
Independent where possible
Trace to requirements

49. Test Case Review

Reviews catch missing negatives, unclear steps, and duplicated effort.

Review focus

Ambiguous steps?
Missing expected results?
Data specified?
Coverage gaps?

50. Test Execution and Reporting

Daily/iteration reports should highlight risk, blockers, and trends — not only counts.

Report metrics

% executed
Pass rate
Open sev-1/2 bugs
Blocked tests
Risk notes

51. Web Application Testing

Include session handling, forms, uploads, and role-based access.

Web QA checklist

Auth flows
Forms/validation
Navigation
Browser matrix
API + UI consistency

52. Website UI Testing

Check hover/focus/disabled states and broken UI on real viewports.

UI checks

Spacing/alignment
Truncation
Empty states
Error states
Brand consistency

53. Responsive Testing

Test orientation changes and touch targets on real devices when possible.

Responsive tip

Key breakpoints
No horizontal scroll
Readable text
Tap targets
Menus/drawers

54. Cross-Browser Testing

Prioritize browsers by analytics; watch CSS and JS API differences.

Browser matrix tip

Based on traffic analytics
Latest + N-1 versions
Safari on macOS/iOS critical for many markets

55. Mobile Testing

Include network switches, backgrounding, and permissions flows.

Mobile risks

Permissions
Poor network
Interrupts (calls)
OS version fragmentation
Store guidelines

56. Android Testing

Watch runtime permissions, battery optimizations, and file/camera intents.

Android focus

API level matrix
Back stack behavior
Permissions
Notifications
Play build variants

57. iOS Testing

Test on multiple iPhone sizes; verify background refresh and Keychain/auth flows.

iOS focus

Permission strings
Safe areas / notch
Face ID/Touch ID flows
TestFlight builds

58. API Testing

Validate status codes, payloads, auth, and error shapes.

API test axes

Status codes
Schema/body
Headers
Auth
Idempotency / errors

59. REST API Testing

Check resource URLs, correct verbs, pagination, and filtering behavior.

REST checks

GET list/detail
POST create
PUT/PATCH update
DELETE remove
Pagination & filters

60. GET, POST, PUT and DELETE Testing

Ensure GET is safe, POST creates, PUT/PATCH updates, DELETE removes (as designed).

Method expectations

GET → read, no side effects
POST → create
PUT/PATCH → update
DELETE → remove / soft-delete

61. API Authentication Testing

Confirm 401/403 behavior and that protected routes reject anonymous access.

Auth cases

No token
Invalid token
Expired token
Valid token wrong role
Token refresh flows

62. JSON and XML Testing

Schema checks catch contract drift before UI breaks.

Payload checks

Required fields present
Correct types
Null handling
Unexpected fields policy
Encoding/charset

63. Postman for API Testing

Organize folders by resource; assert status and JSON paths; run collection runners/Newman in CI.

Postman tip

Environments for QA/UAT
Collection variables
pm.test assertions
Share collections with team

64. Database Testing

Compare UI/API results with DB state; check cascading deletes and transactions.

DB QA focus

Constraints/keys
CRUD accuracy
Migrations
Data migration jobs
Sensitive data handling

65. SQL for QA

QA doesn’t need DBA depth — but strong SELECT skills unlock faster root-cause checks.

Useful SQL

SELECT id, email, created_at
FROM users
WHERE email = 'qa@example.com';
ORDER BY id DESC
LIMIT 5;

66. Data Validation Testing

Validate trimming, encoding, timezone/currency formats, and rounding rules.

Validation angles

Input validation
Storage format
Display format
Round-trip integrity

67. CRUD Testing

Confirm deleted entities cannot be read (or soft-delete rules), and updates are idempotent where required.

CRUD matrix

Create → appears in list/detail/DB
Read → correct fields
Update → persists
Delete → removed / gated

68. Performance Testing

Define SLAs first (response time, error rate, throughput) then test against them.

Perf metrics

Response time
Throughput
Error %
CPU/memory
Apdex / percentiles (p95)

69. Load Testing

Ramp users realistically; watch degradation curves and bottlenecks.

Load tip

Baseline first
Ramp to target load
Hold soak window
Compare to SLA

70. Stress Testing

Stress reveals failure modes — also verify graceful degradation and recovery after load drops.

Stress focus

Breaking point
Error behavior
Recovery time
Data consistency after stress

71. Volume Testing

Large datasets expose slow queries, timeouts, and UI pagination issues.

Volume tip

Seed large DB
Test search/filter/export
Watch query times + timeouts

72. Scalability Testing

Validate horizontal/vertical scaling assumptions with measured results.

Scalability question

If we add instances/resources, does throughput rise near-linearly?
Where are bottlenecks (DB, locks, external APIs)?

73. Security Testing

Security testing should be authorized and scoped. Cover authn/z, sessions, injection, and sensitive data exposure.

Security basics for QA

Auth & session
Access control
Input injection
Sensitive data in logs/UI
HTTPS / cookie flags

74. Authentication Testing

Confirm error messages don’t leak whether a user exists (as per security design).

Auth cases

Valid login
Invalid password
Locked account
Reset token expiry
Logout invalidates session

75. Authorization Testing

Test horizontal/vertical privilege escalation attempts via UI and API.

AuthZ tip

Role matrix
Direct URL/API access
IDOR checks (other user IDs)
Admin-only actions blocked

76. Session Testing

Check cookie flags (Secure, HttpOnly, SameSite) where applicable.

Session checks

Idle timeout
Remember-me behavior
Logout clears session
Concurrent login rules

77. SQL Injection Testing

Prefer verifying parameterized queries / ORM usage and that classic payloads do not change behavior or expose errors.

QA approach (authorized)

Submit suspicious inputs in forms/API
Expect safe rejection / no data leak
Confirm no raw DB errors in UI
Report responsibly

78. XSS Testing

Test reflected/stored XSS surfaces: comments, profiles, markdown fields, admin panels.

XSS QA tip

Enter script-like text
Confirm rendered as text not executed
Check HTML contexts (attr/js)
Use staging only

79. Usability Testing

Observe users; measure task success/time; avoid leading them.

Usability measures

Task success rate
Time on task
Error rate
Satisfaction notes

80. Accessibility Testing

Use axe/Lighthouse plus manual keyboard/screen-reader checks for critical flows.

A11y checklist

Keyboard only navigation
Visible focus
Alt text
Form labels
Contrast
ARIA where needed

81. Compatibility Testing

Build a risk-based matrix from analytics and contracts.

Compatibility matrix

OS × Browser × Device
Prioritize top traffic combos
Retest on upgrades

82. Installation Testing

Include permissions, disk space failures, and upgrade installers where relevant.

Install checks

Fresh install
Uninstall cleanup
Cancel mid-install
Shortcut/services created

83. Upgrade and Downgrade Testing

Never lose user data; verify rollback plans for failed upgrades.

Upgrade tip

N → N+1 upgrade
Data preserved
Feature flags behave
Rollback path tested

84. Configuration Testing

Useful for products with many toggles, locales, or deployment options.

Config ideas

Feature flags on/off
Env configs
Optional modules
Supported OS locales

85. Localization Testing

Check truncation, RTL layouts, and correct date/number/currency formats.

L10n checks

Translations complete
No overlapping text
Date/currency formats
RTL if required

86. Internationalization Testing

i18n testing checks Unicode, locale switching, and that strings are externalized.

i18n focus

Unicode input/storage
Locale switch
No hard-coded strings
Timezone handling

87. CI/CD Testing

Run unit/API/smoke on PRs; heavier suites on schedule/main; gate deploys on quality signals.

Pipeline layers

PR: lint + unit + critical API
Nightly: broader UI regression
Pre-prod: smoke + security scans

88. Git for QA

QA automation lives in repos — know clone, branch, PR, and conflict basics.

Git basics

git clone <repo>
git checkout -b qa/login-tests
git status
git commit -m "Add login smoke tests"
git push -u origin HEAD

89. Jira for Bug Tracking

Use issue types, workflows, and links (blocks/relates) consistently.

Jira habits

Clear summaries
Required fields
Link to story/case
Components + versions
Boards for sprint visibility

90. TestRail for Test Management

TMS tools improve coverage visibility and execution tracking across builds.

TestRail flow

Suites/cases
Test run for build
Execute & comment
Reports for stakeholders

91. Selenium Introduction

Selenium WebDriver drives real browsers — foundation for many UI frameworks.

Selenium pieces

WebDriver
Bindings (Java/Python/JS…)
Grid (optional scale)
IDE (record/playback limited use)

92. Selenium WebDriver

Create a driver, navigate, find elements, interact, assert, quit.

WebDriver flow

Start driver
driver.get(url)
find element → click/type
assert outcome
quit driver

93. Selenium Locators

Prefer stable locators (test IDs) over brittle absolute XPaths.

Locator preference

data-testid / id
CSS selectors
XPath when needed
Avoid long absolute paths

94. XPath and CSS Selectors

CSS is often faster/readable; XPath helps with text/parent axes.

Selector examples

CSS: form#login input[name='email']
XPath: //button[normalize-space()='Sign in']

95. Selenium Waits

Wait for conditions (visible, clickable, present) with timeouts.

Wait tip

Explicit wait > Thread.sleep
Avoid flaky fixed sleeps
Centralize timeout defaults

96. Page Object Model (POM)

POM reduces duplication and eases locator maintenance.

POM idea

LoginPage.hideEmail()
LoginPage.enterPassword()
LoginPage.submit()
Tests call page methods only

97. Selenium with Java

Java remains common in enterprise Selenium stacks with Maven/Gradle.

Java stack

Java + Maven
Selenium WebDriver
TestNG/JUnit
AssertJ optional

98. Selenium with Python

Python enables readable tests and fast prototyping for QA teams.

Python stack

Python + pytest
Selenium WebDriver
Fixtures for driver setup
Allure optional reporting

99. Automation Framework Development

Separate tests, pages/services, test data, and utilities cleanly.

Framework layers

Tests
Page/API objects
Core driver/client
Config + data
Reporting + CI

100. Data-Driven Testing

Keep data in CSV/JSON/Excel and assert expected outcomes per row.

DDT tip

One script + many rows
Externalize data
Clear expected results column

101. Keyword-Driven Testing

Useful for business-readable tables; maintain keyword libraries carefully.

Keyword idea

OpenApp | url
Login | user | pass
Click | Checkout
VerifyText | Success

102. Hybrid Testing Framework

Most real frameworks are hybrid — pick pieces that reduce maintenance.

Hybrid pattern

POM for UI maps
Data-driven inputs
Reusable action keywords/helpers

103. BDD Testing

BDD improves shared understanding; automation should map cleanly to steps.

BDD scenario

Feature: Login
  Scenario: Valid user signs in
    Given I am on the login page
    When I sign in with valid credentials
    Then I should see the dashboard

104. Cucumber for BDD

Keep scenarios business-focused; push technical detail into step code.

Cucumber tip

Features/*.feature
Step definitions
Hooks for setup/teardown
Avoid UI detail in Gherkin

105. Playwright for Test Automation

Playwright is popular for fast, stable UI tests and API testing helpers.

Playwright strengths

Auto-wait
Chromium/Firefox/WebKit
Trace viewer
APIRequestContext

106. Cypress for Test Automation

Great DX for JS teams; know trade-offs vs multi-tab/multi-origin historically (improving over time).

Cypress tip

cy.visit / get / click
Fixtures for data
Network intercepts
CI parallelization

107. API Automation

API automation often gives the best ROI before heavy UI automation.

API automation stack ideas

Postman/Newman
Rest Assured (Java)
pytest + requests
Playwright API
CI gating

108. Performance Testing with JMeter

Start with a baseline script; parameterize users/data; analyze response times and errors.

JMeter building blocks

Thread Group
HTTP Request
Listeners/Reports
Assertions
CSV Data Set

109. Test Automation Best Practices

Avoid flaky sleeps, over-E2E, and testing everything through the UI.

Best practices

Test pyramid
Stable locators
Explicit waits
Independent tests
Clear reports
Quarantine flaky tests

110. QA Interview Questions

Be ready to explain STLC, severity vs priority, test design techniques, and framework choices.

Sample Q&A

Q: Severity vs Priority?
A: Severity = impact; Priority = fix urgency.

Q: Smoke vs Sanity?
A: Smoke = broad build acceptance; Sanity = narrow check after small change.

Q: Why POM?
A: Centralize locators/actions; easier maintenance.

111. Real-World Testing Project

Practice requirement review → cases → execution → bugs → regression → summary report.

Project workflow

Read requirements
Write RTM + cases
Execute + log bugs
Retest + regress
Publish test summary

112. Final Project – Complete Web Application QA Testing

Pick a demo web app (e.g., e-commerce/admin). Deliver RTM, test plan, 40+ cases, bug reports, Postman collection, Selenium/Playwright smoke pack, and a final QA sign-off report with risks.

  1. Select target web app and environments.
  2. Produce plan, RTM, and cases.
  3. Execute manual + API + automation smoke.
  4. File bugs and write the final QA report.

Final project deliverables

1. Test plan + scope
2. RTM linked to requirements
3. Manual functional + negative cases
4. API collection (auth + CRUD)
5. Cross-browser smoke notes
6. Automation smoke (login + core journey)
7. Logged defects with severity/priority
8. Execution report + go/no-go recommendation

Suggested app areas to cover

Auth (login/logout/reset)
Profile update
Search/list/filter
Create-edit-delete entity
Checkout or form submit
Role-based access
Basic responsive checks

Conclusion

You now have a full QA path: fundamentals, design techniques, platform testing, tools, and automation. Finish the final web application QA project to turn the lessons into portfolio-ready evidence.

Keep reading

Related guides

More setup guides and walkthroughs worth reading next.

Leave a reply

Your email address will not be published. Required fields are marked *