Knowledge Center

Free QA Resources, Written to Actually Teach

Original reference material and tutorials, drawn from real testing work — free to read, and free to share the page link. No comments; questions go to Ask Zelqa or our contact form.

Testing Fundamentals Test Documentation Technical Testing Test Types Career Preparation

Testing Fundamentals

SDLC — Software Development Life Cycle

SDLC is the sequence a piece of software moves through from idea to retirement: Requirements, Design, Development, Testing, Deployment, and Maintenance. Testing isn't a phase bolted on at the end — the earlier a team defines what "correct" looks like, the cheaper every later defect is to catch.

Requirements → Design → Development → Testing → Deployment → Maintenance
Testing that starts only after development finishes is the single most common cause of late, expensive bugs
A tester reviewing requirements early can catch ambiguity before a single line of code is written

STLC — Software Testing Life Cycle

STLC is the testing-specific process nested inside the SDLC: Requirement Analysis, Test Planning, Test Case Design, Environment Setup, Test Execution, and Test Closure. Where SDLC asks "is it built," STLC asks "is it built correctly" — with its own entry and exit criteria at every stage.

Requirement Analysis → Test Planning → Test Case Design → Environment Setup → Execution → Closure
Each phase has entry/exit criteria — you don't start execution without a stable environment and reviewed test cases
Test Closure includes a summary report, not just "we stopped testing"

Bug Life Cycle

A bug moves through defined states from the moment it's found to the moment it's verifiably fixed. Skipping states — like marking something "Fixed" without a Retest step — is how bugs quietly come back in a later release.

New → Assigned → In Progress → Fixed → Retest → Closed
Reopened is a real, expected state — not a failure of the process, it's the process working
A bug isn't "Closed" until someone other than the fixer verifies it

RTM — Requirement Traceability Matrix

An RTM maps every requirement to the test case(s) that verify it. It answers one question a checklist can't: "if this requirement changed, which tests would need to change too?" It's also the fastest way to show an auditor or stakeholder that nothing was skipped.

One row per requirement, linked to one or more test case IDs
Makes coverage gaps visible before execution starts, not after a bug ships
Doubles as audit evidence for regulated or enterprise clients

Bug Life Cycle — visualized

Test Documentation

Writing a Test Plan

A test plan defines scope, approach, resources, and schedule before execution starts — it's the document that lets someone outside the testing team understand what "done" will mean for this release.

Scope: what's in, and explicitly what's out
Approach: manual vs automated, by feature area
Entry/exit criteria: when testing can start, and when it's considered complete
Risks and assumptions, stated plainly

Smoke, Sanity & Regression Checklists

These three checklist types answer different questions at different speeds: is the build alive (smoke), did this specific fix work (sanity), and did anything else break because of it (regression).

Smoke — 10–15 critical paths, run first, decides go/no-go for further testing
Sanity — narrow, deep check on the exact area that changed
Regression — broad re-check across the product, prioritized by risk

Technical Testing

SQL for Testers — Getting Started

You don't need to be a DBA to use SQL as a tester — you need enough to verify what the UI claims is actually what's stored. Start with SELECT and WHERE to check individual records, then JOIN to verify relationships (does this order really link to this customer?).

SELECT + WHERE — verify a single record matches what the UI shows
JOIN — confirm relationships between tables are correct, not just individual rows
COUNT / GROUP BY — catch duplicate or missing records at a glance

REST API Testing — Getting Started

API testing means sending requests directly to the backend and checking the response — status code, payload shape, and timing — without a UI in the way. It catches contract-breaking changes before they ever reach a screen.

Check status codes for both success and failure cases, not just the happy path
Validate the response schema, not just that "it returned something"
Test auth: what happens with no token, an expired token, or the wrong role?

Postman Guide — Collections & Environments

Postman organizes API requests into collections, with environments holding variables (base URL, tokens) so the same collection runs against dev, staging, or production without editing every request.

Collections group related requests; environments swap the variables behind them
Use pre-request scripts to handle auth tokens automatically
Postman tests (assertions) turn a manual click into a repeatable check

Swagger / OpenAPI Guide

A Swagger (OpenAPI) spec is the source of truth for what an API is supposed to do — every endpoint, parameter, and expected response documented in one place. Testing against the spec, not just against what the API currently does, is how you catch undocumented behavior changes.

Read the spec before writing test cases — it defines "correct," not the current build
Mismatches between spec and actual behavior are bugs in themselves
Swagger UI lets you try requests directly from the documentation

Test Types

Regression Testing Explained

Regression testing re-checks existing functionality after a change, to catch anything the change broke that wasn't the target of the fix. As a product grows, a prioritized, partially-automated regression suite is what keeps release cycles from slowing to a crawl.

Prioritize by business risk, not just "test everything"
Automate what repeats every release; keep judgment-heavy cases manual
A regression suite is never "finished" — it grows with every real bug found

Smoke Testing Explained

Smoke testing is a fast pass over the most critical paths — can a user log in, can an order be placed — run immediately after a new build, before any deeper testing begins.

Kept intentionally small — minutes, not hours
A failed smoke test blocks further testing until fixed
Named after hardware testing: power it on and check for smoke before testing anything else

Career Preparation

QA Interview Questions — What to Actually Prepare

Most QA interviews test whether you can reason about a scenario out loud, not whether you've memorized definitions. Be ready to design test cases for an unfamiliar feature live, explain a bug you found in a past project end-to-end, and talk through the difference between related concepts (e.g. smoke vs. sanity) in your own words.

Practice designing test cases live, for a feature you've never seen before
Have one real bug story ready — how you found it, reported it, and confirmed the fix
Know the difference between concept pairs cold: smoke vs. sanity, verification vs. validation, retesting vs. regression