Get someone else to test for the tester. Anyone else! Anyone who knows how to use a device will do. Just to look at it from a new (different) angle.
Don’t get me wrong. Testing is not a skill that everyone has/can have. The idea here is to get someone to test it for the tester. By the end of this blog post, you will know what I am saying here.
Here is what happened:
My dev lead went on a week-long break, which means no new builds for 5 days. Hence, no checklists to follow while testing, no pressure to finish testing all the features on multiple devices within a small time and best of all, no stand-ups to attend.
I am working on testing the Android app of Townsquared, which is a well-known platform for local businesses. The app is in the early stages of development and a lot of new features (and bug fixes) keep coming in quite frequently. We follow a checklist to keep track of all the features and the different ways each feature can be accessed.
Android app testing requires you to test on multiple devices and multiple Android versions. Testing for the desired behavior on a number of devices and Android versions not only consumes a lot of time but sometimes also drains you of the creativity to look for unexpected behavior.
Although every once in a while, I do try to drift away from the checklist and play around in an attempt to stumble upon unexpected behaviors and staying more involved, I can only do so much within a specific time period.
Despite all the excitement of getting to freely play around the app, I got into the office on Monday and the Monday blues hit me like they do all human beings. Despite honestly trying to look for new stuff, I could only find very few bugs. That too, by exploring the things I already knew would cause bugs.
After some time, a colleague of mine came to my table and we were talking about random stuff. It was clear that she didn’t have a lot of workload so I decided to do this little experiment of getting her to test it. This is where the wonder began!
She works in the Machine Learning department and has no testing experience. I asked her to test the app for me. I gave her only a two line description about what the app is about and got her to explore. It took her 10 minutes to find about 5 ‘are-you-sure-this-is-how-it-should-be’s. She couldn’t tell how those issues would reproduce but she sure found unexpected (and most probably unwanted) behaviors.
So here is what happened: She looked at the app from a different angle. I might would have figured the same stuff out some time later but the advantage of getting a new person to do it is that it brings in a fresher perspective in a small time.
This small activity didn’t take too much time of the new person but it highlighted areas of the app that could have missed the spotlight for some or maybe a long time. I spent the next 90 minutes figuring out all the new stuff, finding related issues and concrete ways of reproducing the problems.
I repeated this little experiment with more people and received interesting feedback. One of them couldn’t get around the idea of actually ‘exploring’ the app. Another one pointed some things that would be more user-friendly if done differently.
This experiment turned out to be quite productive. It gets people involved, it brings in new ideas and all of it can actually save up a lot of time in the long run. This approach can be helpful in other areas too where whenever you’re stuck at a point, you can involve more people to get a look at it from their perspective and their ideas might help solve problems. It is especially useful in the quality assurance domain because you get many opinions before you release the product to the customer and a lot of problems can be caught and solved in-house.