Contact us
Contact
Blog

Development

9 min read

How to Start Testing Bluetooth Apps: A Beginner's Guide

Katarina
Katarina
QA Engineer

Testing Bluetooth apps can be challenging, especially if you’re a beginner in the world of quality assurance – trust me, we’ve all been there. Bluetooth is one of those technologies that seem very simple from a user perspective, but in reality, it’s often more complex. And wherever there’s complexity, there are also more chances something might potentially go wrong. This is why I decided to write this guide. Continue reading and learn everything you need to know about testing your first Bluetooth app.

But first, let’s talk about preconditions

Before you start the testing process, I suggest you learn all about the Bluetooth device you’re going to work with. First, cover the basics: What’s its purpose? What will it be used for? Afterward, you can dive in a bit deeper and learn more about its behaviour:

  • how to turn it on/off
  • how to start its main functionality
  • how does the firmware behave in certain circumstances
  • which data does the device collect and store
  • what can you do with the device
  • which requirements and needs have to be fulfilled for a successful running

After answering these questions, you will officially have a solid knowledge of the Bluetooth device you plan to test. Now, what exactly does the testing part include, find out below. 

First steps when testing your Bluetooth app 

1. Pairing & connection 

Every Bluetooth device has its own way of connecting to the app. Some of them connect automatically and the connection just stays alive. But there are also Bluetooth apps that require specific pairing to connect to the Bluetooth device. Once the pairing is complete, the user can easily connect their Bluetooth app to the device, provided they turn on Bluetooth on their device, of course.  

Once you start testing, watch out for:

  • the app’s behaviour when you accept or decline all the permissions needed for a successful connection with the Bluetooth device (e.g. iOS requires permission for using Bluetooth, while Android requires permission for using location)
  • the app’s behaviour when you try connecting more smartphones to the same Bluetooth device
  • the app’s behaviour if you have more than one Bluetooth device near your smartphone

The last two points can be especially tricky. For example, you want to connect your Bluetooth device to a particular smartphone, but you have opened the app on more than one device – there’s a high chance of every smartphone nearby trying to connect to it. A similar problem appears when you open the app on just one device but have more Bluetooth devices laying around. This is the part when the smartphone goes crazy because it doesn’t know which Bluetooth device to connect to. 

Do you know how many times I accidentally connected the Bluetooth device I was working with to the wrong smartphone? Too many. And let me tell you one thing, it’s not the most exciting part of the job to search for the phone that’s connected to the Bluetooth device – especially if you work with 10-15 testing devices on a regular basis. But what can you do. 🤷‍♀️ 

2. Distance between the Bluetooth device and the app

I’m sure you’re aware of the impact distance between a Bluetooth device and an app has on the quality of the Bluetooth connection. There are going to be times when the user won’t be able to use the app and the device at the same time. That’s why it’s important to test how the connection will work when the smartphone and the Bluetooth device are not next to each other. 

3. Firmware of the Bluetooth device

One of the biggest challenges was working on features related to the firmware of the Bluetooth device. It all started with the first firmware update, when some features that were working perfectly before, just stopped working or changed behaviour with the new firmware version. This was the moment I realized how complex Bluetooth testing can be. It's also when I recognized the importance of regression testing –  if I didn't conduct it every sprint I wouldn't have even noticed the difference in the developed features after the firmware update. 

If your app has a “firmware update” feature, don't forget to take care of:

  • the download time – how much time does the download take 
  • what happens if the connection breaks while the download is in process
  • update time – how long does it take until the update is finished
  • what happens if the user closes the app during the update process (funny story - I once bricked a Bluetooth device while testing this case)
  • clearly describing the steps for the wanted user group
  • how does the frontend communicate with the backend when showing that a new firmware update is available, and how the data is shown in the app

It’s important to put yourselves in the user’s shoes when testing the firmware features – because if I managed to brick a Bluetooth device simply by closing the app in the middle of an update, then any user could do it. To elaborate… The old firmware version got deleted at the same moment I started the installation of the new version, which first led to an error and then bricking the Bluetooth device. Of course, this was unacceptable so we searched for a fix. And we found one! Now, if the user closes the app while the update is in progress, the app will find the bricked Bluetooth device and start the installation of the new firmware version again.

I’m mentioning this because this situation led me to one of the most important lessons in testing – different platforms, software versions, and devices communicate differently with the Bluetooth device. I faced scenarios where on a Samsung, everything would work perfectly, and then on Huawei, the same feature I tested before, would not work. Thereby, when you start testing, keep in mind to use as many devices and cover as many software versions as possible. And do it on every platform that supports the app. 

Picture of Katarina Đurđević sitting on her desk
Hi, that's me. Casually testing. They caught me totally off guard.


4. Data collecting and storing 

Data collecting and storing is one of the basic functions of every app – that implies Bluetooth apps, too. When testing data collecting and storing, keep in mind:

  • should the data be permanently stored or not
  • if there is no permanent storage, how long will the data be visible in the app
  • will the user have an option to choose if he wants to store the data or not
  • how should the data be displayed in the app
  • is the collecting done in real-time or will the data update be done after a specific amount of time

These are just some of the generic cases you should test when we talk about data collecting and storing in the Bluetooth app, but, depending on the app expectations, there can be even more things to test.  

5. Communication between the app and the Bluetooth device

Bluetooth communication is one of the most important functionalities to test in your app. If the communication doesn’t work, then the app probably doesn’t fulfill its purpose. That’s why you need to test:

  • is the communication fluent or not 
  • will the communication break after some time or not 
  • will the app features work as expected with the Bluetooth device
  • what happens if the communication breaks while the Bluetooth device is running and showing some data in the app

How Bluetooth testing improved my testing skills

Testing Bluetooth apps can be challenging at first, but the benefits you get out of it are worth it:

  1. You will learn how to deal with projects of larger complexity
  2. You will become a true team player
  3. You will deal with every new Bluetooth project with more ease

When testing Bluetooth apps, it’s important to stay organized and to accept help when needed – some things will be new to you. That way, you allow yourself to grow and you'll be able to improve your testing skills. But hey, reading this article is already a step in the right direction. Technically, you’re ready to test your first Bluetooth app. Congrats! If you run into any questions, feel free to contact me. 🤗 

Like what you just read?

Feel free to spread the news!

About the author

Katarina is a Quality Assurance Engineer at COBE. Besides testing apps and writing bug reports, she is a huge fan of Harry Potter books and movies.

Katarina

QA Engineer

Write
Katarina
Write COBE
Related Articles

Still interested? Take a look at the following articles.