When we think about exploratory tests, a frontend application comes to mind with several fields to fill in and buttons to click on, where we can explore in several different ways. However, all types of software can be exploratory test targets, even with no user interface 🎯
In this article, we will present two cases of systems that don’t have a frontend screen but can (and should) be the target of exploratory tests: an embedded fiscal print system, and API software. The idea of this article is to open your mind to new possibilities, thinking outside the box.
Case 1 – An Embedded Fiscal Printer System
Imagine that you are part of a software development project for a fiscal printer (those printers that we can find in stores) and you need to test it. You don’t have a screen, and the only interface you do have is the printer’s hardware. How would you explore it?
First, look at the printer’s structure. Usually, a fiscal printer is composed of:
- 1 energy cable
- 1 network cable to connect it to a computer
- 1 paper roll compartment
- 1 button that opens the paper roll compartment
- 1 ON/OFF button
In addition, if you are testing the printer’s system, you will have access to the compartment where the printer’s physical memory is allocated, which contains the printer’s firmware.
Let’s think about the functionality of issuing a fiscal coupon for the printer as an example. It can be sent to it using another software, and with everything we have available we can think of several test scenarios.
In order to be more organized, let’s divide the test scenarios into sections of the available resources:
📍 Energy Cable
Check the fiscal coupon emission:
- With an energy cable
- Without an energy cable
- With a damaged energy cable
- While removing the energy cable during the coupon emission
📍 Network Cable
Check the fiscal coupon emission:
- With a network cable
- Without a network cable
- With a damaged network cable
- While removing the network cable during the coupon emission
📍 Paper Roll
Check the fiscal coupon emission:
- With a full paper tray
- With a paper tray that’s almost finished
- With an empty paper tray
- Without a paper tray
- With a paper tray in an inverted position
- While the paper tray’s compartment is open
- When opening the paper tray’s compartment during the coupon emission
📍 ON/OFF Button
Check the fiscal coupon emission:
- With the printer ON
- With the printer OFF
- While turning it off during coupon emission
📍 Firmware
Check the fiscal coupon emission:
- With a valid firmware
- With a corrupted firmware installed
- Without a firmware installed
- With a damaged memory slot
- With an incompatible memory slot
- Without a memory slot
📍 Combinations
Check the fiscal coupon emission while combining some states in the suggested scenarios.
After this brainstorming, we can see that we have several possibilities for testable scenarios. If we combine the possible states to each of the resources, we expand the possibilities even further.
In addition, we know that a fiscal printer has several other types of documents that can be printed, which expand to a few hundred possible scenarios that can be tested.
Case 2 – Exploratory Tests for an API
Imagine that you are part of an API software development team. You don’t have a screen, and the only interface you do have is a tool like Postman, where you can send requests to the APIs. How would you explore it? 🔎
First, you can look at the structure of a rest API that is composed of:
- A verb (most commons ones are GET, POST, PUT, PATCH, DELETE)
- A URL
- Query parameters
- One or more headers
- A JSON with data to send in the request
Thinking about the responses of an API, we can complement our resources with:
- A status code
- A response body
- One or more response headers
Analyzing this common structure of a rest API, we can think of several test scenarios. In order to be more organized, let’s divide the test scenarios into sections of the API structure:
📍 Verbs
Check the API behavior using:
- The GET verb
- The POST verb
- The PUT verb
- The PATCH verb
- The DELETE verb
📍 URL
Check the API behavior using:
- Valid URL
- Wrong URL
- Invalid URL
📍 Query Parameters
Check the API behavior using:
- One query parameter
- All possible query parameters
- Invalid query parameters
- Invalid values in query parameters
- No query parameters
📍 Headers
Check the API behavior using:
- All necessary headers
- No headers
- Invalid headers
- Invalid values in headers
📍 Data
Check the API behavior using:
- Valid data
- Invalid data
- Extra data
- Different data types
- Badly structured data
📍 Status Code
Check the API behavior while making the API response a:
- 200 – OK
- 201 – Created
- 202 – Accepted
- 204 – No Content
- 400 – Bad Request
- 401 – Unauthorized
- 403 – Forbidden
- 404 – Not Found
- 405 – Method Not Allowed
- 502 – Bad Gateway
- 503 – Service Unavailable
- 504 – Gateway Timeout
📍 Response Body
Check the API behavior when the API:
- Should not return a body
- Returns success and should return values in the body
- Returns failure and should return error information
📍 Response Headers
Check the API behavior when the API:
- Should not return headers
- Returns success and should return values in headers
With the brainstorming done in this section, we can again verify that we have a lot of testable scenarios to explore API services.
Tips to Perform Exploratory Tests With No User Interface
Let’s discuss 6 tips that will help you when you’re thinking about exploring a system without a user interface:
1️⃣ Look Into the Structure
What is the structure of the system you are testing? Is there any kind of physical structure? What are the available resources?
2️⃣ Look for Inputs
What are the inputs of the system? Are there any kind of buttons, cables, fields, connections?
3️⃣ Look for Input Possibilities
To each identified input, what are the possibilities? Press, remove, change, use invalid things, damage? How can you vary the states of the input?
4️⃣ Check Valid and Invalid Values
What are the possible valid and invalid values to each input?
5️⃣ Understand the Technology
What kind of system are you going to test? Do you understand its technology? Research, discuss, and explore it to understand better.
6️⃣ Combine Inputs
Are there any inputs that can be combined to obtain a different output? Which ones? Which kind of combinations can be done? Do you have enough time to explore all of the combinations? Can you prioritize them?
Tips Cheat Sheet
This a great summary with all the tips that have been given in the previous section 💡 It is a quick-access resource that you can use every day, whenever you need to think about exploratory tests scenarios.
Conclusion
Most people always think that exploratory tests can only be done in a system that has a user interface. But it is totally possible and I encourage you to use it. You can use test strategies like exploratory testing for all kinds of software, so take advantage of it! ✅