Shifting to Remote QA and Dev: 3 Keys to Improve Testing Coverage and Efficiency

While many companies’ daily activities are being heavily disrupted by the global coronavirus crisis, there are ways for teams to take on the challenges that have arisen in the past few weeks. In the first part of this series, I addressed the different challenges that QA, engineering and product teams face when instantly switching to a remote setup. In this second article, I will focus on the impact that switching to a fully remote setup has on the achievable degree of quality across the testing mix, and provide valuable insights on how to make the best out of this new situation.

What impact does remote testing have on the testing mix?

To ensure quality, teams must get their testing mix right. Based on their level of maturity, teams normally work with a combination of exploratory, manual and automated testing. In our current global crisis, organizations leveraging test automation will start to heavily profit from it.

This is due to the very nature of test automation. Tests can be scripted and run off-premises, which means that they are not affected by the situation and can support a very high volume and standard of testing.

In the graph below, you can see how the share of different testing methods forming the testing mix typically evolves over time. However, it is important to highlight again that the level of maturity of your product and QA practices will greatly influence whether your company can truly benefit from test automation or not. Find out more about how to balance manual testing and automation by watching our webinar recording.

In addition, the current COVID-19 crisis impacts test cases themselves. You should still prioritize writing test cases so that the functionality matches the product team’s intent. Unfortunately, as mentioned in my previous article, the input — in the form of user stories and acceptance criteria — is likely less clear than in usual circumstances. Therefore, the QA team needs to spend more time verifying the builds and being more thorough.

In addition to being written and verified, the test cases that have not been automated also need to be executed manually. As I wrote in my first article, due to the strategy changing faster in these uncertain times, more app components and code areas will be touched, causing the regression suites to become bigger and therefore more time consuming. By making the extra effort of writing and executing these test cases manually, testers ensure sufficient code coverage.

At the same time, these efforts put on executing structured testing use up most of the available resources, leaving little to no time available for exploratory testing. Furthermore, structured testing is executed on the most common devices or on virtual machines. This leads to a reduction in the testing coverage of possible flows and devices.

Now is your time to strike back

Here are three ways you can fight back against some of these challenges while your team works remotely.

“If you fell down yesterday, stand up today.”

- H. G. Wells

1. Restore coverage by leveraging vetted testers who already work remotely

After falling down, your first step is to get up again. Your priority will be to restore your operational capabilities. As previously outlined, QA teams lack time and real devices to test on. What are your options?

Traditional offshoring may not work, for a simple reason: in most cases, vendors also rely on shared device labs and usually have equipment (desktop computers, etc.) installed. This means that the workforces are heavily impacted by lockdowns and cannot simply move to a home office setup.

In this case, having the established infrastructure of cloud-based crowdsourced testing capabilities comes in handy. Both exploratory and test case-based testing can be handed over to QA professionals around the world who use their own devices, and thereby enable your team to scale up. Find out how your company can benefit by tapping into a globally sourced community of vetted QA professionals, all of whom have been working from home for years.

2. Win time back by improving your communication

The second step is to start walking — and get better at doing so. You will achieve this by improving your teams’ communication skills. Here are some top tips to remember:

You’d rather over-communicate than under-communicate. Even if you think it may be too much, communicating more can help significantly reduce the workload, especially when it comes to user stories, sprint goals or even product vision/strategy.

Working remotely often means asynchronously. It’s fine to ask questions as they arise for you — just don't expect answers right away.

Align on some core hours when you’ll be “available” for questions and on maximum turnaround times that your peers can expect.

Update your peers more frequently about the status of your work or align on times to catch up again. This way you will not get interrupted as frequently.

Provide a more comprehensive documentation of bugs so that they are easier to reproduce by the developer alone. Remember that work is more asynchronous. At Applause, we typically provide screen recordings and highlighted screenshots attached to all functional issues as well as application logs where applicable.

3. Use this time to level up your processes

You're already back to walking. But if you really want to improve and speed up your processes, simply change the setup - take a car and get faster!

Indeed, the interruption of day-to-day operations evoked by the coronavirus crisis across the world may actually turn out to be an opportunity to use the idle time to improve your setup.

For example, here at Applause, we often execute test runs over the weekend to make better use of “idle time.” This helps ensure operations aren’t slowed down. Similarly, now that operations are interrupted and many projects are put on hold, you finally have time to assess whether you want to shift left and work on becoming more Agile, improve your engineering system by implementing selected CI/CD processes and tools, or fully move to DevOps. The choice is yours, the situation allows it!