There is No User Interface – how to explore?

A frontend application is what comes to mind when we think of exploratory tests. It has many fields and buttons that we can click on to explore the software in many different ways. All types of software are possible exploratory test targets, regardless of their user interface.

This article will show you two examples of systems without a frontend screen that can be (and should) be the targets of exploratory testing. These are an embedded fiscal printing system and API software. This article aims to expand your thinking and allow you to think outside of the box.

Case 1: An embedded fiscal printer system

Imagine you’re part of a software project to develop software for a fiscal printer. The only interface you have is the printer’s physical hardware. You don’t even have a screen. What would you do to explore it?

Take a look at the structure of the printer. A fiscal printer usually consists of:

  • 1 energy cable
  • 1 Network Cable to connect it with a computer
  • 1 roll of paper
  • 1 button to open the paper roll compartment
  • 1 ON/OFF button

You will also have access to the area where the printer’s physical memories are allocated. This compartment contains the firmware.

As an example, let’s consider the functionality of issuing a fiscal voucher for the printer. You can send it to it with another software. We have many test scenarios.

Let’s make it easier to organize the test scenarios by dividing them into sections based on the resources available:

Energy Cable

You can check the fiscal coupon emission.

  • An energy cable
  • Energy cable not required
  • A damaged energy cable
  • During coupon emission, remove the energy cable

Network Cable

You can check the fiscal coupon emission.

  • A network cable
  • Without a network cable
  • A damaged network cable
  • During coupon emission, remove the network cable

Paper Roll

You can check the fiscal coupon emission.

  • A full-sized paper tray
  • A paper tray almost done
  • A empty paper tray
  • A paper tray is not necessary
  • Inverted paper tray
  • The compartment of the paper tray is not closed.
  • During the coupon emission, open the compartment in the paper tray.

ON/OFF Buttons

You can check the fiscal coupon emission.

  • The printer ON
  • With the printer OFF
  • During coupon emission, turn it off


You can check the fiscal coupon emission.

  • A valid firmware
  • Installed corrupted firmware
  • Without a firmware installed
  • A damaged memory slot
  • An incompatible memory slot
  • Without a memory card


You can check the fiscal coupon emission by combining certain states in the suggested scenarios.

This brainstorming reveals that there are many possibilities for testing scenarios. The possibilities are even greater when we combine the states possible for each resource.

We also know that a fiscal printer can print many other types of documents, which can expand the number of possible scenarios that can all be tested.

Case 2: Exploratory Tests to an API

Imagine you’re part of an API software team. There is no screen and you only have a tool called Postman to send API requests. What would you do to explore it?

You can first look at the structure and components of a rest API.

  • A verb (most commonly GET, POST or PUT, PATCH and DELETE).
  • A URL
  • Parameters for queries
  • Headers
  • A JSON containing data to send the request

We can supplement our resources by thinking about API responses.

  • Status code
  • A response body
  • One or more response headers

We can see several scenarios when we look at the common structure of a Rest API. To make things easier, let’s break down the test scenarios into sections within the API structure.


You can check the API behavior by using:

  • The GET verb
  • The POST verb
  • The PUT verb
  • The PATCH verb
  • The DELETE verb

You can check the API behavior by using:

  • Valid URL
  • The wrong URL
  • Invalid URL

Query Parameters

You can check the API behavior by using:

  • One query parameter
  • All possible query parameters
  • Invalid query parameters
  • Invalid values in query parameters
  • No query parameters


You can check the API behavior by using:

  • All headers required
  • There are no headers
  • Headers not valid
  • Invalid values in headers

You can check the API behavior by using:

  • Valid data
  • Invalid data
  • Extra data
  • Different data types
  • Poorly structured data

Status code

When you are getting an API response, make sure to inspect the API behavior

  • OK – 200
  • 201 – Created
  • 202 – Accepted
  • 204 – No Content
  • 400 – Bad Request
  • 401 – Unauthorized
  • 403 – Forbidden
  • 404 – Not Found
  • 405 – Not allowed
  • 502 – Bad Gateway
  • 503 – Unavailable Service
  • Gateway Timeout – 504

Response body

You can check the API behavior when you use the API:

  • Do not return a corpse
  • The body should have a high return on its investment in success.
  • Failure to return information and returns

Response Headers

You can check the API behavior when you use the API:

  • Not to return headers
  • Success in returns and the return value of headers

We can confirm that there are many scenarios we can test to explore API services by using the brainstorming we did in this section.

Tips for Exploratory Tests Without a User Interface

Let’s talk about 6 tips to help you explore a system without an interface.

1 A Look at the Structure

How is the structure of your system? Does the system have any physical structure? What are the resources available?

2 Search for Inputs

What are the inputs to the system? What are the inputs of the system? Are there buttons, cables or fields?

3 Search for Input Opportunities

What are the possible outcomes for each input? You can remove, modify, use invalid items, or damage each input. What can you do to change the state of an input?

4 Valid and Invalid Values

What are the valid and possible invalid input values?

5 Understanding the Technology

Which system will you test? Are you familiar with its technology? To understand it better, research, discuss, and investigate it.

6 Combine Inputs

Is there any way to combine inputs to get a different output? Which ones? What combinations are possible? Are you able to take the time to try all possible combinations? Do you know how to prioritize them?

Tips Cheat sheet

This is a summary of all the information from the previous section. It’s a resource you can access every day whenever you have to think about exploratory test scenarios.


Many people believe that exploratory tests must be performed in a system with a user interface. It is possible, and I encourage you use it. It is possible to use exploratory testing as a test strategy for any type of software.

Leave a Reply

Your email address will not be published.