Behind the scenes: A new tool to test FieldBuddy Swift

In this blog, we take a behind-the-scenes look at the FieldBuddy Swift development process. We recently developed a new tool to automate FieldBuddy Swift testing: FieldBuddy Test Automation. Curious how our developers developed this solution? Read all about it in this blog!

Every time a new FieldBuddy Swift version is published, our developers and testers need to perform regression tests on the application. These tests aim to check if everything that was working before the new version is still working on this one. This task is crucial as we always want to ensure that the new version is better than the previous ones! But as it can be quite repetitive and time consuming for our team, we decided to develop a new tool that can automate these tests: FieldBuddy Test Automation.

Choosing the adequate solution for automation: Appium

First of all we had to choose a solution that would help us to automate tests on mobile devices. We opted to use Appium for multiple reasons:
First, this tool allows our developers to write the tests in multiple languages including JavaScript, a language well known to our developers.
Secondly, by using Appium we knew that we could execute the tests on real devices for both iOS and Android and not only on emulators/simulators which was really important to us. As we would like to use this tool in order to test a wide variety of devices and versions, the solution we would choose should be runnable on a real device farm service provider. Appium complies to this requirement.

Once we knew how to run our tests, the next step was to define what we would specifically like to test. We wanted to perform regression tests that would (1) reproduce the regular use of a FieldBuddy Swift user, but would also (2) check if some errors are being well handled.

Reproducing the user behaviour

Concerning the regular use of Swift, the tests are doing the following tasks:

• First FieldBuddy Test Automation connects to Swift with a valid account: it clicks on the “Sign In” Button, enters valid credentials and then waits for the work orders screen to be displayed.

• After that the test creates a new work order: it clicks on the button to create one, then it assigns an account, a location and an installation to it. Finally FieldBuddy Test Automation checks if it is well created by going to this new work order.
• FieldBuddy Test Automation changes the status of the work order: it changes it to all the values available such as “arrived”, “in progress”, “on the road” or “open”

• An attachment is added to this work order: FieldBuddy Test Automation adds a picture coming from the library of the tested device.
• A timesheet line item is added to the work order: as the work order status has been changed earlier, a record has been automatically added to the work order when the status has been switched from “on the road” to “arrive”. FieldBuddy Test Automation checks if it has been well added to the timesheet line items, then we add another one manually. Finally it checks if both of these entries are displayed on the timesheet line items screen.
• Some other items are added as well: those items are parts, activities and other expenses.
• FieldBuddy Test Automation closes the work order: it switches the work order status to “closed”, after that all the steps required to close a work order (adding comments from a technician, adding a signature, etc…) are filled. Once the work order is closed, the work orders screen is displayed.
• FieldBuddy Test Automation logs out from Swift: it opens the drawer, clicks on the “log out” button and waits for the sign in page to be displayed.
  
  

Checking errors handling

As specified earlier, we also provoke errors on purpose to see how they are handled. Those errors are:

• Trying to log in to FieldBuddy Swift with an account that has no configuration assigned to it

:Missing configuration error message

• Trying to log in to FieldBuddy Swift with wrong credentials

:Incorrect credentials error message

• Trying to log out of Swift while there is no internet connection

:“Unable to log out” button

• Checking how a 500 error is handled by the application (a 500 error is an error coming from the server which means the problem is not coming from your device or your internet connection )

The tests reproducing the user behaviour are important because they let us know that the application still works correctly, so the user can continue to use it like he is used to. The ones provoking issues on purpose are also important because it is checking if the users are well informed about the error they are encountering.

FieldBuddy Test Automation in action

FieldBuddy Test Automation is a great addition to our current tools! As it is automated, our developers can run it in the background waiting for the tests results. Instead of manually testing Swift, they could use the time that is usually allocated to these tasks to continue to develop new features for FieldBuddy Swift.

NB: This project and this article have been made by Luc Gulden as some of the goals of his internship. This French student from the CESI Ecole d’Ingénieurs Strasbourg joined our team on September 28, 2020. He has been working on FieldBuddy Swift and FieldBuddy Test Automation throughout his internship that will end on February 8, 2021. Luc’s LinkedIn