Curious: Is there a better way to capture steps during manual testing?

Discussions
, , , ,
1

Hi everyone,

I’m trying to understand something about exploratory testing workflows, and I would appreciate some perspective from people with more QA experience than me.

Lately, I’ve been noticing how much time gets spent capturing steps, screenshots, network info, etc. during manual testing. I started wondering:

How do experienced testers handle this efficiently?
Do you rely on tools, shortcuts, browser extensions, or just good habits?

This led me down a rabbit hole where I experimented with a small script that observes interactions during a session (clicks, navigation, delays, etc.). It’s very rough, and I’m not even sure if I’m approaching the problem the right way.

Before I go any further with it, I wanted to ask the community:

  • Is “documenting as you test” actually a major pain point, or just part of the job?

  • Are there tools you already rely on that solve this well?

  • What should or shouldn’t be captured during exploratory testing?

  • Are there privacy or accuracy concerns I might not be considering?

  • If you’ve ever tried tools that auto-record or observe sessions, what worked or didn’t?

I genuinely don’t know if this is a meaningful problem or a misunderstanding on my part, and I’d love to learn from people with real QA experience.

Thanks in advance to anyone willing to share how they think about this.

2

What is the intent behind recording your steps?

I don’t record every step along the way but it is important to note what tests/experiments I’ve performed so that I can discuss if I feel like I’m missing something or when a bug escapes, I can see exactly what I did. Quite often I’ll include screenshots just to “prove” that I’ve seen the expected behaviour and I’ve found it useful to note down test data used, such as the names of a user account that I created, any interesting observations (especially weird log messages).

There’s definitely times when I’ll either be writing down my steps or recording myself. For example getting reproduction on a bug or when it is REALLY important that I know what I did when. However these detailed notes / longer recordings aren’t stuff that I intend for others to read. It is my notes / recording to help myself. If I want to share something, I’ll usually re-write or re-record to get something nice and focused.

It is worth calling out that to me there is a difference between the notes that I may take along the way and what goes in my test report.

3

Thanks! Spot on - except on special tests where the bug is very subtle and not easily seen.
I have a tool that does something like:
so if i miss anything, i can always check

image
image2864×1710 386 KB

4

I usually just run a screen recording with the snipping tool (in Windows) and talk through what I’m doing, what I clicked, what I’m trying to achieve, and any observations along the way. I’ll pause the recording to jot down rough notes about what I’m doing, but only enough to avoid doing the same things twice. If something odd happens, I can replay the video to see exactly what occurred, which makes it much easier to replicate issues. If needed, I can also share the video with a developer.

I rarely keep the recordings because of the storage limitations, the main purpose is to avoid those moments where you think you saw the software behave a certain way but can’t quite remember the steps.

I’m just starting my “learning how to do testing properly” journey, so there’s probably a better way but I’ve found that recording my sessions has been really helpful. Perhaps it’s something everyone is already doing.

5

Your workflow (screen recording + talking through + rough notes + replaying when needed) is actually something I’ve heard from a few other testers too, especially early in their careers.

6

Hey, I echo @oxygenaddict ‘s question: What are you trying to achieve by recording all the steps?

To me, documenting exploratory testing shouldn’t mean creating a script for someone to repeat exactly, every single thing you did. But it is important for them to know what you tested, and how. A subtle, but important distinction.

  • Is “documenting as you test” actually a major pain point, or just part of the job?

    • Learning what to document in your context is something that comes with practice and experience; when you get it right, the benefits should outweigh what is hopefully a low pain

  • Are there tools you already rely on that solve this well?

    • Rather than recording steps, I take note of scenarios / cases / journeys / flows; I often include screenshots and, when it’s hard to describe, short videos using the Awesome Screenshot browser extension

  • What should or shouldn’t be captured during exploratory testing?

    • Should: Information that would be useful to your intended audience, be that developers, product owners, stakeholders, auditors, or even your future self; think about why someone would read your test documentation, and what would help them - you can always ask them directly too, you don’t have to guess
    • Shouldn’t: ET documentation definitely shouldn’t turn into a glorified test script writing session, nor should it be so detailed and verbose that it’s hard to digest / extract value from

  • Are there privacy or accuracy concerns I might not be considering?

    • I like that you’re asking this kind of question
    • I think any privacy concerns would come down to how, and to who, you’re making your documentation accessible, and what sensitive / production data you may be including within
    • Not sure what you mean with accuracy concerns; documentation should always be accurate, but that doesn’t necessarily mean covering every detail / step

  • If you’ve ever tried tools that auto-record or observe sessions, what worked or didn’t?

    • I’ve never had the need to record an entire ET session, outside of training purposes; even then, it would be done live with someone / people, and recorded more for reference; I wouldn’t record a “normal” ET session, but I might make short videos to show issues, as mentioned above

You might want to check out some blogs I’ve written on (documenting) ET: Exploratory Testing Archives - Cassandra HL

In particular, How to Document Testing with SBTM: Testing IRL Part 2 | Cassandra HL and SBTM in Practice with PQIP | Cassandra HL

7

Documenting tests can be tricky! Some use tools or extensions, others just take notes, depends on what works best for you.

8

I never had much issues with documenting as I test. Working on software with a lack of documentation it wasn’t that clear what should happen before I started anyways. Usually you get a feeling over time what you need to record for yourself so you remember what you did and can answer questions about coverage.

Several times I did regret not recording though as I couldn’t recreate weird behaviour afterwards. Without the recording I couldn’t fully retrace my steps and had no proof.

9

Thanks MoTs,

Seems we all go with what works for us. I am a big fan of proper organization. I prefer to have my tools in a place where I can launch and do stuff at a go, i.e. something that can do the screen capture, create narrative steps, generate clean bug report, and I can just send to Jira once verified. Again considering the time, pressure from Product team, not to talk of work volume. Having one tool that do all those will save me time. If I am facing such a situation, I consider tens of others facing same.

A user on X once mentioned, the fact that he has to write down steps, monitor logs, network activities and do the tedious work of QA pisses him off. He is a founder, and was looking for a tool he could speak into and it does the magic, generate a rich report for his QA sessions, so he can just at a click send to Linear. I agree QA might not be his daily work.

Personally, I am experimenting with a script that takes my work further, saving me some time. I think of having a screen recorder, capture, a session recorder that records only my actions in real-time. I did write some python script + rust, ran it, and it is doing exactly as i wanted (don’t think anyone will penalize me for that). The goal is to deliver quality much faster without loosing context.

I found some interesting metrics while running the script:

I just summarized those into a dashboard and monitor my session.

2025-12-04_16-40
2025-12-04_16-401126×1350 112 KB

It gives me better insights into what other QA might not look into, and I learn more technicalities. The workplace is highly competitive now. For those who do more of UI testing, it’s sometimes boring like that guy said.

Are there any legal or ethical issue with using the script for my work? Please do let me know

10

I come at exploratory testing without following anyone elses guidance on what is good exploratory testing. However, when it comes to documentation, (I know, I’ve mentioned this before and I’m going to mention it again :laughing: ) but I’ve found nothing more powerful than using a PQIP sheet. The document is not about what you did, but its all about what you find.
Ironically, we had an hour long time boxed PQIP session yesterday on a feature, recorded our findings. After the session finished we went through each category:

  • Problems - most likely to be bugs. Try to reproduce them and if you can, document your bugs well. If you can’t, don’t…how likely are they to reoccur if you can’t find them? But make a note its an area you may need to explore again
  • Questions - do you need to document them or just ask them? Do you need to document the answers, if so where? In additional tickets, test cases etc.?
  • Ideas - the majority of what we find here is ideas on how the product could be better, but not exclusively. Those ideas we hand those over to the product manager to make the call whether to add them to the road map. Also, we’ll have testing ideas, maybe areas we think would be ideal to automate. So documenting a test case would be useful so its clear what we need automating.
  • Praise - well that doesn’t necessarily need documenting, but it does need communicating. If there are good practices going on shout about them and keep moving forward with them. If there are great features shout about them so the whole team can get behind the roadmap.

So in summary, we don’t get preoccupied with documenting what we did, more what we found. Then taking what we found and documenting what we need to document.

11

Thank you Gary. Those are gems!

12

this is a real pain point.

i don’t think the answer is “record everything.” that usually turns into another pile of video nobody wants to scrub through.

the valuable version is capturing the minimum useful proof:

  • what path was taken
  • what the browser saw
  • what changed in the app
  • what network/console clues matter
  • what someone else needs to replay or inspect it

i think manual/exploratory testing has a handoff problem more than a note-taking problem.

if the artifact is too thin, devs ask for repro steps.
if it’s too heavy, nobody opens it.

the sweet spot is a replayable test artifact that carries the bug, the context, and the evidence without making the tester become a documentary filmmaker.

13

May I suggest AI and dictation?
I found that chatgpt is really good at dictation and notes building. The posibillities are endless with how it can be setup to generate your steps.

14

In my experience, documenting during exploratory testing is definitely one of the more time-consuming parts of the job. I don’t try to capture everything. I focus on the information that will actually help someone reproduce and understand the issue.

I usually capture the key user actions, test data, environment details and screenshots or console/network logs only when they add value. The rest comes from good note-taking habits and experience.

I do think there is an opportunity fort AI here. Rather than recording every click, I would prefer a tool that understands session, identifies the important events, and generates defect report or draft summary report. for testing team members to review. That would let testers spend more time exploring application and less time in documenting it.

Curious to see what approaches others are using in enterprise environments.

15

Like Richard, I’m not a fan of starting any kind of manual testing with no goal other than the raise bugs. When I take notes I’m also never wanting to make notes for someone else to follow. I want the next tester to use their initiative, something that is lost if you did a screen-recording. All the happens is the next test iteration will see a tester searching high and low for a 8 gigabyte flash-drive identical to the one I used. I’m with Jonathan, teach people how to test properly, don’t leave detailed notes. Customers never follow the user manual and customer will always use a 2Gigabyte flash drive that was formatted FAT instead! boom!

Cassandra is , as always, able to take us to a point in the landscape where we can see the long view. What are the outputs from this session you want to keep for years to come? And so maybe to think of every test session as exploratory is not a bad thing if all it does is stop you from recording in high detail.

My brain does 2 things when I do manual testing, but before I start I write a shingle short paragraph describing why I’m doing this and how long I’m prepared to spend doing it. I call it a “charter”. It’s like a task: “I’ve been asked to sail the ship out across the Atlantic and back to see if it leaks or runs out of gas. I’ll be done this time tomorrow!” When as I sail I am checking that we have no leaks or bugs and that everything works, but as I go I’m also literally doing tiny little risk assessments and running every heuristic I know of. My favourite is CRUD (Create/read/update/delete) there are many more of them that I won’t check in the voyage, but I’ll write them all up on paper as I go for later. It will be crazy things like the 2 gigabyte flash drive that is formatted in an unexpected way. I add those all into a jira backlog and forget about them because the charter is to check the ship for leaks and fuel consumption. If I were to capture all the steps I would not have time to make a note that if you happen to sail near to the Caicos, Antiles, Bahama islands or the coast of Puerto Rico. Because those are not good places to sail to at certain times of the year. But at certain times of the year you want to test a thing you could not do today, like for example if it’s the week when daylight saving changes for the UK but not for the USA. It’s not worth recording a trip to the Bermuda Triangle, but if your brain is applying the heuristics, it will come to you. You certainly would never test that or even report it at all in your expense claims, because sipping pina coladas is not a thing you can fit into a 1-day test anyway. Capture in the report what matters now, and capture on paper what matters later for later. That’s probably how most of the pro bug-finders do it. They certainly never follow the user manual nor our pretty test-plans.

16

You’ve named the split that matters: not “record everything,” but capture the
important events and generate a draft for review.

The part I’d watch is that review step. A generated summary is only useful if
someone can trust it without redoing the work — otherwise you’ve traded
documenting-as-you-test for correcting-the-AI-afterwards.

What earns that trust, for me, is when the report sits on top of a deterministic
capture underneath: the exact actions taken, plus the API/network behavior
behind them. The summary is the readable layer; the replay is the proof. A dev
can then act on it without asking for repro steps.

On your enterprise question — does a generated summary get accepted on its own
there, or does it still need something replayable behind it before a dev (or an
auditor) trusts it?

17

@probe_runner You ended on exactly the question that matters: does a generated summary get accepted on its own, or does it need something replayable before a Dev – or an auditor – trusts it? Let me answer from the regulated end, because it flips the whole calculus.

I spent over 8 years in HIPAA-regulated pharmacy healthcare QA. There, your notes aren’t only for the Dev beside you or your future self – they can become audit evidence. Someone may need to reconstruct, perhaps two years later, not just what you found but that you looked, how you looked, and when you looked – and defend it to an auditor who wasn’t even in the room.

That changes “how much to document.” “Teach people to test, don’t leave detailed notes” is excellent advice for a fast-moving product Team – and genuinely wrong for a validated medical or fintech product, where traceability is the deliverable. The charter/SBTM discipline still applies; you just also owe a provenance trail.

So, to your question directly: no, in that world a generated summary isn’t trusted on its own. It’s trusted when it sits on a record someone can reconstruct – which is really a question of who has to trust this, and how far in the future. A note-to-self, a Dev repro, and an auditor’s evidence are three artifacts with three unique shelf lives.

Curious how others handle the regulated/audit end of this – it’s the corner the “just enough notes” school (which I love) doesn’t quite reach.

18

This reminds me of tools like jam . The tool does a job of automatically capturing session replay, console logs, network requests, browser details, and reproduction steps, which significantly reduces the effort of creating bug reports.
Where I think there is still room for innovation is around exploratory testing. During exploration, my biggest challenge isn’t remembering what I clicked, it’s remembering why I chose a particular path. My decisions are driven by observations, risks, and hypotheses that emerge while testing.
A recording can tell me what happened. It rarely captures what I was investigating.
If a tool could combine automatic interaction capture with lightweight annotations, for example, I changed the payload here because I suspected a validation issue or I switched workflows after noticing inconsistent state, it would preserve not only the evidence but also the tester’s reasoning.
For me, that would be much more valuable than a perfect click-by-click replay.

19

Not a fan of calling exploratory testing manual but maybe what I’m experimenting with currently might be of value. The core reason for me for exploratory is that there are unknowns in play and that’s what the focus is, discovering, “exploring” and investigating those.

So for web testing I’ve been pairing with goose and playwright_cli and giving it full access to code.

We start by modelling risk and generating a few risk charters/hypothesis for investigation. This will involve research and establishing a few risk oracles and heuristics to leverage from, I’ve found the back and forth via goose very useful for this. Not only intent but risks to that intent, the latter makes it exploratory and not intent on it’s own.

On the investigation itself I interchange with two approaches, 1) goose connects to application I investigate and it tracks and gives visibility on things I may miss, it as full access to everything dev tools has but can be more focused, this is almost business as usual. 2) I assign investigations to goose guided by not only intent but by risk so its focus is to find things I do not already know, this requires loops but I’m close enough to add critical thinking between loops if needed.

This model also allows data creation on the fly, access to code so code level risks investigated and importantly it goes straight into root cause and fix recommendations. I’m not ready to allow it to fix directly yet but its going that direction.

I have not tried asking it to replay exactly what I did, with unknowns value lies in variation not repeatability with the exception of STR’s. I suspect it could do this and create a video if really needed, I have not seen that as a value add thing yet.

At the end of the session its a one liner to get documents and tickets created, risks covered, level of investigation, issues found, interesting things that are worth discussing, opportunities for improvement and recommended fixes. Stay close enough to avoid creation of noise.

I feel I gain a lot without losing much at all provided I stay at the helm.

Once you get a feel of it you can often create skills and recipes for different risks, like a specific skill for accessibility risk or a tailored skill for the way you want reporting or ticket creation done and share these across your team for consistency whilst still allowing for highly empowered individual testing which exploratory testing really benefits from.

Maybe worth me posting some slides on this approach in it’s own right.