Flurry of bugs

Recently I was doing some exploration around an area of a product. I didn’t have any specification or knowledge of the product, so it was an activity of learning how things worked as I explored. As I continued on a particular testing mission I observed one problem, then as I went problem after problem surfaced. We agreed as a team that we’d track issues in our ticket management system and for me, it started to become overwhelming. Logging all the issues, along with learning and exploration. My brain went into overdrive. One thing I started to do was record issues in the snipping tool video function. It took away the mental load of having to take time away thinking of the words to say to explain the problem, so anyone could understand. I feel this video recording is one that others should certainly explore.

I had to unfortunately pause my testing to work on some other things and one truth is that I actually didn’t report all problems that I noticed. It started to make me feel a little bit guilty and perhaps I was being a bit sloppy. However, when there’s that flurry of bugs, it might be because some bugs are the result of other bugs. A fix to one bug would fix all the issues. So in a way, it might be better that you in fact pause the testing — get the issues fixed and then continue the testing. This is what I decided to do. I will have to see if this was the right decision. I believe it was the right one at the moment in time.

What I enjoyed the most was exploring without any specification. Learning to see how things worked and questioning whether the expected behaviour was the expected behavior we wanted to see. This demonstrates to me what testing is all about. Learning, reporting observations and exploring whether there’s anything the team wants to change.