QA Onboarding · RFQ-Compare

Think Like
a Tester

We test all of it: we confirm it works,
and we hunt for the ways it breaks — before a customer finds them.

Program testing can be used to show the presence of bugs, but never to show their absence.

— Edsger W. Dijkstra, computing pioneer, 1970 · still the first lesson of every QA course today

In plain words Testing can prove bugs exist. It can never prove there are zero bugs. So we never say “it’s perfect” — we say “I looked hard, here’s what I found.”
Agenda

The next 45 minutes

5 minThe QA mindset
7 minSeven principles every tester works by
10 minHow to attack one feature from many angles — and why
7 minThe UX eye — spotting friction, clutter, extra clicks
7 minOur setup — you three are the company
7 minBug reports in Jira that actually get fixed
3 minTools + homework videos
Mindset5 min

Developers test the tip.
You test the whole iceberg.

  • Two questions, not one. “Does it work when I use it normally?” and “what happens when I don’t?”
  • You speak for the user. Every bug you catch is an angry customer that never happens.
  • Bugs are good news. Finding one is a win for the team. Report facts, never blame.
Principles · ISTQB Foundation8 min

The seven testing principles

1 · You can’t prove “zero bugs”So say “here’s what I found” — never “it’s perfect”.
2 · You can’t test everythingPick the biggest risks first: money, private data, first impressions.
3 · Test earlyA bug found today costs minutes. Found by a customer — days, plus trust.
4 · Bugs live in groupsFound one? Dig in the same place — there are usually more.
5 · Old tests wear out (“pesticide paradox”)Repeating the same steps finds nothing new. Change your data and your route.
6 · Know what matters hereFor us: wrong totals and privacy leaks beat a pixel that’s off.
7 · Zero bugs ≠ good productIf a screen confuses people, it’s broken — even with no bug in it.
Bugs lurk in corners and congregate at boundaries.

— Boris Beizer, “Software Testing Techniques” · the most useful sentence in test design

In plain words Bugs are not spread evenly. They hide at the limits — the biggest number, the empty field, the last day of the month — and in rare combinations nobody tried. Test there first.
Technique · angles of attack 1/212 min

One feature, seven angles

1 · Happy path

Do exactly what a well-behaved user does. Why — if this fails, nothing else matters. Confirming it works is half the job; the next six angles are the other half.

2 · Negative

Do what the app says you can’t: empty forms, wrong formats, past dates. Why — developers code the “yes” case first; the “no” cases are where they forget.

3 · Boundaries

Test the edges: 0, 1, max, max+1, empty, enormous. Why — code often says “less than” where it needed “less than or equal”. Only the edge values show it.

4 · Permissions

Try to see and do what your role should not allow. Why — one company seeing another’s prices = lost customer, possibly a lawsuit.

Technique · angles of attack 2/2

…and the three everyone forgets

5 · Interruptions

Refresh mid-save. Double-click submit. Press back. Two tabs. Why — a double-click can run the code twice: duplicate orders, double charges.

6 · Data states

Brand-new empty account vs. one with 500 orders. Why — developers test with 3 rows. Page 50, or the empty screen, they’ve never seen.

7 · Stranger’s eyes

Is it understandable without training? Why — confused users don’t file bugs. They leave. Confusion is a defect.

Worked example

Edge cases, made mechanical

Quantity field accepts 1–10 000. Don’t try 47 random numbers — test the edges of each zone:

Why it works: the developer wrote the limit as one small rule. If that rule is slightly wrong, only the numbers at the edge can show it. Most input bugs sit at an edge — these six values catch them, no luck needed.

Worked example

The “weird input” kit — and why each one matters

O'BrienTo a database, the apostrophe is a command sign. If the app doesn’t handle it, searches crash — and real customers have this name.
<script>alert(1)</script>Your text should be shown, never run. If the page runs it, an attacker can run worse. That’s a security bug.
مرحبا · 你好 · 😀Foreign letters and emoji are stored differently from a–z. Weak code scrambles them — and real suppliers have non-English names.
"abc "To a computer, abc␣ and abc are different words. Result: logins and searches fail for no visible reason.
5 000-character pasteLong text breaks layouts, gets silently cut by the database, overflows emails. Users paste from Excel all day.
A user interface is like a joke. If you have to explain it, it isn’t that good.

— Martin LeBlanc, designer & founder of Iconfinder

In plain words If you needed someone to explain a screen to you, that screen has a problem. Confusion is a bug — file it like one.
The UX eye7 min

“Broken” is not the only bug

The QA lens — broken

  • It crashes, or the total is wrong
  • The button does nothing
  • Data leaks to the wrong company

→ defect ticket

The UX lens — hard to use

  • I did it… but it took 7 clicks
  • I wasn’t sure which button to press
  • The screen shows 20 things; I needed 3

→ friction ticket

Same mission. Quality means it works and it works without thinking. Why you? — you still see the product with fresh eyes. In a month you won’t. That’s a superpower with an expiry date — use it now.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

— Antoine de Saint-Exupéry, writer & aviator

In plain words A page often gets better when you remove 30–50% of it. Fewer clicks, fewer choices, fewer words — same result, happier user.
The UX eye

Six ways to spot friction

Count the clicks

How many clicks to finish a core task? Every extra step loses users.

The squint test

Squint at the screen. What stands out? If everything shouts, nothing does.

Could we remove it?

Point at any element and ask: if this disappeared, would anyone miss it?

Do I have to remember?

Needing to memorize things between screens is the app’s failure, not yours.

Same name everywhere?

If it’s “Order” here and “RFQ” there, users think they’re two different things.

Do errors help?

“Something went wrong” helps nobody. An error should say what to do next.

Simplified from Nielsen’s 10 usability heuristics — the industry standard checklist since 1994.

The UX eye · worked example

Cutting 50% made it better

Nothing was lost — rare fields moved behind “More options”, three unclear buttons became one clear action. Why it matters — every field and button is a small decision. Cutting decisions, not features, is what makes software feel easy.

The UX eye

How to report a UX finding

✓ Friction ticket · label: UX
Title: [New order] Sending an RFQ
takes 9 clicks across 3 screens

Where: Project → New order → Send
What: I had to re-select the
supplier on every screen
Count: 9 clicks (video attached)

Suggestion (optional): remember
the supplier from step 1

House rules

  • Label it UX — not a defect severity, no bug-vs-opinion fights
  • Evidence over taste: click counts, timings, screenshots — not “I don’t like it”
  • A suggestion is welcome but not required — spotting friction is already the job
  • Lead reviews UX tickets weekly and picks what ships
Technique

Test like a real user, not like a robot

Real users…

  • Get distracted mid-flow, come back tomorrow
  • Paste messy data from Excel
  • Work on old laptops and slow connections
  • Never read instructions

So you…

  • Test whole journeys, not single screens
  • Keep realistic data — real-looking suppliers, items, prices
  • Write a charter: “Explore X as [persona] to find [risk]” — then wander for 60–90 min, taking notes

Why journeys? Bugs hide between the screens — something you create in step 2 breaks step 7. Testing one screen at a time never sees it.

Our setup8 min

You three are the company

A · Company Owner

Sets up the company: users, roles, permissions, plan limits. Tests — onboarding, settings, “can my people do too much?”

B · Buyer / Requester

The daily driver: projects, RFQs, sending to suppliers, comparing quotes, messages. Tests — the core money path, end to end.

C · The Outsider

A second company + the admin app. Tests — isolation: Company 2 must never see Company 1’s data.

Team lead: new features + full regression. Personas rotate later — fresh eyes on old screens (principle 5!).

Our setup

The company simulation

One shared storyline, replayed continuously. Every step is a test surface:

Sign up Create company Invite + roles Suppliers Project Build RFQ Send Quotes Compare & award Messages Delivery
Testing is a technical investigation of a product, done to expose quality-related information.

— Cem Kaner, author of “Testing Computer Software”

In plain words You are an investigator. What you deliver is information — “this flow works” is information, and so is a bug. The bug report is how you deliver the second kind. That’s the next skill.
Reporting8 min

A bug that isn’t reported well
doesn’t exist

✗ Unusable
Title: Orders broken!!

I tried to send the order and
it didn't work. Please fix asap.
✓ Gets fixed same day
Title: [Orders] "Send" stays
disabled after CSV import

1. Buyer, Company A, staging
2. Project → New order
3. Import items via CSV (attached)
4. Select supplier "Steelco"

Expected: Send enabled
Actual: greyed out; console
TypeError (screenshot)

Chrome 138/macOS · 3 of 3 tries

Title formula: [Where] What happens + when. Why — if a developer can replay your bug in 2 minutes, it gets fixed today. If they can’t, it waits forever.

Reporting

Severity, priority, etiquette

Severity = impact (yours)

  • Critical — data loss, security leak, money wrong
  • Major — core flow broken, no workaround
  • Minor — broken but avoidable
  • Trivial — polish, typos

Priority (when it’s fixed) is the lead’s call.

Etiquette

  • One bug per ticket — tickets go to different people; bundles never close
  • Search before filing — comment on the duplicate instead
  • Reproduce twice, state frequency (“3/3”, “~1 in 5”)
  • You verify the fix — never trust “fixed” without retesting
Toolbox4 min

Your toolbox (small on purpose)

Jira + our templateEvery bug lives here. The template mirrors the anatomy — fill every field.
Jam (jam.dev)One click captures video, console, network, steps — straight into Jira. Your default reporter.
DevTools (F12)Two habits: red in Console, red in Network → screenshot into the ticket.
Screen recorderLoom, or built-in: ⌘⇧5 / Win+G.
Session notesOne doc per session: charter, what you tried, what smelled wrong.
Homework

Watch this week

Day 1–2 Exploratory Testing, with example — testing without a script
youtube.com/watch?v=tiPBh_0Z6J8
Day 2–3 How to write a Defect Report — compare with our template as you watch
youtube.com/watch?v=ZVwCRSRxH_c
Day 3–4 Live exploratory testing session — watch a professional test, out loud
youtube.com/watch?v=xvUKVpOCqAY
Day 4–5 “Don’t Make Me Think” in 14 minutes — the UX classic, summarized
youtube.com/watch?v=79pRcSjwpcY
Week 1–2 Manual testing foundations course — 30–40 min/day
link in our channel

After each video, post one idea you’ll try tomorrow in the team channel. That’s the whole assignment.

Kickoff

Your first week

“Quality is everyone’s responsibility.”

— attributed to W. Edwards Deming, father of modern quality management

Meaning: quality is not only the QA team’s job — developers and designers own it too. But it starts with what you three find.

Questions?

1 / 25 ← → navigate · F fullscreen · N presenter notes