You've been invited to a testing session: what to do

An email has landed telling you you've been invited to a testing session. Maybe you're a developer, a product owner, a business analyst or a designer. Maybe you're the person paying for the project. Or you've been asked to try out something new and have never tested software in your life.

If "testing" makes you think of long checklists, specialist tools and people who know what they're doing, here's the good news. A session asks for none of that. Nobody hands you a script to follow. You're asked to use the product the way a real person would, for a fixed stretch of time. Along the way, you write down anything that goes wrong, confuses you or could be better. That's the whole job. This guide walks through it step by step: before, during and after.

Why you were invited, and not just the testers

It's tempting to think testing is a job for specialists. It isn't. Quality is the whole team's responsibility, and a session is one of the simplest ways to share it.

Each person sees the product differently. A developer knows where the code was hardest to write. A product owner knows what the business actually asked for. A business analyst knows the real-world process the screen is meant to support. A sponsor or a trial user sees it the way a customer will: with no idea how it's meant to work. That last view is the hardest for the people who built the product to reproduce. Once you know how something works, you can't unknow it.

So if you're thinking "I'm not a tester", that's exactly why your view is useful. You'll get confused in places the team stopped noticing long ago.

What a session is, in one minute

A session is a block of testing time with three things attached:

• A scope. One application, and usually a few features within it. The invitation tells you which.
• A time box. A start and an end, so nobody's asked to "have a look when you get a chance".
• A record. Everything worth mentioning is written down as a finding, so it's still there after everyone's gone home.

Often there are also session instructions: a short note from whoever organised the session about what's changed and why it matters. For the longer version, see What is Session Based Testing?

Here's what taking part looks like.

Before the session

1. Read the invitation properly

The invitation tells you four things. Which application you're testing, when the session starts, which features are in scope, and the session instructions. Read the instructions twice. They're usually short, and they explain why the session is happening at all. "The payment step was rebuilt this week" tells you where problems are most likely to hide.

Add the session to your calendar. Most invitations include a calendar entry you can open and save.

2. Get set up ahead of time

You'll need access to the application you're testing and to whatever tool your team uses to write findings down. Sort both out a day early, not at the start time. Logging in for the first time, or installing something, always takes longer than you'd expect. Nobody wants to spend the first 20 minutes of a session on a password reset.

3. Protect the time

Block out the session in your calendar. Close your email and silence chat if you can. Testing works best when you give it your full attention. A few minutes of real focus finds more than an hour of half-attention between meetings.

During the session

4. Open the product and start where a user would start

Don't open the most complicated screen first. Start where a real person would, from the home page or the first step of the task. Then try to do something real: place an order, book an appointment, update a customer's address, whatever the feature is for.

If the session instructions mention something specific, give it extra attention. Treat them as context, not orders. If something else catches your eye along the way, follow it.

5. Explore, don't just follow the happy path

Nobody breaks a product by using it exactly as the designer imagined. Problems turn up at the edges. If you're not sure what to try, here are some ideas that need no technical knowledge:

• Change your mind. Go back a step, change an answer, then carry on. Does the product keep up?
• Make a mistake on purpose. Leave a required field empty. Type letters where a number belongs. Enter a date in the past.
• Be impatient. Click a button twice. Refresh the page halfway through. Press the browser's back button.
• Use a different screen. Try it on your phone, or make the browser window narrow.
• Be a newcomer. Does every label make sense? Would you know what to do next without being told?
• Be an expert. If you do this task every day in your real job, is there anything that would slow you down?

This style of testing has a name: exploratory testing. The Agile Alliance describes it as designing, running and learning from tests all at the same time. It's also the kind of testing that doesn't need years of experience, only curiosity and attention.

6. Write it down the moment you notice it

When something is worth mentioning, capture it straight away. If you wait until the end of the session, you'll remember that "something was odd on the payment page" but not what you clicked to get there.

Each thing you write down is a finding. Findings come in three kinds:

• Bug. Something doesn't work as it should. The total didn't update. The page froze. The confirmation email never arrived.
• Question. You're not sure whether something is intended. "Should I be able to book a slot on a Sunday?" Questions are especially valuable from people who know the business. Only you might know the answer is "no".
• Improvement. It works, but it could be better. A confusing label, a missing shortcut, an extra step nobody needs.

Don't worry about picking the wrong kind. Whoever reviews the findings afterwards can sort that out.

7. Write it so someone else can act on it

A finding is only useful if someone who wasn't sitting next to you can understand it. That person has to find the problem again before they can fix it. Across six large collections of bug reports, researchers found about 1 in 6 couldn't be reproduced, and those stayed open about three months longer than the rest. A report can be unreproducible for many reasons, but clear steps are the part you control.

A good finding answers four questions:

1. What's the problem, in one line? This becomes the title.
2. What did you do? The steps, in order, as a short numbered list.
3. What happened?
4. What did you expect to happen instead?

Compare these two:

• Hard to act on: "Booking is broken."
• Easy to act on: "Booking a slot on a narrow screen shows no confirmation." Steps: 1) Make the browser window narrow. 2) Open the booking page. 3) Pick tomorrow at 10:00 and press Book. What happened: the page went back to the calendar with no message. Expected: a confirmation that the slot was booked.

The second one takes a minute longer to write. It saves a developer an afternoon of guessing. If a picture explains it better than words, add a screenshot. Check that it doesn't show anything private first.

For questions, the "what happened / expected" part doesn't apply. Just write the question clearly and say where you were when it came up.

8. Check it hasn't been logged already

In a session with several people, two of you will sometimes spot the same problem. Before you file a finding, check whether someone else already has. If they have, you've saved a reviewer from reading the same thing twice. If you've noticed something extra, like a different way to trigger it, add it to theirs rather than starting a new one.

9. Log it and move on

Once it's written down, get back to exploring. Resist the urge to dig into why something went wrong. Finding the cause is someone else's job, later. Your job is to notice and record, then carry on and find the next thing.

After the session

10. Finish your last finding

When the session reaches its end time, wrap up what you're doing. Most sessions leave a little room after the end to finish writing up a last finding, so don't abandon a half-written one. After that, the session closes and nothing more can be added to it.

11. Look out for follow-up questions

Every finding is reviewed afterwards, a step called triage. Someone decides whether it's a real problem, how urgent it is, and who should deal with it. They might ask you a question about one of yours: which browser you were using, or whether it happens every time. A quick answer while it's still fresh in your mind can be the difference between a fix and "could not reproduce".

That's it. You've taken part in a session.

"I don't have time for this"

A session is time-boxed for exactly this reason. You're not signing up to an open-ended project. You're giving an hour, sometimes less, with a clear start and end.

It's also time that pays back quickly. A problem you spot now is fixed before release. The same problem found by a customer next month turns into a complaint, an urgent fix and a meeting about how it slipped through. Even one good finding makes the hour worth it.

"What if I do it wrong?"

There's no wrong way to take part. A question that turns out to be "yes, that's intended" still tells the team the design isn't as obvious as they thought. A bug that's already known still confirms it happens. Triage is there to sort findings, so you don't have to get every one perfect.

The only real mistake is noticing something and not writing it down.

How this works in Session Based Testing

Everything above applies whatever tool your team uses. If your team uses Session Based Testing, the invitation arrives by email with a calendar file attached. Findings are logged from a small panel that opens beside the page you're testing, in Chrome, Edge or Firefox. The panel checks for duplicates before a finding is filed, and attaches technical details the developers need, such as the web address you were on, without you typing them.

The user manual's guide for session participants walks through setting up and filing your first finding, screen by screen.

Want to run sessions like this with your own team? Sign up for the Allways Free tier (no credit card needed).