A day in the life of a mobile app tester

A few days ago I posted on LinkedIn that I have hardly written any test automation code in the last year:

And I had a few people ask, “how do I test during a code review?”. So I thought I would dive deeper into what an average day for me looks like.

My Role; Software Engineer in Test

Officially my role is a Senior Software Engineer in Test on a mobile app team, it’s a little like this role description but with a mobile app focus instead of a C#/web focus. So why am I not writing test automation code? It’s there in the job description.

Checking Jira

I’ll start my day by checking our scrum board for our current sprint and figuring out what my focus is for the day. What tasks have been assigned to me and what needs some focused testing:

Here’s a rough cadence of sprint meetings, you can read more about what these meetings involve in my mobile app test strategy blog:

Check’in out the Code

Next I’ll usually update my local code to include recent changes, if the dev work was merged in recently it can be tested. This is the git command I’ll usually run to get my local up to date:

git checkout develop && git pull project develop && git push

I use git to help me with large code reviews. The developers will create a pull request with their new feature. I’ll check that code out on a local branch and use Xcode/Android studio to test that code on emulators/simulators. I’ll often use this git command to do so:

git fetch project pull/{pr_number}/head:{pr_number} && Git checkout {pr_number}

I’ll explore the new feature and pass the code review. I’ll chat with the developer if there were any issues observed. I might even run the tests they’ve created as part of that pull request.

I don’t do this for every code review, if it’s a small change I’ll approve it and once it’s merged into the main dev branch I’ll update my local to test those changes. Then I’ll test on emulators/simulators or I’ll wait for our continuous integration (CI) testing pipeline to produce an app file and test on devices.

Android Emulators

I have an emulator for every supported android version, for really important features (i.e. a 3 star feature based on my risk analyst) I’ll test it on every emulator:

I have a similar set up for Xcode, we are in the process of dropping support for iOS 11 because we’d also like to update Xcode.

Backend Testing

I also sometimes checkout backend code but my work machine isn’t set up to be able to build our back end locally. I’ll usually use a test environment to test API’s via Postman or cURL.

Helping with unit testing

I’m more likely to help the developers I work with come up with unit testing strategy. E.G. we were working on a feature recently to add up transactions over the last financial year and we have over 100 different transactions types.

We came up with an approach, if we give every transaction it’s type as it’s value we can more easily check the sums invoved. E.G if one category to calculate was:

transaction type2 + transaction type3 - transaction type1 

we could say we’d expect the unit test result to be $4 (2+3-1). We created the mock JSON that went into the unit tests and it really helped the developer figure out how to test this more easily.

Supporting the App

I helped my team build out a mobile analytics dashboard where we could monitor user engagement and any potential issues that needed more investigation. Recently I’ve be checking it nearly every day and helping my team add more sections because we’ve got an SSL certificate issue at the moment.

We release our app monthly and we’ve got 7 versions that our customers can be on. We have a force update API that the mobile app will hit before it starts the log in process. If a user is on an unsupported version they can’t log in and are directed to the play store to update.

BUT this API uses HTTPS and our production SSL certificate expired recently. We haven’t built certificate white listing yet so it means instead of the old app seeing a forced update, they see a generic error message instead because the SSL certificate has expired. Oops, our bad.

We were able to get 98% of our regular app users onto the latest build with the latest SSL certificate but people who log in infrequently would not have seen the forced update. We are monitoring for an increase in generic error messages and hoping that no one gives us a poor review on the app stores.

I have a crash course in SSL certificates if you’d like to read more.

Building our mocking framework

Most of my code changes involve adding mock JSON data to our mobile app mocking framework. We can test our mobile app independently of any test environment. It’s a really cool feature that I’m proud of our team for building it.

We have a bunch of profiles mocked into the test build of our app. E.G if you wanted to see the difference between a pensioner vs investor you can change the profile in the test build.

Our whole business has access to this test build to help the company support the app (not every staff member has an account to use the app with). Sometimes these mocks need updating. As a team we’ve discussed a programatic way to keep these profiles up to date but it’s a little hard and hasn’t been prioritised.

If we are working on a new feature and I’ve recently been testing the API, I’ll often add the API mock test data into our mobile repositories ahead of the mobile dev work to make that process easier.

User Research

Recently I’ve been branching out and helping the design team with competitor analyst and research for new features we are working on. For example, how do other mobile apps handle two factor authentication?

Running a bug bash

every few sprints I’ll book the team in for a bug bash. It’s dev tools down and bug hunting goggles on. I’ll organise some snacks and a confluence page of test data and information about what has changed recently to help people focus on what to test. We award our best bug bug hunter for their efforts and add bugs found to the backlog. You can read more about running a bug bash here. We try to keep it fun and social.

Summary

So yes, I haven’t written much test automation code and this is ok. The developers I work with are great at writing their own unit and integration tests. Does this make my work any less valuable? No.

I enjoy engaging with customers and analytics more than building out test automation code. If you are interested in learning the technical skills that I use on a day to day basis, I have a technical testers guide here.

What are your thoughts on this way of working?