Hands-on · 10–15 minutes each

Time to do, not just read.

Two short activities — one for BA, one for QA. You don't need any tools installed. Just a notepad or a blank document to write in. These are the same types of tasks you'd do on a real project.

Lab 1 — BA

Write acceptance criteria for a real user story

Your brief

A client is building a self-service booking system for a physiotherapy clinic. The product owner has given you the following user story. Your job is to write the acceptance criteria.

User Story

As a patient,
I want to book an appointment online,
so that I don't have to call the clinic during business hours.

Write at least 4 acceptance criteria for this story. Each one should be specific, testable, and unambiguous — a tester should be able to read it and know exactly what to check.

Need a hint?

Think about these angles: What time slots should be available? What happens if a slot is already taken? What confirmation does the patient receive? Can they cancel or reschedule? What happens if they enter invalid details?

See a sample answer

Here's one possible set of acceptance criteria. Yours don't need to match exactly — good BA work often looks different from different angles. What matters is specificity and testability.

  • The patient can select an available appointment slot from a calendar showing the next 14 days
  • Slots already booked by other patients are displayed as unavailable and cannot be selected
  • After booking, the patient receives a confirmation email within 2 minutes containing the date, time, and practitioner name
  • The patient can cancel an appointment up to 24 hours before the scheduled time via a link in the confirmation email
  • If the patient enters an invalid email address, an inline error message appears before the form is submitted
  • The booking form is accessible on mobile devices with screen widths from 320px and above

Notice: each criterion is specific, testable, and has a clear pass/fail state. "The system should be easy to use" would not make this list.

Bonus — Accessibility AC

Australian government projects must meet WCAG 2.1 AA accessibility standards. Try writing one acceptance criterion that addresses accessibility for this booking form.

See an example accessibility AC

All form fields have a visible, descriptive label that is programmatically associated with the input — not just placeholder text — so that screen reader users can identify each field correctly.

Lab 2 — QA

Find and log defects on a real (broken) page

Your brief

A client has sent you two pages from their registration system for review before launch. Your job is to test them and document what you find — exactly as you would on a real project.

For each defect you find, write it up using this format:

Title: Short description of the defect Steps to reproduce: Numbered steps to make it happen Expected: What should happen Actual: What actually happens Severity: Critical / High / Medium / Low

Open both pages below. Take your time. Write down everything you notice — big or small. A real QA doesn't ignore the small stuff.

QA
Login page
Opens in a new tab
QA
Registration page
Opens in a new tab
Need a hint? (read only after you've tried)

Look at these areas: page titles and headings, form labels, navigation links, button behaviour, input types, validation, contrast and readability, error messages, and anything that feels legally or professionally inappropriate.

See the full defect list — how many did you find?

These are the defects we planted. This is also an example of what a proper defect log looks like — notice the format, the severity ratings, and the level of specificity.

Login page defects
DEF-001 · Typo in page title and heading: "Logon hear"
Medium
Expected: "Log in" or "Login" — correct spelling Actual: "Logon hear" — misspelled in page title, h1, and tab title
DEF-002 · Password field not masked
Critical
Expected: Password input uses type="password" — characters hidden Actual: Password input uses type="text" — password visible on screen
DEF-003 · Missing form labels — accessibility failure
High
Expected: Each input has a programmatic label associated via for/id Actual: Placeholders used as labels — disappear on input, fail WCAG 1.3.1
DEF-004 · Form submit prevented with no user feedback
High
Expected: Submitting the form navigates the user or shows a clear result Actual: Nothing happens. No error, no navigation, no feedback whatsoever
DEF-005 · Broken navigation links
Medium
Home link points to # — goes nowhere. Register link routes to /account/Registar — broken path with typo baked in.
DEF-006 · Stale copyright date
Low
Footer shows © 2018. Damages credibility and may have legal implications depending on jurisdiction.
Registration page defects
DEF-007 · Typo in page title and heading: "Sing Up"
Medium
Expected: "Sign Up" — correct spelling Actual: "Sing Up" — appears in page title, h1, and submit button (three occurrences)
DEF-008 · All navigation links broken (badurl.com)
Critical
Expected: Nav links route to correct internal pages Actual: All links including Sign Up, Log on, Contact, Terms, and Conditions point to http://badurl.com — completely broken
DEF-009 · No client-side validation
High
No required attributes on any fields. Form can be submitted completely empty with no error shown to the user.
DEF-010 · Inappropriate brand tagline
High
Site header reads "GAP2IT — Get a Job or Die Trying". Unprofessional and potentially distressing. Not suitable for a client-facing registration page.
Reflection

How many did you find? Most people catch 5–7 on their first attempt without any training. With a structured approach — working through each area methodically — experienced testers find all 10 and often spot issues beyond the planted ones.

Notice the difference between Critical (password visible to shoulder-surfers, all navigation broken) and Low (stale date). Severity matters — it tells the development team what to fix first. That judgment is a skill, and you're already building it.

What to do with what you've just made

The acceptance criteria you wrote and the defect log you created are real work outputs. They belong in your evidence folder — the same folder you'll build throughout the full program.

  • Save your AC in a document labelled with the story and date
  • Format your defects as a simple table: ID, title, steps, expected, actual, severity
  • Screenshot anything visual — a screenshot is evidence, a description is not
  • Keep everything. Even early rough work shows progress over time

If it's not documented, it didn't happen. This is the first professional habit worth building.

← Back to Overview Next: Next Steps →