Practical 3: Manual Test Case Design and Execution

The ISTQB syllabus says of boundary values that when two elements belong to the same partition, all elements between them must also belong to it, which is why the edges are where a wrong comparison shows itself.

The given web application

The application under test is the Student Registration page of the Practice Portal, register.php, which the browser opens at localhost:8080/register.php. Its source is printed at the end of this chapter, for setting the practical up. Do not read it before testing. A tester works from the requirements, which are the promise, and not from the code, which is the attempt.

The requirements given to the tester:

Step 1: the test plan

A test plan for a practical is one page. Its headings follow the ISTQB syllabus's list of what a test plan typically contains: the context of testing (scope, objectives, test basis), assumptions and constraints, stakeholders, communication, a risk register, the test approach, and budget and schedule.

Step 2: the test scenarios

One scenario for each thing to be tested, each traced to its requirement:

Tracing each scenario to a requirement is what makes a gap visible: a requirement with no scenario is a requirement nobody tested.

Step 3: the test cases

Every test case starts from the same valid values and changes only what it is testing. Using one baseline means a failure can have only one cause.

The common steps for every case are: open the registration page, enter the valid values, change the field named in the test data, click Register, and read the page.

The boundary cases, and why each value was chosen:

• Full name: 2 and 3 characters are either side of the minimum; a 40-character name and a 41-character name are either side of the maximum.
• Mobile number: 9, 10 and 11 digits; a first digit of 5, just outside the allowed 6 to 9, and of 6, just inside.
• Date of birth: born on 1 July 2009 is exactly 17 on 1 July 2026, the first valid date; born on 2 July 2009 is one day short.
• Password: 7 characters and 8 characters.

Step 4: execute them, and record what happened

Execute each case by hand, in order, on a freshly reset site (localhost:8080/reset.php), and write down what the page actually said. The order matters for one reason only: each accepted registration takes the next registration number.

Three things to notice in how the table was filled:

• Expected results were written before execution. An expected result written after seeing the page is not an expectation.
• A pass or fail is a comparison, not an opinion: TC19 passes because the page did reject a password with no digit, which is all it tested, even though the message is misspelled. The misspelling is TC17's finding, and one defect is reported once.
• TC22's list is the page's own, in its own order, and it is where requirement R10 is tested: seven fields wrong, seven problems listed.

Step 5: the test execution report

All 22 test cases designed were executed. The pass rate is 17 of 22, about 77.3 per cent. Five test cases failed, and each failure is one defect.

A report ends with a recommendation. Here: the page does not meet requirements R1, R3, R4, R6 and R7 in full, and should not be released until the five defects below are fixed and their test cases pass on a second run. Running the failed cases again after a fix is called confirmation testing, and running the passed ones again, to check the fix broke nothing, is regression testing.

Step 6: the defect report

The ISTQB syllabus lists what a defect report typically includes: a unique identifier, a title with a short summary, the date, the author, the test object and environment, the context (such as the test case being run), a description that lets somebody reproduce the failure, expected and actual results, severity, priority, status, and references.

Severity is how bad the defect's effect is. Priority is how soon it should be fixed. They are not the same: a spelling mistake on a college's home page is trivial in severity and may still be high in priority.

DEF-01: Mobile number with 9 digits is accepted

• Test case: TC08. Requirement: R3.
• Environment: Practice Portal, register.php, PHP 8.4 built-in server, Firefox.
• Steps: open the registration page; enter the valid values; change Mobile number to 987654321; click Register.
• Expected: the registration is rejected, with the mobile number message.
• Actual: "Registration successful. Your registration number is REG-2026-0005."
• Severity: Major. Priority: High. Status: New.

DEF-02: Mismatched passwords are accepted

• Test case: TC20. Requirement: R7.
• Steps: valid values; change Confirm password to Secret999; click Register.
• Expected: rejected, because Confirm password differs from Password.
• Actual: registered as REG-2026-0010. No message about the passwords appears at all.
• Severity: Major. Priority: High. Status: New.

DEF-03: A student one day under 17 on 1 July 2026 is accepted

• Test case: TC13. Requirement: R4.
• Steps: valid values; change Date of birth to 2009-07-02; click Register.
• Expected: rejected; the student is 16 on 1 July 2026.
• Actual: registered as REG-2026-0008. (Born 2010-01-01 is correctly rejected, TC14, so the age check exists but is wrong near the boundary.)
• Severity: Major. Priority: Medium. Status: New.

DEF-04: Full name longer than 40 characters is accepted

• Test case: TC05. Requirement: R1.
• Steps: valid values; change Full name to a 41-character name, Sri Venkata Lakshmi Subramaniam Chowdhary; click Register.
• Expected: rejected; the maximum is 40.
• Actual: registered as REG-2026-0004.
• Severity: Minor. Priority: Low. Status: New.

DEF-05: Spelling mistake in the password message

• Test case: TC17. Requirement: R6.
• Steps: valid values; change Password and Confirm password to Secret1; click Register.
• Expected: the message "Password must be at least 8 characters and contain a digit."
• Actual: "Pasword must be at least 8 characters and contain a digit."
• Severity: Trivial. Priority: Low. Status: New.

A good defect title says what is wrong in the user's terms, not what the tester thinks the code does: "Mobile number with 9 digits is accepted", not "validation regex wrong". Practical 20 logs these same five defects in Bugzilla.

Doing it in Excel or Google Sheets

Keep the practical in one workbook with one sheet for each document: Plan, Scenarios, Test cases, Execution report, Defects. On the Test cases sheet, put the columns in this order: ID, Scenario, Test data, Steps, Expected result, Actual result, Status.

Make the Status column a dropdown of Pass, Fail, Blocked and Not run, so that nobody types "passed" in one row and "PASS" in another; both programs call this data validation. Then the execution report can count for itself. Microsoft's own description of COUNTIF is COUNTIF(range, criteria), where the criteria can be a word such as "apples". With the statuses in cells G2 to G23:

Passed:   =COUNTIF(G2:G23,"Pass")
Failed:   =COUNTIF(G2:G23,"Fail")
Blocked:  =COUNTIF(G2:G23,"Blocked")
Total:    =COUNTA(G2:G23)

A report that counts its own figures cannot drift from the table it reports on, which is the whole point of doing it in a spreadsheet rather than typing the numbers.

The page's source, for setting the practical up

Read this only after the test cases are executed. Save it as practice/register.php, and create registrations.json in practice/seed, holding just [], an empty list:

<?php
// register.php: the student registration form tested by hand in Practical 3.
// NOTE: this page carries deliberate defects, so that a tester has something to find.
require 'inc/store.php';
$courses = ['B.Sc. CS', 'B.Sc. IT', 'B.Com.'];
$v = ['name' => '', 'email' => '', 'mobile' => '', 'dob' => '', 'course' => ''];
$errors = [];
$success = '';

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    foreach ($v as $key => $unused) {
        $v[$key] = trim($_POST[$key] ?? '');
    }
    $password = $_POST['password'] ?? '';
    $confirm = $_POST['confirm'] ?? '';

    if (!preg_match('/^[A-Za-z ]{3,}$/', $v['name'])) {
        $errors[] = 'Name must be at least 3 letters, using letters and spaces only.';
    }
    if (!filter_var($v['email'], FILTER_VALIDATE_EMAIL)) {
        $errors[] = 'Please enter a valid email address.';
    }
    if (!preg_match('/^[6-9][0-9]{8,9}$/', $v['mobile'])) {
        $errors[] = 'Mobile number must be 10 digits and start with 6, 7, 8 or 9.';
    }
    $d = explode('-', $v['dob']);
    if (count($d) !== 3 || !ctype_digit(implode('', $d)) || !checkdate((int) $d[1], (int) $d[2], (int) $d[0])) {
        $errors[] = 'Please enter a real date of birth as YYYY-MM-DD.';
    } elseif (2026 - (int) substr($v['dob'], 0, 4) < 17) {
        $errors[] = 'You must be at least 17 years old on 1 July 2026.';
    }
    if (!in_array($v['course'], $courses, true)) {
        $errors[] = 'Please choose a course.';
    }
    if (strlen($password) < 8 || !preg_match('/\d/', $password)) {
        $errors[] = 'Pasword must be at least 8 characters and contain a digit.';
    }
    if (!isset($_POST['terms'])) {
        $errors[] = 'You must accept the terms to register.';
    }

    if (count($errors) === 0) {
        $all = load_records('registrations');
        $all[] = ['name' => $v['name'], 'email' => $v['email'], 'course' => $v['course']];
        save_records('registrations', $all);
        $success = sprintf('Registration successful. Your registration number is REG-2026-%04d.', count($all));
    }
}
$title = 'Student Registration';
include 'inc/top.php';
?>
<h1>Student Registration</h1>
<?php if ($success !== ''): ?>
  <p id="success" class="success"><?= htmlspecialchars($success) ?></p>
<?php else: ?>
  <?php if ($errors): ?>
    <ul id="errors" class="error">
      <?php foreach ($errors as $e): ?><li><?= htmlspecialchars($e) ?></li><?php endforeach; ?>
    </ul>
  <?php endif; ?>
  <form method="post" action="register.php">
    <label>Full name <input type="text" name="name" id="name" value="<?= htmlspecialchars($v['name']) ?>"></label>
    <label>Email <input type="text" name="email" id="email" value="<?= htmlspecialchars($v['email']) ?>"></label>
    <label>Mobile number <input type="text" name="mobile" id="mobile" value="<?= htmlspecialchars($v['mobile']) ?>"></label>
    <label>Date of birth (YYYY-MM-DD) <input type="text" name="dob" id="dob" value="<?= htmlspecialchars($v['dob']) ?>"></label>
    <label>Course
      <select name="course" id="course">
        <option value="">-- Select --</option>
        <?php foreach ($courses as $c): ?>
          <option<?= $v['course'] === $c ? ' selected' : '' ?>><?= htmlspecialchars($c) ?></option>
        <?php endforeach; ?>
      </select>
    </label>
    <label>Password <input type="password" name="password" id="password"></label>
    <label>Confirm password <input type="password" name="confirm" id="confirm"></label>
    <label><input type="checkbox" name="terms" id="terms"> I agree to the terms</label>
    <p><button type="submit" id="registerBtn">Register</button></p>
  </form>
<?php endif; ?>
<?php include 'inc/bottom.php'; ?>

[]

Now read the code against the defect report, which is what a developer will do. Each defect is one line:

• DEF-01 is the mobile pattern [0-9]{8,9} after the first digit: eight or nine more digits, so nine digits in all passes. It should be exactly nine more.
• DEF-02 is an absence: $confirm is read and never compared with $password.
• DEF-03 is 2026 - (int) substr($v['dob'], 0, 4) < 17, which compares only years. Anybody born in 2009 counts as 17, whatever the month.
• DEF-04 is the name pattern {3,}: at least three, with no upper limit. It should be {3,40}.
• DEF-05 is a typing mistake inside a message.

Black-box testing found all five without reading a line of this, which is the point of it: the tests came from the requirements.

Result

A test plan, nine test scenarios and twenty-two test cases were prepared for the Student Registration page and executed manually. Seventeen passed and five failed. The test execution report and a defect report of five defects, three major, one minor and one trivial, were prepared. The page does not meet requirements R1, R3, R4, R6 and R7 in full.

Where marks are lost

Expected results written after execution. Write them first, or the test proves nothing.

Changing two fields in one test case. When it fails, you cannot say which field caused it.

No boundary values. "Mobile number: 12345" tests one partition; the defects are at 9 and 11 digits.

Reporting the same defect twice. The misspelled message appears in three test cases; it is one defect.

A defect report nobody can reproduce. Steps, data, expected and actual, every time.

Mixing up severity and priority. Severity is impact; priority is urgency.

Typed-in report figures. Count them from the Status column.

For the journal

Aim; the application under test and its requirements; the test plan; the test scenarios with their requirements; the valid values; the test case table with actual results and status; the test execution report; the defect report; the result. Attach a printout of the spreadsheet if your college asks for one.

Quick revision

• STLC in ISTQB's terms: planning, analysis, design, implementation, execution, completion, with monitoring and control throughout.
• Test plan: scope, approach, environment, entry and exit criteria, deliverables, risks.
• Scenario: what to test, traced to a requirement. Test case: exact data, steps, expected result.
• Equivalence partitioning: one value per partition. Boundary values: the edges, on both sides.
• Expected result before execution. Pass or fail is a comparison.
• Defect report: ID, title, steps, expected, actual, severity, priority, status, test case.
• Severity is impact; priority is urgency.
• Here: 22 cases, 17 passed, 5 failed, 5 defects.

Questions you must be able to answer

1. What is the difference between a test scenario and a test case? A scenario says what is to be tested, in a line. A test case is one concrete check of it, with exact data, steps and an expected result.

2. Why test a 41-character name when the limit is 40? Boundary value analysis: defects collect at the edges of a range, so the values just inside and just outside it are the ones most likely to expose a wrong comparison. Here, 41 characters exposed DEF-04.

3. Why does every test case change only one field? So that a failure has exactly one possible cause.

4. TC19's message is misspelled. Why is TC19 marked Pass? It tests only that a password with no digit is rejected, and it was. The misspelling is TC17's finding and is reported once, as DEF-05.

5. What is the difference between severity and priority? Severity is how much damage the defect does; priority is how soon it should be fixed.

6. What must a defect report contain for a developer to act on it? An identifier and title, the steps and data to reproduce it, the expected and actual results, the environment, severity, priority, status, and the test case that found it.

7. What is the pass rate here? Seventeen of twenty-two, about 77.3 per cent.

8. What is confirmation testing? Running a failed test case again after the defect it found has been fixed, to confirm the fix.