Even as governments slowly start to loosen coronavirus restrictions around the globe, many businesses will continue to have their employees work remotely. That means QA managers have to build a testing plan and strategy that can be executed while testers work from home.
This has been a significant transition for some organizations, particularly those that lean on an in-office device lab or have tight collaboration between the product, engineering and QA teams. Working remotely has the potential to disrupt that collaboration and slow down the speed of development. If you’re fueling a CI/CD pipeline, that could be especially damaging.
We asked our Test Engineers, who are responsible for building testing plans for our remote testing teams to execute for our customers: How do you build a testing plan that QA testers can smoothly execute remotely? Here are their answers:
Don’t short-change QA’s time with dev
Find a way to keep the QA teams and developers in sync on an ongoing basis. As Test Engineer Matt Shipps points out, one of the major advantages of an in-person testing team is the ability to show discoveries to developers or designers (or someone else, as necessary) as they happen, and get the opportunity to troubleshoot in a hands-on, immediate way.
That becomes more challenging when everyone is working remotely, but it’s not impossible.
“Being able to see the error as it’s happening isn’t always necessary, but sometimes it’s invaluable for identifying the root cause,” said Shipps, who’s based in the United Kingdom and has extensive experience helping to strategize and execute testing plans remotely. “In an all-remote environment, this is simply not possible, but that doesn’t mean it can’t be worked around. Having a way for testers to screen-share with developers can sometimes be almost as good as seeing the issue live in person, and may help to convey more information than a screenshot or a video could.”
Take advantage of being remote
Testing outside the office can present communication challenges and limit a tester’s ability to access a device lab — but it also offers an opportunity to better replicate your end-users’ experiences.
When you test in an office or a device lab, that is often a sterile and pristine environment. Testers do not have to account for poor WiFi or how the user experience or functionality might suffer when the user is leveraging an app while in a car or sharing WiFi with other users. You can only account for this with in-the-wild testing — and testing remotely makes this possible in a way that an in-office environment can’t.
“Testing remotely will, in many cases, create a much closer testing environment to what an end user will be experiencing,” Shipps said. “Every location is different — it may lead to discovering some issues that otherwise would have been missed due to factors such as poor connectivity, different network configurations (e.g. firewalls, different router configurations), security software, or unusual mobile considerations, like lower speed connections, or connections that frequently switch between carriers’ networks due to proximity to towers. These are all real-world scenarios that aren’t likely to come up in an in-office testing environment, but it’s almost a guarantee that some subset of end users will encounter them.”
Create a device plan
Testing with an in-office device lab is one of the biggest challenges for teams that are now all-remote.
“You need to properly plan how you will cover any testing requiring specific devices to test — be it a mobile phone, computers that employees usually use on-site, or physical devices that are prototypes of the final product,” said Patryk Raba, a Test Engineer based in Poland.
For companies that are keen on using the devices that they have already purchased, teams could explore lending them out to remote testing and ensuring that they are disinfected each time the device changes hands. But this is not a scalable or time-friendly solution, and could in fact be costly in the long run with device wear-and-tear.
Applause’s Test Engineers, including Shipps and Raba, make it a full-time job to build testing plans that the Applause global community of vetted QA professionals can execute testing on. That community tests in the same environments as end users, and has access to an endless combination of devices and OSes to test on. If you have questions about how to build a testing plan remotely, reach out and ask our team of experts.