Testing or Quality Assurance or QA as we call it, comes in different shapes and sizes (or to be technical – in different forms and varieties) and one size does not fit all. There are different type of applications, web developments happening across the world that one type of QA practice cannot be deemed fit for use for everything. But wouldn’t it be great if as a QA, we had the freedom and the luxury of time to sometimes think out of the box and not just go by the stricter structured methods and techniques of testing and QA’s could just play around with the uniqueness and functionality of an application for a bit.
Well, it did come across other genius minds as well, and hence the concept of “Exploratory Testing” was introduced, a term coined by – Software Testing guru ‘KEM CANER’ in 1983.
What is Exploratory Testing?
Exploratory Testing has its context hidden in the name itself, which means – to explore. ‘KEM CANER’ very famously quoted that – “No matter how many test cases of how many types you have created, you will run out of formally planned tests and you can still keep testing. Run new tests as you think of them without spending much time preparing or explaining the tests. Trust your instincts.”
Unlike the other structured testing techniques, here in Exploratory Software Testing type, testers do not have to create Test Cases in advance or have them well-manicured and scripted and documented in order to perform but rather it allows them to be more inquisitive, trust their instincts and become more confident, which as a result enhances performance as well as quality of the developed product. However, we could of course write down some ideas and brain dumps to have a little idea of what areas we want to touch upon or revisit. It can also be in a way called as – Scriptless Testing as we are not following any hard and fast scripting protocols here.
Structured Testing vs Exploratory Testing –
|Structured Testing||Exploratory Testing|
Importance of Exploratory Testing –
Customers today have the luxury of choosing from a plethora of options and then deciding wisely as to what they want to invest in and what not. So from this vast range of options, how we can have a loyal client base is by offering a superior quality product and a quicker delivery of the finished product to the market.
In the times when the organizations follow the Continuous Integration/ Continuous Delivery approach just to stay at the top of their game, it is all the more essential to keep up with the different testing techniques to maximize the test coverage and avoid the expensive bugs to be found out at a later stage, as insufficient or low quality testing can lead to dissatisfied customer as well as financial strain.
Even though the traditional structured testing techniques are great to ensure maximum test coverage and well-suited to most of the applications but sometimes testers are able to find bugs that could otherwise remain undiscovered by just performing tests on the fly rather than following scripts, only on the basis of their instincts, gut feeling or in some cases experience in the trade. Also, exploratory testing allows us to be freer to find bugs rather than confining us to merely follow a sequential document.
The best part about exploratory testing is that anyone can perform it, even the new joiners in the team who might not have much information and knowledge about the application yet. This allows them to be a team player and allows them to become more confident and imbibes into them a feeling of being responsible towards success of application.
How to perform Exploratory Testing?
Exploratory Testing is beneficial to every type of application, but it is much more followed in Agile-based models. There are several steps that can be followed to perform exploratory testing like –
- Classification of Bugs – It can be done by categorizing the defects found in other similar types of applications and identifying their root causes, as sometimes one cause is responsible a number of identified defects. Classification of bugs will help with prioritizing the areas that need to be tested more thoroughly.
- Test Charters – Creating of test charters help with identifying the areas for testing, define starting point for testing.
- Time Boxing – It’s quite a similar concept to that of pair programming, the difference being that here instead of coding, two testers work together for 90 minutes or more to test the responsiveness of application.
- Review Results – We can analyze the application, the defects and learn from defects raised previously in order to find out the weak points in the application.
- Debriefing – Here we can compare the results and compile them and use them to find out if we need more testing to be confident about the test coverage and its quality.
Challenges faced while performing Exploratory Testing –
- The first and most important issue that the QA’s face in this form of testing is the replication of defects and scenarios.
- Testing of an application without any prior knowledge can be a bit challenging.
- Automation Testing does not readily support Exploratory Testing as there are no defined cases and scripts written which have to be followed and tests are being performed on the fly.
- It is sometimes difficult to document the whole scenario that has been identified as a failure.
- It is difficult to figure out as to when we can stop the testing and declare the test coverage to be done or complete.
- Logging these defects is difficult as there are no defined scripts and steps being followed.
It is always a good practice to think differently and out of the box when working as a QA and be more creative with testing techniques and implement different strategies as and when they think necessary.
Exploratory Testing is more of a hands-on approach and helps find out the defects that might not be discovered via a structured format. Although we cannot utilize it to a 100%, but we should try to utilize the potential of Exploratory Testing to the fullest and reap it’s much underrated benefits.