The Conclusive Exploratory Testing Checklist to Follow

Performing effective Exploratory Testing is not everybody’s cup of tea. But that doesn’t mean you have to shy away from it thinking it’s not for you or thinking you’ll be able to do it only after gaining a lot of experience. As one of the top QA companies, we have curated this exploratory testing checklist from the vast experience we have gained over the years. We have always found exploratory testing to come in handy in various projects as it helps unearth the software bugs that flew under the radar of the various test cases. So without any further ado, let’s take a look at the exploratory testing checklist and then explore them one-by-one in detail.

The Exploratory Testing Checklist

• Charter Your Exploration
  • Don’t make your Charter a Test Case
  • Think from the user’s perspective
  • Interview the Stakeholders
• Using time-boxed Sessions
• Learning while Executing
• Use Variations
• Create proper documentation
  • Mind Maps
  • Defect list and Debriefing notes
  • Console and Logs

Charter Your Exploration

Exploratory Testing can be compared to exploration missions to easily get an idea of how to execute it. You can either wander around without any particular target with the hope of finding something or you can start your mission with a target in mind. You then have to plan a course as per the resources you have at your disposal to be more effective in your exploration mission and find the target.

Likewise, you can start out by defining what to explore (a particular module, or the entire app). Following which you can utilize the resources such as testing tools, data sets, exploratory testing techniques, and so on. You should be clear of what your target is as an exploration session without any target is not a good idea. So be sure of whether your objective is to test the app’s security, performance or test it on the whole.

A Charter isn’t a Test Case

The more and more details you add to a charter, the more and more it becomes like a test case. And that is something you should avoid at any cost. If your charter becomes like a test case, the point of performing exploratory testing is compromised. But at the same time, you shouldn’t let it be too vague as it’ll not be an efficient way of doing exploratory testing.

Since charters will not have all the expectations mentioned in an explicit manner like a test case, you have to analyze and pick up implicit expectations. For example, it goes without saying that a mobile banking app has to have a secure login feature that works only if the correct pin or password is entered. If that condition isn’t fulfilled, then it has to be explored even though it isn’t mentioned in the charter. You can call it the ‘Never and Always’ approach as all the app should always be able to achieve a few functionalities like providing a safe login and should never do certain activities like sign the user out every time the app is closed.

Put yourself in the User’s Shoes

Since it can be tricky to strike the balance between the two extremes to perform effective exploratory testing, the best strategy to not go astray would be to test by putting yourself in the user’s perspective. User workflows are so diverse in nature that they can’t be covered in just test cases. With this approach, you will easily be able to go beyond just testing functionality and test the app’s usability with the help of effective user stories.

Interview the Stakeholders

As we said earlier, exploratory testing makes it possible to detect potential future risks. Thinking from the user’s perspective will solve only half the problem. The other half can be solved only when you have a chat with the stakeholders. Once you do that, you will be able to understand the vision for the app in the longer run, discuss the priorities, understand the concerns of the stakeholders, and so on.

Time-Boxing

Time-Boxing should be an integral part of any exploratory testing checklist as even your well-developed charters can let you go down the wrong road and waste your time without it. When it comes to scripted testing, we will not be able to explore areas of concern immediately. But here once we have a hunch or a gut feeling about a probable issue, we will have the freedom to explore it and detect the bugs.

But you have to understand that not every assumption you make might lead to the detection of bugs. So make sure to time box your sessions so that you don’t get carried away with the exploration process. As one of the best manual testing companies, we have found timeboxing highly beneficial to our testing process. So if you are in a position to analyze your exploration and test accordingly, it will definitely yield good results. You have to be quick to learn and adapt your tests accordingly.

Learning while Executing

Learning while Executing has made it to this exploratory testing checklist as it is probably one of the biggest challenges you might face. A good exploratory tester will be proactive when performing the tests. Testing is accustomed to seeing the results we’d hope to see on most scenarios as you’ll have a well-defined test case. But in the case of exploratory testing, you’ll have to look beyond what you’d expect to see to find out what is actually happening and unearth hidden bugs that would usually go undetected.

The more you understand the app, the better it will be for you to guide yourself throughout the exploratory testing process. You will be able to not just detect bugs, you will be able to detect the root cause of such issues and find a cluster of bugs that are interlinked. You’d have to have an open mind while performing exploratory testing as rigid beliefs and generalized assumptions are traits that you should steer clear from.

Use Variations

Variations are an integral part of exploratory testing. It has made its way to our Exploratory Testing Checklist as you’d have to implement such variations based on what you learn on the go to be effective with your exploratory testing. But there are a few constant variations that you should look to cover. Let’s take a look at a few.

• CRUD – Create, Read, Update, and Delete are important actions you have to test with whenever there is data involved.
• Starve the application of any required information to see how it handles the situation. You can also give partial information or excessive information to see what happens as well.
• Play around with the data formats and speed of input to ensure things don’t go wrong.
• Centralizing and decentralizing the data or configurations of the application might also reveal undetected bugs.
• Create intentional interruptions to explore the various stability issues that might arise.

We could just keep adding to this list, but we hope you get the idea. The fact to remember when it comes to using variations is that there are an infinite number of possible variations and it is not possible to test everything. So make sure to explore the interesting ones alone based on your targeted user base.

Documentation

The purpose of any type of testing isn’t just to identify bugs. Rather, the goal is always to identify the bugs so that they can be fixed. This cannot be achieved without proper documentation as if you don’t document your testing, you will never how to reproduce the bug or even find out the cause behind it. So make sure to take notes and keep track of the steps you take as it will also be useful in reviewing and analyzing your exploration on a regular basis. Apart from that, you can use mind maps and use documentations like consoles and logs to be more effective.

Mind Maps

Mind maps are very effective in helping us connect the dots that we might otherwise fail to see. In addition to making it easy for others to recreate the bug or issue to fix it, mind maps will help you detect functionality gaps. Since mind maps can be easily edited by adding or removing nodes, they will also suit the testing style employed in exploratory testing. Mind maps are a great match for exploratory testing as one will be able to be guided properly without needing too much information.

Defects list and Debriefing notes

Knowing how much is enough is an important aspect of exploratory testing. So with the notes you have taken for your reference during your exploration, you have to create a defect list to make sure no defect gets overlooked. You must also create debriefing notes wherever necessary to help the team understand your approach, and take input from your actions.

Inclusion of Identified Test Case

If we were to compare exploration testing to exploration again, then it’s obvious that we should keep a track of the routes that we have already taken. Likewise, once you have found an issue when testing your app, make sure to add relevant test cases of it so that further testing can be done and avoid exploring the same route again. But it doesn’t mean you have to stop exploring the entire area. You just have to avoid the same route. Here the area is a comparison to the entire module or feature and the route is the action you performed to find the bug.

Consoles and Logs

Consoles and Logs are the other warning systems that can help you analyze the inner workings of a system and bring unnoticed errors to your notice. They are a great way to understand the structure of the app which in return will help you attain the required insight to detect internal issues that might go undetected. You have to ensure that your logs don’t get too lengthy by filtering them out smartly. Let’s take a look at an example to get a clearer picture. If you are testing a web application, you should keep track of the JavaScript console, the webserver log, and the application log to detect any anomalies.

Conclusion

So it is evident that an app can be termed as completely tested only if both regular testing and exploratory testing have been completed. If that is done, you can be sure that your application has met the defined expectations and is free from any unexpected liabilities and risks. So we hope this exploratory testing checklist of ours will be helpful for you to get started and eventually become proficient at exploratory testing.