I’m building a small local first Windows tool for working with image files, and I’m trying to understand this part of testing workflows better.
If you’re testing several bugs, features, or cases in one session, do you rename screenshots, move them into folders, attach them straight to Jira or another tool, or just rely on remembering what was what?
I’m especially curious about the parts that still feel annoyingly manual.
Hi,
Nice question. What i do is firstly assign in each bug a unique id. Then for each image i start by using this id and some first X words of bug’s title. For example Bug_id_001_button_overlap.jpg, Bug_id_002_Image_is_being_overlaped.jpg and so on.
Probably been asked before, and the answer, is probably still “with great difficulty”.
Simon P once wrote a nice app to capture testing sessions that did a pretty good job at keeping notes and screenshots in track. I think this is do-able, just requires notes and metadata timestamping capture.
For manual tests, I only worry about screenshots in case of a failure, in which case I attach the screenshot to the Jira I raise. For automated testing, I created a UUID for every component and included it in the screenshot filename. Even so, sifting through the log for a couple thousand tests run overnight and correlating failures to screenshots is far from painless*!
* I’ve been saying for some time that the predatory elation of finding a bug is surely an early career thing, given the effort involved in turning that bug into something useful to give to the developers (and I’ve put quite a bit of effort into making the tools to make that as easy on me as possible).
I so feel seen by this, when I was young, bugs gave me some kind of joy or power. Later on you learn not to get too excited.
The moment you start dumping screenshots into a local desktop folder, you’re setting yourself up for a mess. It’s much easier to attach screenshots directly inside your test management tool or execution log at the exact moment you run the step. If you’re doing exploratory testing, look for tools that let you attach media inline or auto-grab environment details with each capture. That way, the image is permanently tied to the specific build and test run, and you never have to play “guess which bug this screenshot belongs to” three days later.
Really? In 2026 we’re still discussing screenshot management? It’s monkey work that still eats time. No offense, just my take
I think, the fact that someone asked, is showing that there are 2 sides to screenshots.
People who screenshot tests results or bugs just because they got told to… and people who have to screenshot because a screenshot shows up CSS issues or for example when it’s a CAD application and impossible to describe 3D bugs without one.
It’s also conceivable that video is better, and a range of tools for that exist also. I screenshot a lot, for reference mostly, and I find the storage overheads are not really an issue. Sharing them however needs to be done in a way that does not tie you into a custom tool. When I used to do mobile work, I found iphones were especially easier.
Sorry, my first reply sounded sharper than I meant. Your CSS and CAD examples are good ones. I was thinking only about web testing, where bunch of extensions exist. For a desktop app like CAD or FPS they can’t work, so I see why this is still may be unsolved. How do you handle it?
This is interesting from the automated-testing side too
I hit the “which screenshot belongs to which run” problem building out a Playwright + BDD framework, and ended up solving it by tying the correlation to the run itself rather than to a naming convention.
Every run writes its report to a folder stamped by project + date + time, and never overwritten, and a failing step auto-captures a screenshot that’s embedded inline in that report right next to the exact Gherkin step that failed (not a separate pile of PNGs you have to go match up afterwards. So “which build was this from” is answered by which folder you’re looking in, not by parsing a filename.)
Doesn’t solve it for exploratory/manual sessions though
darth_piriteze’s UUID-per-component approach sounds like the more honest answer there, since there’s no “run” to hang the screenshot off of. (I’m new to this site)