Manual testing is the discipline of exercising software by hand against a defined plan, rather than relying on scripts, to confirm it behaves the way requirements say it should. It sits inside the Software Testing Life Cycle (STLC), the structured sequence every QA team follows from reading a requirement to signing off a release, and it remains the foundation every automation engineer builds on: a badly designed test case automates just as badly as it was written by hand. What separates a useful tester from someone who "clicked around and it seemed fine" is test case design — techniques like boundary value analysis and decision tables turn a vague requirement into a small, deliberately chosen set of inputs that actually expose defects instead of a random guess. This cheat sheet covers the STLC, how to write test plans and test cases that hold up under scrutiny, the core black-box and experience-based design techniques, the testing types practitioners reach for daily, and how defects are triaged, tracked, and measured once they're found.
What This Cheat Sheet Covers
This topic spans 14 focused tables and 99 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: STLC Phases (Software Testing Life Cycle)
The Software Testing Life Cycle is the sequence every testing effort moves through inside the broader SDLC, and it's what actually produces the plans, cases, and reports a project relies on. Each phase has its own entry criteria, deliverables, and exit criteria, so skipping one usually surfaces later as a rushed release or a defect nobody planned for.
| Phase | Example | Description |
|---|---|---|
Reviewing the SRS and flagging that a "password reset" requirement never states a token expiry time | Testers study the requirements and interview stakeholders to spot ambiguous, missing, or untestable requirements before any test is written. | |
Deciding the release needs load testing but not accessibility testing, and setting exit criteria at 95% pass rate | Defines scope, strategy, and resourcing, and sets the entry and exit criteria that decide when testing can start and stop. | |
Writing "Verify login with valid credentials redirects to /dashboard" as a numbered, repeatable case | Testers write detailed test cases and test data, then map each one back to a requirement in the Requirement Traceability Matrix. |