Conducting effective exploratory testing is not everyone’s cup of tea. But that doesn’t mean you should shy away from it thinking it’s not yours or think that you’ll only be able to do it after you gain a lot of experience. As one of the top quality assurance companies, we have curated this exploratory test checklist from the vast experience we have gained over the years. We have always found exploratory tests useful in many projects as they help in spotting software errors that have flown under the radar of various test cases. So without any further ado, let’s take a look at the exploratory test checklist and then explore them one by one in detail.
Exploratory Test Checklist
- charter your exploration
- Don’t make your charter a test case
- Think from the user’s point of view
- Stakeholder interview
- Use time-restricted sessions
- Learning while doing
- Use the differences
- Create the appropriate documents
- mind maps
- List of defects and debriefing notes
- Console and records
charter your exploration
Exploratory testing can be compared to exploration tasks to easily get an idea of how to perform them. You can either walk around without any particular goal in hopes of finding something or you can start your quest with a goal in mind. Then, you have to plan a course according to the resources you have available to be more effective in your mission of exploration and finding the target.
Likewise, you can start by deciding what to explore (a specific unit, or the entire application). Then you can use resources such as testing tools, data sets, exploratory testing methods, etc. You need to be clear about your goal, an exploration session without any goal is not a good idea. So check if your goal is to test the application’s security, performance, or general testing.
The charter is not a test case
As I add more and more details to the charter, it becomes more and more of a test case. This is something that should be avoided at all costs. If your charter becomes like a test case, the point of doing exploratory testing will be compromised. But at the same time, you shouldn’t make it too vague because it wouldn’t be an efficient way to do exploratory testing.
Since charters will not have all of the expectations stated in an explicit way like a test case, you have to analyze and capture the implied expectations. For example, it goes without saying that a mobile banking app should have a secure login feature that only works if the correct PIN or password is entered. If this condition is not met, it should be explored even though it is not mentioned in the charter. You can call it a ‘never and always’ approach where every app should always be able to fulfill some functionality like providing a secure login and should never do certain activities like logging the user out every time the app is closed.
Put yourself in the user’s shoes
Since it can be difficult to balance the two for effective exploratory testing, the best strategy for not being misled is to test by putting yourself in the user’s perspective. User workflows are too diverse in nature to be covered only in test cases. With this approach, you will easily be able to go beyond just functionality testing and app usability testing with the help of effective user stories.
As we said earlier, exploratory testing makes it possible to discover potential future risks. Thinking from the user’s point of view will only solve half the problem. The other half can only be resolved when you have a conversation with stakeholders. Once you do this, you will be able to understand the application’s long-term vision, discuss priorities, understand stakeholder interests, etc.
Time-Boxing should be such an integral part of any exploratory exam checklist that even well-developed charters can allow you to go down the wrong path and waste your time without them. When it comes to the written test, we won’t be able to explore areas of interest right away. But here once we have an intuition or an inner feeling about a potential problem, we will have the freedom to explore it and discover errors.
But you have to understand that not every assumption you make may lead to bugs being discovered. So be sure to make time for your sessions so you don’t get carried away in the exploration process. As one of the best manual testing companies, we have found timeboxing to be very useful for our testing process. So if you are in a position to analyze exploration and test accordingly, it will definitely lead to good results. You have to be quick to learn and adapt your exams accordingly.
Learning while doing
Learning in action has made it to the test’s exploratory checklist as it is likely to be one of the biggest challenges you may face. A good exploratory lab will be proactive when conducting tests. Testers are used to seeing results that we hope you will see in most scenarios where you will have a well-defined test case. But in the case of exploratory testing, you’ll have to look beyond what you expect to see to see what’s really going on and discover hidden bugs that usually go undetected.
The more you understand the application, the better you can guide yourself through the exploratory testing process. Not only will you be able to discover errors, but you will be able to discover the root cause of such issues and find a set of interrelated errors. You should have an open mind while taking the exploratory test as rigid beliefs and generalized assumptions are traits you should stay away from.
Use the differences
Variations are an integral part of exploratory testing. It made its way into the exploratory testing checklist where you have to implement such variations based on what you learned on the go in order to be effective in exploratory testing. But there are some ongoing differences that you should look forward to covering. Let’s take a look at a little.
- CRUD – create, read, update, and delete are important actions that you should test whenever there is data involved.
- Starve the application of any information required to know how it handled the situation. You can also give partial or redundant information to see what will happen as well.
- Play with data formats and input speed to make sure things don’t go wrong.
- Centralization and decentralization of data or application configurations may also reveal undetected errors.
- Create intentional interruptions to troubleshoot various stability issues that may arise.
We can keep adding to this list, but we hope you get the idea. The truth to remember when it comes to using variations is that there are an infinite number of possible variations and it’s not possible to test everything. So make sure to explore the interesting stuff alone based on your target user base.
The purpose of any kind of testing is not just to identify errors. Instead, the goal is always to identify errors so that they can be fixed. This cannot be achieved without proper documentation as if you don’t document your test you will never be able to reproduce the error or even discover the reason behind it. So be sure to take notes and keep track of the steps you are taking as they will also be useful for reviewing and analyzing your exploration on a regular basis. Apart from that, you can use mind maps and use documents like consoles and logs to be more effective.
Mind maps are very effective in helping us connect the dots that we might fail to see. In addition to making it easier to recreate the bug or problem to fix it on others, mind maps will help you discover functional vulnerabilities. Since mind maps can be easily edited by adding or removing nodes, they will also fit the testing style used in exploratory testing. Mind maps are a great match for exploratory testing as one will be able to orient properly without needing a lot of information.
List of defects and debriefing notes
Knowing how much is enough is an important aspect of exploratory testing. So with the notes you took for your reference as you explored, you should create a list of defects to make sure that no flaw is overlooked. You should also create debriefing notes where necessary to help the team understand your approach, and take input from your actions.
Insert the selected test case
If we want to compare the exploration test with the exploration again, it is clear that we must trace the paths we have already taken. Likewise, once you find an issue when testing your app, make sure to add relevant test cases to it so that more testing can be done and avoid exploring the same path again. But that doesn’t mean you have to stop exploring the whole area. You just have to avoid the same path. Here the area is a comparison of the whole unit or feature and the path is the procedure you did to find the error.
keyboards and records
So obviously an app can only be described as fully tested if both regular testing and exploratory testing are completed. If this is done, you can be assured that your application has met the specified expectations and is free from any unforeseen obligations and risks. So we hope this exploratory test checklist will be helpful for you to get started and eventually become proficient in exploratory testing.