Grad techniques
Nothing clever yet. Your job at this level: look carefully, and write down what you see. These seven techniques are the foundation everything else builds on.
1. Smoke testing
A quick pass to confirm the most important things work: can I load the page, can I click the main button, does the form submit? If smoke fails, you don’t bother with anything else — the build isn’t worth testing yet.
How: walk the happy path end-to-end. Note every failure. Don’t try to be clever.
Time budget: 10–20 minutes maximum. If your smoke takes longer, it’s not a smoke test.
2. Visual review
Your eyes are a tool. Before you click anything, just look. Look at alignment, spacing, typography, colours, images, text. Is anything obviously wrong? Misaligned? Cut off? A placeholder left in?
How: scan the page top to bottom, left to right. Zoom out. Zoom in. Resize the window. What looks off?
Common finds: broken images, truncated text, overlapping elements, wrong colours, Lorem Ipsum left in, inconsistent fonts.
3. Spec vs reality
If there’s a design, a requirements doc, or a ticket — put it next to the product and compare. The spec says “blue button labelled ‘Submit’”. What does the actual page say?
How: list every testable statement in the spec. Tick the ones that match reality. Flag the ones that don’t.
Common finds: label text doesn’t match spec, wrong button colour, missing element, element in wrong position.
ISTQB link: comparing expected vs actual results is one of the seven testing principles (CTFL Ch. 1.1). Every test case needs an expected result — without it, you can’t tell pass from fail.
4. Content & copy review
Read every word on the page out loud. You’ll catch typos, grammar, broken sentences, and placeholders that never got replaced.
Welcome to our restuarant. We hope you enjoy your meal.
Common finds: "Submitt" instead of "Submit", leftover "[first name]" placeholders, wrong product name.
5. Link & button check
Click every link. Click every button. Do they go where they claim? Does the “Contact Us” button actually open contact? Does the logo link home? Are any buttons dead?
Common finds: links that go to the wrong page, 404 errors, buttons that do nothing, external links that opened in the same tab (should open in a new tab).
6. Basic exploratory testing
Not random clicking — structured wandering. Exploratory testing is about learning the system while you test it. Use a Charter to keep you focused.
Exploratory Charter Template:
Explore: [The feature/area]
With: [Tools like DevTools, different browsers]
To Discover: [Specific goal, e.g., how the cart handles massive quantities]
Timebox: 30 minutes.
The Debrief: After your time is up, ask yourself: "What did I learn that isn't in the spec?" "What area felt most fragile?" "Where should I spend more time tomorrow?"
7. Accessibility (a11y) basics
A11y isn’t just for senior testers. Even as a grad, you can spot the big ones. Can you navigate the page using only your keyboard? Are images missing descriptions?
How: unplug your mouse and try to "Tab" through the page. Can you see where the focus is? Do all images have an alt attribute?
<img src="logo.png" alt="">
alt text means a screen reader will just say "Image". It should be "Resync Logo".
8. DevTools for grads
Right-click anything on a page and select Inspect. This opens the browser's DevTools. It lets you see the code *behind* the pixels. It is a tester's x-ray vision.
- Elements: Use this to find typos in the HTML or hidden fields. You can even change the text live to see if a long name breaks the layout!
- Console: The most important tab for spotting "Silent Killers." If a button does nothing when clicked, check the Console — you'll often see a red error message here.
- Network: See the communication between the browser and the server. If a page is taking too long to load, check here to see if a massive 5MB image is the culprit.
→ Deep dive: DevTools for Testers learning module
9. Write it down
Every bug you find: title, steps, expected, actual, screenshot. You’ll forget by lunchtime otherwise. A bug that can’t be reproduced from your notes is a bug that doesn’t get fixed.
| Field | Example |
|---|---|
| Title | Submit button on contact form labelled "Submitt" (double-t typo) |
| Steps | 1. Navigate to /contact 2. Observe the submit button label |
| Expected | Button reads "Submit" |
| Actual | Button reads "Submitt" |
| Evidence | [screenshot attached] |
| Severity | Low — cosmetic |
ISTQB CTFL mapping
These grad techniques map to ISTQB Foundation Level concepts. You’re building the mental models that the CTFL exam tests formally.
| Grad technique | ISTQB reference | Chapter |
|---|---|---|
| Smoke testing | Test levels — system testing, acceptance testing | Ch. 2 |
| Visual review / spec vs reality | Expected vs actual results, test oracle | Ch. 1.1 |
| Copy review | Static testing, review types | Ch. 3 |
| Basic exploratory | Exploratory testing (4.4.3) | Ch. 4.4 |
| Write it down | Defect reports, defect lifecycle | Ch. 5 |