logo logo

How to Explore When There Is No User Interface

How to Explore When There Is No User Interface

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.

Cheat Sheet: How to Explore When There Is No User Interface

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! βœ…

Avatar

About the author

Paulo Oliveira

I’m a proactive, cooperative, and responsible Quality Assurance Engineer with more than 14 years of experience in software testing. I love to automate tests for all kind of applications (both backend and frontend) in order to improve the team’s workflow, product quality, and customer satisfaction. Even though my main roles were hands-on testing applications, I’ve worked as QA Lead, planning and coordinating activities, as well as coaching and contributing to team member’s development. Mentoring people to achieve their goals is also something that makes my eyes shine.

Website- https://paulocoliveira.github.io/qa/

LinkedIn- https://www.linkedin.com/in/pcesar/

Join TestProject Community

Get full access to the world's first cloud-based, open source friendly testing community. Enjoy TestProject's end-to-end test automation Platform, Forum, Blog and Docs - All for FREE.

Join Us Now  

Leave a Reply

popup image

API testing has never been easier

Explore this step-by-step guide to easily achieve flawless automated API testing flows, without any 3rd party tools and without a single line of code. A bunch of test examples are included!
Get Started
FacebookLinkedInTwitterEmail