With 70% of the world’s workforce working remotely at least one day per week and 98% of workers stating that the ability to work anywhere positively impacts their performance, the future of work is looking more distributed than ever.
A distributed workforce is a modern one. It includes inhouse office workers, as well as remote employees, contractors, vendors, and agencies. In other words, it’s the total of the strategic and agile combination of resources that the organization needs.
Although distributed work does present organizational challenges to agile software development, there are plenty of advantages too. A remote, distributed team of quality assurance testers can help engineering teams ship updates faster than a QA team that works out of a single office.
In this post, we explore five key ways that distributed testing speeds up product releases.
1. Evening testing
With distributed testing, testers are often in multiple time zones. Of course, your team could be distributed across a single time zone, but for large organizations making strategic use of the global workforce, this is unlikely.
When working in different time zones, it’s easier to deliver test results faster. For example, Strava uses Testlio to get testing achieved within 48 hours. This speed is partly due to a global network of testers that can test during different time zones. Strava delivers the release on a Wednesday and receives the results on a Friday. That level of speed wouldn’t be possible if all of the testers were in one location.
2. Weekend testing
Time zones come into play on the weekend too. It is possible to get QA done over the weekend. If you work with employees and individual contractors, they might not be easily persuaded to test releases over the weekend.
However, with advantageous time zones, it can still feel like your team is testing on the weekend, even if they’re not. Let’s say that your QA engineer, who lives in California, delivers the release to your testers, who live in Israel, on a Friday afternoon. The testers can test on Monday and Tuesday, and the QA engineer can get results back on Tuesday morning. He’s only waited for one workday, instead of two.
While time zones can work in your favor with a distributed in-house team, it’s most convenient when working with a testing vendor that taps into a professional, global network of testers.
3. Realistic localization testing
If you have high-quality standards for localization testing, you need a distributed QA team (unless you want to risk slowing things down).
Localization testing often includes these key things:
- User interface
- Application’s language support
- Localized hardware compatibility
- Cultural appropriateness
- Typographical errors
- Address formats and date formats
- Hotkeys, text filters, and other technicalities
When you combine the depth and breadth of localization testing with several different markets (each with their own cultures and dialects), you’re left with a very complicated testing cycle.
There are two dangers with having a testing team that exists in one location. First of all, there will be an issue of speed and capacity to handle the localization quality requirements. Secondly, you’re far less likely to have testers who are genuinely knowledgeable in every key culture or language all in a single office. They might be checking off the basics without knowing the nuances of spelling, appropriateness, and various other expectations.
On the other hand, with a distributed testing team, you gain real localization from native speakers – and you also achieve this in less time because people can be testing simultaneously across various time zones.
To learn how this works in practice, read how an eCommerce giant maintains a 4.9+ app store rating by conducting localization and payments testing throughout the world.
4. Unique skills and responsibilities
Companies with distributed workforces tend to be more creative and adaptive. Because they require increased operational and partnering agility, they have a good handle on which roles need to be in-house to be successful and which ones can yield better results when outsourced to a vendor.
While some larger organizations might bring together distributed testers from various offices to satisfy time zone requirements, localization needs, and level of skills, most companies will struggle to employ all of the testers they need. These organizations will be more likely to use in-house QA managers in combination with external partners to source the unique skills and responsibilities required to satisfy testing cycles – paying for additional capacity only when it is necessary.
That matters a lot for QA testing. Your engineering team might need a burstable team of testers for three days, and then not need to work with them again for two whole weeks. Distributed testing gives your organization the freedom and flexibility to build the right relationships with the right resources.
On the other hand, without distributed testing, your company has to choose between hiring all of the testers needed during releases and not making full use of them in between idle periods, or not recruiting enough testers and not living up to customers’ expectations for a quality experience.
5. Different devices
With around 1.5 billion smartphones sold worldwide each year, it’s impossible to test every possible device your customers might own. However, good device coverage for popular smartphones, tablets, and IoT devices remains essential, as small differences in hardware can have a significant effect on the customer’s digital experience.
With that in mind, organizations engaged in distributed testing can effectively manage test coverage with real-world devices. Why? Because they have testers spread in different markets and locations, where popular device manufacturers vary. These companies are also more likely to team up with networked testing partners that rely on contract testers and their combined thousands of real hardware devices.
With easy access to the devices that matter to the product, distributed testers can more quickly satisfy device coverage requirements for a release. When testing isn’t distributed, an engineering manager will need to procure device coverage for important releases, and the time it takes to do so will slow shipping speeds considerably.
In so many ways, distributed testing makes shipping quality updates to your users faster.