How to Perform QA on Your Mobile Data Collection App

Software testing and quality assurance (or affectionately, ‘QA’) is a world of its own these days. Big tech companies have teams of people doing only this, all day, every day – and we should thank them. Otherwise, the software we rely on every day would be considerably more aggravating.

Of course, this level of dedication is not the reality for most teams working with mobile data collection. As implementing staff at Dimagi, we are not only building apps, but also managing budgets and timelines, refining requirements, designing (and redesigning) features, working out a deployment strategy, supporting partners, working with users, and the list goes on and on.

So, we empathize deeply with you role-juggling app-builders out there: Everyone knows QA is important, but how do we make the time?

Thankfully, there are some systematic ways to make the process substantially less painful and time-consuming – without compromising the quality of your app.

Casual QA: Easy Tips You Can Try Today

The process of QA can be complex and take many iterations to perfect, but there are some simple things to keep in mind that will help it go smoothly.

Test as you go.

It might go without saying, but you should be sure that every change you make to your app works before you publish it. Yes, we ALL cut this corner from time to time. It’s the same deeply human impulse that pushes us to cross “clean front closet” off a to-do list when all you really did was shove your things into another closet.

App-building is a good opportunity to overcome this impulse. Build, test, fix, test, fix, test, test again, then publish. Saying, “We’ll catch it in QA!” and pushing testing off is NOT a good approach to developing apps – trust us, we learned that the hard way.

Submit a lot of forms. Now, submit more.

‘Exploratory testing’ – high-level testing of the app without a specific plan – is a process that should take place every day in your development process.

Making an end-of-the-day revision? Enroll a few test clients and take them through the forms you have been working on then take them through your older workflows too. It’s crucial to ‘zoom out’ to see how recent changes affect the rest of the app.

Got a few minutes of downtime? Get into the app and check out the weirdest edge cases you can think of. What happens when you submit a form as a pregnant male beneficiary? And if you’re used to testing on the desktop preview of your app, remember to spend time testing things out on the mobile device, too. Things can sometimes look very different, and you’ll catch many issues you might not have predicted.

Real QA: Rules to Live By

Getting your tool in the hands of the people who will use it is an important part of the QA process. Organize your approach to know exactly what you want them to test.

Build a dedicated QA period into your timeline – and hold yourself to it.

A classic tale of woe: Your timeline and budget were already tight, that last feature was more complex than you anticipated, and non-tech issues cropped up to derail you. You promised yourselves you would QA the app as soon as it was built, but….building never stopped.

When you lay out your app-building timeline, make sure to dedicate time for testing and bug-fixing. You may be able to get a simpler app to a high level of reliability in a week or two, but a complex one can take months to explore fully. If you are doing QA right, you should always feel like there is more to do.

Ideally, QA takes place just before user testing or deployment, at a time when the app is frozen for building and as many team members can jump in as possible. Having non-app-builders test is a great idea, too. A good rule of thumb is that whoever built the feature should not be the only one to test it in QA.

App documentation is life!

Writing test plans is hard. And time-consuming. And sometimes even boring! However, it is also vital to the success of your app. Before end-users start relying on it, you need a systematic way of assuring that your app does what it’s supposed to – you simply will not find all of the bugs with exploratory or ad-hoc testing.

The simplest key to making sure you do not forget important tests when conducting QA – and that you’re testing the right things – is to have clean technical specifications for your app, like workflow diagrams and models of your case structure. Invest time and energy upfront in some truly informative documents, ideally before you even begin designing and building your app. Then, when it comes time for that crunched QA you promised yourself, you can hit the ground running because you already know what to test. This documentation is especially helpful when you need to revisit this process later – for instance, when you introduce a new feature to your app.

The following is a bare-minimum short list of types of documentation, which can give you a great head-start on your QA process. You can work in design programs like draw.io, drop a bunch of shapes into a PowerPoint slide, or traditional pen and paper. Just make sure your docs are readable, shareable, and get saved somewhere for reference down the line.

For more information on designing the structure of your app and making great workflow diagrams, click here and here!

List of use cases:

Think of this as your end-users’ list of demands:

• “As a front-line worker, I need to register new clients and keep track of their age, address, and pregnancy status.”
• “As a midwife, I need to be able to know which of my clients have missed follow-up appointments and see them at the top of my visit list.”
• “As a supervisor, I need a list of all clients who have been referred to secondary facilities in the past month.”

These ideas may be scattered in different formats around your requirement documents, field notes, and design specs, but taking the time to list them out in this format BEFORE building both makes it very easy to test these capabilities during QA and ups the chances that you build the right functionality the first time around.

High-level workflow diagrams: 

Depending on the details of your project, these may be from the perspective of your user, your supervisors, or something else entirely. You may be mapping paths between forms within the app or real-life visits at different facilities. Whatever the specifics, it’s important to lay out complex processes visually before you get to building. Similarly to the list of use cases, your team and stakeholders will be aligned on the app before you build it, and you can easily leverage the pathways on these diagrams to create QA tests.

Case structure and case ‘states’:

Diagramming the ‘architecture’ of your app is essential. Before you can be sure it works properly, you need to deeply understand how it stores and transmits data.

Start with the case structure. At a high level, map out what case types you’re using and what their relationship is to one another (Parent? Child? Neighbor?). In a separate set of diagrams, think through where in your app these cases open and close, and the key list of case properties that most impact the workflows. To put it another way, which properties will have the worst effects if they’re not working right? Focus on identifying these, and you will know where to focus your QA.

For Your Consideration…

An application handles immunization for newborns, family planning appointments for female clients age 12 and above, and prenatal visits for pregnant women.

The registration form intakes clients of all ages and genders, opens a client case, and saves case properties to it: date of birth (‘dob’), gender, pregnancy status, mailing address, phone plan, and favorite food. Which of these case properties sounds most important to track in case diagrams and QA, given that it needs to identify which clients need which type of services?

If we later discover that the favorite food property is malfunctioning, it would probably have less of an impact on the app than pregnancy status. Think through these ‘pivot points’ in your app, and list out the case properties that define them.

It is a given that resources and timelines will always be tight, but prioritizing the components of your app will help you outline a QA test plan that will make the most of your time.

Make your test plan write itself

Once you start building your app, learn to rely heavily on the available tools, such as Case List reports. You will quickly realize how useful it is to visualize case relationships to see all the places they are affected.

If your documentation is exhaustive and up-to-date, you will find that QA tests start to generate naturally. Each one of those ‘As a _____, I need to _____’ statements is a test to run, custom-written for a test user.

Each one of those case opening/closing/pivoting points is a test, too, though it needs a bit more help and can be more subtle to troubleshoot. These tests will read more like: “Enroll a female client, age 28, who is pregnant. Search for her case on the case list report and verify that date of birth, gender, and pregnancy status are set correctly.”

QA is never over.

Though QA ‘cycles’ may end, QA is really a state of mind: Hold your applications to a higher standard by developing strong habits around testing as you build, even as early as the design phase. Your app is doing an important job, helping a frontline worker do hers. When you find bugs, it means she doesn’t have to!