Manual Test Execution

Why it matters

Execution is where a team sees how the product actually behaves, and everything before it pays off only if the results can be trusted. A step marked "passed" after a quick glance can let a wrong amount or a misleading message reach customers; a "failed" with no details can cost a developer hours of guessing.

For the tester, a careful run produces evidence others act on: the release decision, the defect report, the retest after a fix. Results that say what ran, on which build, with which data and what happened can be trusted and repeated; results written from memory cannot.

Executing one test case, step by step

A test case reaches you as part of a test run: one execution of a set of tests on one specific build. Read the whole case before you start, and ask about anything unclear now, not halfway through.

Then work through it in a fixed rhythm:

• Check the preconditions and note the context: build, environment, browser or device, account and data. If a precondition cannot be met, do not improvise; record why the test could not run.
• Perform one step exactly as written, with the stated data. If you must deviate, for example because a field was renamed, record it.
• Observe the whole result: the screen, messages, amounts, the next page, and any email the step should trigger.
• Compare the actual result with the expected result. On a match, go to the next step; on a mismatch, capture what you saw before doing anything else.
• After the last step, record the outcome and clean up the data the case changed, so the next test starts from a known state.

Try it: Temporary Email

Comparing expected and actual results

The expected result is the behaviour the test basis predicts, written into the test case before execution; whatever tells you the correct behaviour, such as a requirement, an acceptance criterion or a previous version, is a test oracle. The actual result is what the system really does. The comparison must be exact: "This code is not valid" is not "This code has expired", and 216.00 is not 240.00.

Compare every part the expected result states: text, values, the state of the data, the next screen. A mismatch is an anomaly, not yet a verdict. Before calling it a defect, confirm that you performed the step correctly with the right data and build, and that the expected result agrees with the test basis. Never edit the expected result to match the system; if the test case is wrong, record that and have it corrected.

For long messages or JSON responses (the structured data many APIs return), paste the expected and the actual text into a diff tool: it highlights every difference more reliably than your eyes.

Try it: Text Diff Try it: JSON Diff

Recording what happened

Each run produces what ISTQB calls a test log, a chronological record of the relevant details of test execution, usually kept in a test management tool or a shared spreadsheet. Fill it in while testing, so that someone else can understand, repeat and retest your run without asking you.

• Which test: the test case ID and its version.
• Context: build, environment, browser or device, test data or accounts, tester, date and time.
• Outcome: passed when every actual result matched its expected result, failed when at least one did not. Other statuses, such as blocked, come in the lesson on test suites and test runs.
• The full actual result of every step that did not match, not just the word "failed".
• Evidence and links: screenshot or log references and the ID of any defect report raised.

Staying observant beyond the script

A test case tells you what to check, not everything that can go wrong. While you focus on one expected result, other problems can appear on the same screen: a total that does not add up, a broken layout, a slow response, an error in the browser console, a label in the wrong language. Follow the script, but keep your eyes open.

When you notice something outside the expected results, do not abandon the case. Note it at once with the time and what you were doing, finish the case, then try it again and report it on its own. It does not change the status of the case, which describes only that case's expected results. If it reveals a gap in the test cases, propose a new case or an extra expected result.

Problems in the test case itself are findings too: steps that no longer match the screens, outdated data, an expected result that contradicts the requirement. Record them so the case is fixed before the next run.

Worked example: running TC-07 on build 4.2.0

Sara runs TC-07 on staging. Steps 1, 3 and 4 match. In step 2 the code is rejected, but the message differs from the expected text taken from the acceptance criterion. She checks that she typed OLD5 correctly and that the code is set up as expired, takes a screenshot, finishes the steps and records the case as failed.

She also notices that after the rejected code the VAT line showed 0.00 SAR until she reloaded the page. No step of TC-07 checks VAT, so she notes it, reproduces it after the case and reports it as a separate defect, proposing a new test case.

TC-07   Expired promo code is rejected (version 2)
Run:    build 4.2.0, staging, Chrome desktop, 2026-10-06 10:42, tester Sara
Data:   account cust-basic-01, cart CART-3 (240.00 SAR), code OLD5 (expired)

Step 1  Expected: the cart shows 3 items, subtotal 240.00 SAR
        Actual:   as expected                                    [passed]
Step 2  Expected: message "This code has expired", no discount line
        Actual:   message "This code is not valid", no discount line
        Evidence: tc07-step2.png                                 [failed]
Step 3  Expected: the subtotal is still 240.00 SAR
        Actual:   240.00 SAR                                     [passed]
Step 4  Expected: after a reload, no code is applied
        Actual:   as expected                                    [passed]

Status:   failed (step 2), defect DEF-412 raised
Observed: after step 2 the VAT line showed 0.00 SAR until a reload, seen twice;
          not checked by TC-07: reported as DEF-413, new test case proposed

Try it: Text Diff

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesISO/IEC/IEEE · 2021The test process model: organisational, test management and dynamic test processes, with their activities and outcomes.
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021Templates and content for test documentation — test policy, strategy, plan, status and completion reports, incident reports.