Exploratory testing – the tester’s own arena
A few years back I was leading a project on a banking application under test. We had two tasks to perform, one was to test the enhancements developed by our dev team, but before that, the client wanted us to test the current application as he was not satisfied with the work from his previous vendor – and so that was the second task.
My colleague and I were busy in preparing the test plan and other things, so I asked another colleague, who was fresher, to do the exploratory testing. He spent around 1-2 days on the application and made some observations.
Every application from every domain is equally important, but when it comes to a banking application, then being a tester you need to keep an excellent eye on the application as it has so many calculations, taxes, transactions, third party involvement and different financial dues.
My colleague worked well, but later came to me and said he felt as though there were more areas he could have explored.
I have always noted that whenever exploratory testing is conducted, then all testers, mainly freshers, often have a negative approach. But this should not be so, as the aim of exploratory testing is to explore the site to discover all the functionalities, workflows, processes and their results, and thus exploratory testing often helps in finding more bugs than other methods; ultimately resulting in a higher quality end product.
Exploratory testing is not just a test of an application but a test of a tester, as he/she gets a chance to prove their domain knowledge!
So, let’s check the possible scenarios of applications which might come to you for testing, and your approach towards exploratory testing as a tester.
1. It may be a complete application which was developed previously: Here, with exploratory testing, one can understand more about the flows, processes and the way it was developed. This will help in making the application better quality, as an exploratory tester will approach things more thoroughly.
2. You may get a piece / module of application developed within your organisation by suggesting some other application / template: When the application is processing in your organisation then it’s always good to get a quick response on your observations and suggestions post exploratory testing. It can be beneficial for developers to develop the application in sync with suggested template and identified functionalities.
3. Undertaking product development for a target group / customer / domain: Yes! You are the right person to think in the manner of an end user, tester, domain, client or business group, and using this versatility, exploratory testing will prove to be an essential approach.
4. Application from a maintenance project: With any maintenance project there are tiny roles for every profile, as it’s almost a stable product. Still, if any enhancements, change requests or performance issues arise – then being an exploratory tester, you can explore the possible effects of any new development across the application.
5. An application developed from scratch and having proper documentation: If every requirement including software, business and system is properly defined then, by preparing the requirements traceability matrix (RTM), we can confirm the application development. Other flows with the combination of developed functionalities will form, so to check those flows and their effects on the application and business, exploratory testing is the perfect path to walk on.
Exploratory testing is a great methodology for any level of testing and tester, as it offers complete freedom to the tester. A software tester can do a lot here, and give his or her best performance, because it’s truly a tester’s own arena!
Advait Avinash Sowale is a test automation solution architect