Bumble Tech
Published in

Bumble Tech

Mobile test automation practices —
Part 2: preconditions, elements verification and independent steps

This is Part 2 of an article on the mobile test automation practices we use at Bumble Inc. In Part 1 we looked at the role of automation in our processes, gave details of the framework, and examined in detail three practices we employ when creating autotests.

  1. Practice no. 4. Verification of element state transitions
  2. Practice no. 5. Guaranteed preconditions setup
  3. Practice no. 6. Simple and complex actions, or Independent steps in tests
  4. Practice no. 7. “Optional” elements verification (which is mandatory to do 🙂)
  5. Summary
  6. Bonus.

Practice no. 4. Verification of element state transitions

This practice is probably one of the most important practices for mobile automation. This is because it is extremely rare to see static elements in applications that display on-screen immediately, and that are always accessible on-screen. More often we have a situation where it takes a certain amount of time to load elements.

Why we need our own bike/Why we didn’t go for a standard solution

When we began to build our automation framework we used a standard “wait_for” method to wait for elements to appear or change state. But then we ran into a problem. Sometimes, once every 2–3 weeks, our tests froze. We couldn’t understand how or why this was happening, or what we were doing wrong.

Element state transitions (various options)

Now let’s move on to the most interesting bit. Let’s talk about how to verify various state transitions, and which state transitions they are. Allow me to introduce our test object — the black square:

Should appear
Should disappear
Should not appear
Should not disappear

State transitions verification implementation

So, now we have identified all possible element state transitions. How can we verify them? Let’s review the implementation of options one and two first, and then — options three and four.

“Should appear” verification
“Should disappear” verification
“Should not appear” verification
“Should not disappear” verification


  • It is important to include all four state transition options when verifying UI elements
  • It is helpful to move this verification to a generic method.

Practice no. 5. Guaranteed preconditions set up

Task definition

As you can probably guess from the header, the task in this section is to explore how to configure preconditions before starting a test execution.

Examples of solutions

Here are two examples. The first is switching off the location service in the iOS settings. The second is generating a chat history.


We always recommend the use of guaranteed preconditions set up in tests by adding verifications that required actions have been performed successfully. This allows us to save the time usually needed to investigate test failures in those cases where setting preconditions has not worked since the test will fail immediately at the preparation stage.

Practice no. 6. Simple and complex actions, or, independent steps in tests

Simple actions

Based on the conclusions stated in the previous section, it might seem that we should add verifications, confirming that all actions have been performed in tests before moving on to the next actions. But in fact, this is not the case. In this next section, we will talk about implementing steps for various actions and verifications. This is a very general formulation that is appropriate for any step in our tests. For this reason, as usual, we will consider specific examples.

Sending GIF scenario
Step searching for a GIF
  1. First, we wait for the necessary page to open up (ChatPage)
  2. Then we save a list of all accessible GIF images
  3. Next, we enter a search keyword
  4. Then we wait for the list to update (after all, we said that it is useful to add verification that actions have been performed successfully before proceeding further).
  1. Saving the existing list
  2. Searching
  3. Verification that the list has been updated.
Sending GIF scenario

Complex actions

When we speak about complex actions we mean those actions which include transitions between different screens in an application, or the handling of changes in the state of any screen. Let’s consider such a situation, based on the example of voting in a mini-game.

Test user


We are creating independent steps for simple actions. This allows us to reuse/create scenarios faster and easier than if we needed to rewrite steps that are similar to one another. For steps for complex actions, we add verifications as to whether the action has been performed, before proceeding to the next actions.

Practice no. 7. “Optional” elements verification

By “optional” elements we mean those elements which could either be displayed or not on one and the same screen depending on certain conditions. Here’s an example with dialogues for user’s actions confirmation, or ‘so called’ alerts.

Examples of alerts

Task definition

Let’s analyse the screenshots above.

  • Screenshot 1: header, description and two buttons
  • Screenshot 2: header, description and one button
  • Screenshot 3: description and two buttons.

Examples of solutions

Let’s begin with how we call a method for verifying each of the dialogues:


We’d like to draw your attention to the fact that there is no such thing as “optional” verification but rather, there are “optional” elements — and all their states must be verified. Moving verification of the “optional” elements states to the shared method allows us to easily reuse it for various screens in the application.


To summarise, here are our key recommendations on mobile test automation from seven practices we have described:

  • Since verifications are the reason why we write tests, always use a full system of possible states
  • Do not forget to add presets verification for asynchronous actions
  • Extract shared methods for reusing similar code — both in the steps and in the methods on the pages
  • Implement simple test objects
  • Implement independent methods for simple actions in tests.

A little bonus

We have prepared a test project where all the practices described in this article are represented. We encourage you to follow the link, study and apply them: Mobile Automation Sample Project.



We’re the tech team behind social networking apps Bumble and Badoo. Our products help millions of people build meaningful connections around the world.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store