Stay in the flow: how a browser extension improves Session Based Testing

Most teams log bugs the same way. Someone spots a problem, switches to the issue tracker, and opens a new issue. They pick a project and a component, then paste the page URL. They grab a screenshot with another tool, crop it and upload it. Then they write the steps to reproduce from memory, and switch back to the browser to work out where they were.

Each step takes seconds. Together, they pull the tester's attention off the product at the exact moment it was most engaged. The bug gets logged, but the train of thought that found it is gone.

A browser extension changes where capture happens. With the Session Based Testing browser extension, findings are logged from a side panel on the page under test, automatically collecting a rich amount of data to reproduce the issue later. The tester stays on the page — and gets straight back to exploring and finding the next issue.

This post covers why that matters more than it sounds, what the research on flow and interruptions says, and what capture in the side panel does step by step.

Exploratory testing runs on flow

Mihaly Csikszentmihalyi spent decades studying people at their most absorbed: chess players, climbers, surgeons, artists. In his best seller book Flow: The Psychology of Optimal Experience (1990), he describes flow as "the state in which people are so involved in an activity that nothing else seems to matter".

Great exploratory testing happens when people are "In the flow". A tester follows a hunch through a checkout flow and notices that the total didn't update. Then they try different approaches and work their way through a mental tree of options until they tried all branches. None of that is in a script and it needs constant attention.

It's like completing a Sudoku, you really want to do it in one go, without distractions. Opening the door to a mail delivery can be overcome, but continuing the next day... You might as well start all over again.

Csikszentmihalyi names what makes that depth of involvement possible: "goals are usually clear, and feedback immediate." A session supplies both. The session instructions give the goal: which features, and why they're risky right now. The product supplies the feedback: every click either behaves or it doesn't.

He is also blunt about how fragile the state is. "Although the flow experience appears to be effortless, it is far from being so," he writes. "Any lapse in concentration will erase it."

The academic version of the model says the same thing about attention. In a later review of flow research, Nakamura and Csikszentmihalyi write that "staying in flow requires that attention be held by this limited stimulus field" and that "attention is finite." For a person executing testing, that field is the application under test. Every trip to another tool takes attention out of it.

What a tool switch actually costs

Research on interruptions has measured this cost in some detail, from office field studies down to brain imaging.

Seconds count

In one experiment, 300 participants worked through a task where they had to keep track of their place in a sequence of steps. Interruptions averaging 2.8 seconds doubled the rate at which they lost their place. Interruptions of 4.4 seconds tripled it. Exploratory testing runs on keeping your place: applied the code, switched to mobile width, now trying a different basket. Opening a new issue in a tracker takes far longer than 4 seconds.

A related set of experiments measured how long people take to pick a task back up. That resumption time grew with the length of the interruption, most steeply in the first seconds. It grew faster still when the interruption was demanding. Writing a bug report — a title, steps, expected and actual results — is about as demanding as interruptions get.

Ignoring something isn't the same as attending to it

Brain imaging helps explain why. An EEG and fMRI study compared two kinds of interference during a memory task. When people could ignore a distraction, the brain kept what they were holding in mind active. When the interruption needed their attention, it didn't. The memory had to be reactivated afterwards.

Filling in a form in another tool is the second kind. The tester's picture of where they were in the product has to be rebuilt when they come back. Meanwhile, research on attention residue found it's hard to pull attention away from an unfinished task. While the tester writes the report, part of their mind is still in the exploration.

In a controlled experiment by Gloria Mark and colleagues, interruptions on the same topic as the task were just as disruptive as unrelated ones. The authors conclude that "any interruption introduces a change in work pattern and is not related to context per se." Logging a bug about the thing you're testing feels like part of the job. It still costs you.

What's waiting in the tracker

Now picture the actual detour. A tester spots a bug and opens a new issue in GitLab. The top bar shows their open merge requests, their to-do count and the issues assigned to them. The issue list is full of other people's problems. A colleague's review request is one click away.

At best, each of those is a distraction to ignore. At worst, it becomes a second interruption. In a field study of 27 people at Microsoft, people who switched to their email client to answer one message took the opportunity to check other email too. It took them about 10 minutes on average to get back to what they'd been doing. The same study found that windows left mostly visible were returned to significantly faster than windows hidden behind others. A tracker tab hides the page under test completely.

The side panel has none of that. It shows the session you're in, its features and a finding form. There's nothing else to click on. And the page under test stays on screen the whole time. The resumption research recommends exactly that: a quick glance back at the suspended task keeps it alive.

The charter drifts

The bigger cost isn't the single bug. It's the session.

A session starts with a charter: the session instructions say which features matter and why. Keeping that goal in mind while doing something else is real cognitive work. Brain imaging shows a specific region at the very front of the brain engaging when people hold a main goal pending while they work on a side goal. And the resumption research shows a pending goal fades unless it's refreshed.

Every finding logged in another tool is another side goal, on another page full of other people's work. Every trip leaves the charter a little further behind. By the fifth bug, the tester is still testing. But more and more they're testing whatever the last issue list reminded them of, not what the session was for. The session was about discount codes, and somehow the last 20 minutes went on the address form.

The mechanism applies to each of these studies found, repeated once per bug. Keeping capture next to the page shortens every detour, so the charter has fewer detours to survive.

Side by side

What capture in the side panel looks like

Here's what logging a finding with the extension looks like, step by step. It works in Chrome, Edge and Firefox. In Firefox the panel opens as a sidebar.

• Open the panel. A keyboard shortcut (Ctrl+Shift+F by default) opens the side panel next to the page. You don't leave the page you're testing.
• Application & Feature. The panel remembers the session and feature, minimum of data needed.
• Write what you saw. Give it a title and a type: bug, question or improvement. Severity only appears for bugs, and it's optional. The steps field starts with a numbered outline to fill in. Bugs and improvements ask for the actual and expected result. A question asks for the question itself.
• Grab the screen. One button captures the visible tab. A crop window lets you keep only the part that matters.
• Check for duplicates. Before a finding can be filed, the panel checks the team's existing findings for similar ones and lists the closest matches. If someone already logged it, you find out now, not in triage.
• File it and carry on. "Submit + New" keeps the panel open for the next finding. "Submit + Close" gets it out of the way.

A couple of details matter more than they look.

1. Notice how the flow doesn't require the person testing to capture metadata to reproduce the issue. Much is captured automatically, so the user can keep going and stay "In the flow".
2. Every edit is saved as you type. If you close the panel to check something on the page, the half-written finding is still there when you reopen it.
3. you never leave the page, so you never have to find your way back to where you were.

The context nobody has to type

The written steps record what the tester meant to do. The extension also records what actually happened.

While a session is running, the extension captures a repro context in the background. It records the tester's actions (clicks, typing, navigation), network requests and failures, console errors and slow-performance samples. It also takes an environment fingerprint: the browser, window and machine the tester was using. When a finding is filed, that context is attached to it.

It's scoped to the testing. Only entries from the tab under test count, after testing started, on the application's own domain or the navigation path from there. Everything else is dropped (Not even sent to the server), we take privacy seriously. The in-page parts need one extra browser permission, called deep capture. The panel asks for it once and remembers the answer. If a tester declines, findings still file normally, with whatever the extension can see without it.

On the other side, whoever triages the finding sees a finding timeline. The tester's actions, page navigations, failed requests and console errors appear on one clock, so the finding reads as a single story.

What changes for the people triaging the findings

A session produces its best information while it's running. That's when the tester still remembers exactly what they clicked, and still has the page open.

With the extension, a finding doesn't wait for anyone to sort it. It's assigned the moment it's filed, following the session's assignment policy. By default, bugs go to the Test Manager, and questions and improvements go to the Product Owner. The finding arrives with plenty of detail: the tester's steps, a screenshot, and the repro context of actions, requests and console errors leading up to it.

So the person it lands with can act while the session is still going. They can walk over and ask for more details while they are both still in the session, still on the page, still in the flow. "Does it also happen when ...?" takes them a minute to try right now.

Compare that with exploratory testing done the traditional way, or a session run from a spreadsheet. Testers note their findings as they go and hand the list over when the session ends. Someone works through it hours or maybe even the next day. By then everyone is back in their inbox. The tester has moved on, the page is closed, and the details are half-remembered. A question that would have taken a minute during the session now takes an email thread — or never gets asked.

The side panel keeps everyone in the flow, and it keeps the conversation about each finding in the flow too.

"We don't want yet another tool"

It's a fair objection. Most teams already juggle a tracker, a chat tool, a CI dashboard and a test management tool. Here's what the extension does and doesn't add.

• It takes steps out of your workflow. Testers already have the browser open. The extension allows the capture panel in the browser window they already have open for testing, instead of in another window.
• It doesn't replace your issue tracker. Findings are triaged first. From there, a finding can be sent to Jira or GitHub through an issue tracker integration, and a session can send every new finding automatically if the team prefers. Developers keep working where they already work.
• It routes findings to the right person. With the default assignment policy, bugs go to the Test Manager, and questions and improvements go to the Product Owner. Nobody has to sort a pile of mixed findings by hand.
• Its permissions are opt-in. Screenshot capture asks for its browser permission the first time you press the button. Deep capture asks once in the panel. Declining either one doesn't stop anyone filing findings.

And because the panel does the busywork, a session doesn't need a specialist to run it. Whoevers involved in the change or new feature can explore it and log what they find. The capture step is the same for everyone.

Getting started

Install the extension, sign in, and open the panel on the application you're testing. Run one short session against a single feature. Log findings as you go, then open them in triage and look at what came attached.

If your sessions produce good findings but losing the thread afterwards costs testers their momentum, capture is the bottleneck. Sign up for the Allways Free tier (no credit card needed).