Sometimes, you can find yourself testing something very new, and very big. Perhaps there are lots of people working on something together for the first time, not many specifications around, a number of potential ideas and directions, new technologies and/or a host of other things. This doesn’t necessarily mean something is wrong – it’s just how things are.
As such, one might expect there to be a lot of issues, and again that’s not necessarily a surprise, it’s just a natural transition phase from “nothing” to “something” and as testers we’re here to help with that. Issues in this sort of project could really be anything, from personal preference (stylistic), to font colours (accessibility), buttons not doing anything (functional) to out of memory errors (maybe stop-ship).
As well as being a rather special opportunity, it can pose some particularly interesting challenges to a tester. For me, it can throw a few out of memory errors in my own head.
With so much information flying around – and I’m not even talking about the stuff beyond the issues – it’s hard to keep track of them through a sort of observe, record, report, discuss, prioritise, review and verify process even when it’s just your own things, let alone all being aware of those from anyone else on the team (not just testers).
There are also risks that you’re swamped with observations and don’t report them all. Perhaps you’re duplicating issues others have already raised. Maybe it’s taking so long to officially report things that you’re getting behind on the testing and giving quick feedback to the developers.
Some tactics have worked well, whether they’ve been deliberately implemented or arrived at naturally over time. For example, rather than raising everything as a separate bug, issues can be recorded under a single bug, each issue with its own unique Id. The advantage is that these can be concise, thus quicker, and means less time is spent on paperwork/red tape and more time on finding, recording issues and giving timely feedback. It can also mean that more things are recorded, as even the self-prioritised low priority trivial stuff can be noted quickly, and might be perceived as a higher priority by someone else.
By having the issues in fewer places and with less to read, it can also help with getting a good overview of what the issues are. That’s good for both avoiding burning time investigating something that’s already been investigated, but also gaining an appreciation of the product as a whole – which areas aren’t as stable right now, where haven’t we looked for a while, etc.
There are risks too though, and some of their effects we can minimise. Tracking these multiple issues in one place requires a degree of care to make sure everything is fixed or gets preserved to be addressed later on. I’m particularly keen to make sure that the time we’ve put in to find these things isn’t wasted by losing the issues somewhere along the line, however important they’re currently deemed to be.
It also needs some consistency in how they’re handled (e.g. unique Id creation scheme), discussed and prioritised. It also really helps when everyone else is on board with the approach too – for example, having a developer enumerate an issue list and report back status on them all separately is a wonderful help.
Also, being concise can cause some details to be lost and/or misunderstandings. It’s good to accept that and be understanding of each other when it happens. If the reproduction isn’t clear, add more details (e.g. a screenshot) until it is. If there’s a lack of a common language to write things concisely, work at creating one and get everyone involved so there’s both some spread of knowledge and agreement.
So, how does this particular tactic help with my memory issue? By having this system in place, it’s possible to keep more on top of a constantly fluctuating (status and issue creation/resolution) situation, rather than having it run away into a set of issues that can’t be easily tracked, nor quickly parsed, nor fully appreciated. I’m also less concerned about trying to keep too much in my head at any one time, when I have faith in a system that’s working well.