Manual testing done well

Turning requirements into test ideas, testing with a plan and curiosity, and writing bug reports that developers act on.

Also called acceptance criteria, testability review

What: Reading a user story or specification before any code exists and asking questions: what happens on errors, at limits, with empty input, for which users.
Why: Ambiguities found in a requirement cost a conversation to fix. The same gap found after release costs a hotfix, and your questions become your first test ideas.
Example: "Users can upload a profile photo" raises: which formats, what size limit, what if the upload fails halfway, and who can see the photo?

Also called EP, equivalence classes

What: Splitting possible inputs into groups the system should treat the same way, then testing one value from each group.
Why: It cuts an endless set of inputs down to a handful of tests without losing coverage of distinct behaviours.
Example: An age field accepting 18 to 60 has three partitions: below 18, 18 to 60, above 60. Test 10, 35 and 70, plus a non-number.

Also called BVA, edge cases, boundary value

What: Testing the values at and next to the edges of each partition, where off-by-one mistakes live.
Why: Developers often write < where they meant <=. Boundaries are where those bugs show up.
Example: For 18 to 60, test 17, 18, 60 and 61. A discount for orders "over 5,000" needs 5,000 and 5,001.

Watch out

Testing only the middle of a range, which almost never finds the bug.

What: A table listing combinations of conditions and the expected result for each, used when a rule depends on several inputs at once.
Why: It makes missing or contradictory business rules visible and gives one test per meaningful combination.
Example: Free delivery depends on member status and order value: four combinations, each with an expected delivery charge.

Also called test script, test steps, test case, checklist

What: A test case gives preconditions, steps, test data and an expected result. A checklist is a shorter list of things to verify, trusting the tester to fill in the steps.
Why: Detailed cases suit regulated work and handover; checklists are faster to write and maintain for most teams. Both make coverage visible and repeatable.

Watch out

A test case with no expected result, so two testers reach different verdicts on the same behaviour.

Also called charter, session-based testing, SBTM

What: Designing and running tests at the same time, learning as you go, usually in a timed session guided by a charter such as "Explore checkout with expired cards to discover how errors are handled".
Why: It finds the bugs nobody wrote a case for. Charters and short session notes keep it focused and reportable instead of random clicking.

Watch out

Exploring with no charter and no notes, so nobody can tell what was covered.

Also called defect report, issue

What: A record of a problem with a clear title, steps to reproduce, expected and actual results, environment details and evidence such as screenshots, logs or a video.
Why: A developer who can reproduce a bug in a minute fixes it. One who cannot will close it as "cannot reproduce".
Example: Title: "Checkout total ignores 10% coupon when basket has 2+ items". Steps, test account, browser version, actual 5,000, expected 4,500.

Watch out

Vague titles like "Checkout broken" and several unrelated problems in one report.

Also called severity, priority

What: Severity is how badly the bug affects the system. Priority is how soon the team should fix it. Testers usually propose severity; product owners set priority.
Why: They are different questions, and mixing them causes arguments. A typo in the company name on the home page is low severity but high priority.
Example: A crash in a rarely used admin export: high severity, possibly lower priority than a wrong price shown to every customer.

Also called defect workflow

What: The states a bug moves through: new, triaged, in progress, fixed, ready for retest, then closed or reopened. Teams name them differently.
Why: Knowing the workflow tells you when to retest, when to reopen instead of filing a duplicate and who owns the next step.

Watch out

Closing a bug after checking only the exact steps, without a quick look at nearby behaviour the fix may have changed.

Also called smoke test, sanity check, regression testing, regression suite, regression pack

What: A smoke test is a quick check that a build works at all. A sanity check confirms one fix or small change. Regression testing checks that existing features still work after a change.
Why: They decide how much to run and when: smoke on every deploy, regression before a release, the most repetitive regression checks first in line for automation.

Also called Jira, Xray, Zephyr, TestRail

What: Tools that store test cases, plan test runs, record results and link them to requirements and bugs. Jira tracks issues; add-ons such as Xray or Zephyr, or tools such as TestRail, manage the tests.
Why: They answer the questions managers ask before a release: what was tested, what failed, and which requirements have no tests.

Watch out

Keeping hundreds of stale cases in the tool that nobody runs, which gives a false picture of coverage.

Go deeper