EXPLORATORY TESTING – THE TESTER’S OWN ARENA!

By Advait Avinash Sowale

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.

Start by thinking about what your goals are as individuals and as a team. Is it to break software? To create bug-free software? To get paid? To create the next big thing? Writing down these goals will let you formalize them and communicate them clearly. You'll often find that the team's goals are very aligned, which starts to set the stage for a solid, trusting relationship. Everyone trusts that the team is working for the same goals.

 

Please login to comment
  • No comments found