Speed and quality — they’re debatably the two most sought-after exploits to participants in the software development lifecycle. Unfortunately, having one often comes at the cost of the other, leaving professionals to make a decision on which is more important.
Of course, different businesses may put a different emphasis on one or the other. For example, an e-commerce company might be more interested in maintaining consistent quality on their web application so customers will complete a purchase from their site and have a good enough experience to come back. Additionally, companies in high-stakes industries such as medical or financial recognize the unparalleled importance of quality over speed with their stakeholders.
Quality
Meanwhile, a large social network like Facebook may be more interested in releasing new features to keep their users engaged and interested than they are invested in worrying about quality. We can assume this because Facebook doesn’t even have dedicated QA or Testing team — they depend on developers and users to test new features since “social media is nonessential.”
In light of many organisations adopting processes such as Agile and DevOps, it may seem like speed has become a priority as teams take a more iterative approach to implementing new features and getting them to market more quickly.
But, it also depends on who you ask. If you consult a tester, they might say that these methodologies allow for more opportunities to intermittently assess quality and make way for Continuous Testing, while others might say that focus on speed often means overlooking those same concerns.
The moral of the story is that speed vs quality will be an eternal debate. Some will think one is more important, and some the other, with no one-size-fits-all answer.
Maybe the question should not be which do we prefer, but how we can do both more often. How can we combine the speed that development and management strive for with the quality our testers and QA engineers know is critical? How can we make Agile work for us in a way that is both effective and efficient?
Test Automation
Test automation exhibits the best of both worlds in speed and quality. Repeating scripts allows anyone to run tests in regression without having to manually repeat the same steps over and over so that more time can be spent exploring new features rather than checking old ones. However, automated testing can be time-consuming in itself. Even just considering all the different browsers and devices you have to test on, running these tests one after another in different environments is still tedious.
Parallel testing is an increasingly popular way many software teams are finding a way to strike the balance between speed and quality by taking automated testing a step further. By leveraging a Selenium grid, either with an in-house device lab or a cloud service like CrossBrowserTesting, developers and testers are able to run their scripts at the same time instead of one after the other, allowing teams to test across different environments in a fraction of the time it normally takes.
Cumbersome and tedious tasks like unit testing, smoke testing, regression testing, and cross-browser testing can be cut from taking weeks to days, days to hours, and hours to minutes with parallel testing. This not only makes the process faster to affect quicker deployments, but it also increases the range of coverage of your tests. Yes, this means that speed and quality are being addressed at the same time.
It’s revolutionary. Teams that have experienced this phenomenon know that life will never be the same again. They no longer have to waste their time and effort worrying about speed and quality (or arguing which is superior) but instead, they can focus on their jobs — building new features, creating new test cases, and delivering great software to customers.
So perhaps the challenge is to stop pursuing the debate of speed vs. quality and start embracing the idea of speed and quality. How can we find more ways to combine these ideas in order to work towards one common goal? How can we utilise faster testing that doesn’t compromise quality, but enhance it?
This post was originally published on SmartBear blog
