Focus on Speed Doesn’t Mean Focus on Automation
When forced to choose, quality wins out over speed seven out of 10 times according to a survey of over 600 IT professionals conducted by OverOps, a vendor that helps identify and remediate software issues. In the real world, the choice is not stark. The New Stack used data not included in 2020 edition of “The State Software Quality” to look at the implications of having a bias towards releasing software quickly.
People with a bias towards speed are faster. Twenty-eight percent of those with a preference for speed release new features at least daily while the quality-loving cohort only does so 17% of the time. The consequence is that 71% of the “speed” respondents’ organizations encounter critical or customer-impacting issues in production at least once a month, while 53% of everyone else says likewise.
While there may be more critical issues, that does not mean more time is spent on troubleshooting. Of those that have responsibility for troubleshooting, about 65% spend less than 25% of their time troubleshooting, regardless of whether they care about quality or not. Taking your time before releasing code does not reduce the time spent after it is released into production. Developers are probably using that extra time to do tweak new features and address less critical functionality.
Ironically, 70% of respondents that prefer quality use automated testing pre-production compared to only 54% of those that claim to care about speed. Automated testing is about making things faster, but it also enforces policies and reduces the chance for human error. Companies that prefer speed are focused on the latter issue, with almost half (48%) saying the primary reason for production errors is a lack of the right processes, compared to 28% of everyone else.
About half of the IT pros surveyed were developers or software engineer. Source: Overops’ “2020 Report” The State of Software Quality”.
These results require some context. There are many different types of testing: unit, integration, functional, load to name a few. Different job roles often claim primary responsibility for each type. According to the “State of Open Source Testing,” published by Tricentis and several partners, functional testing is the domain of Quality Assurance/Testing and a lack of time is its biggest roadblock.
Diffblue’s “2020 DevOps And Testing Report”.
In another survey, this one from GitLab, testing is the top reason for delays in software development. Whether the testing is for security, customer experience or performance optimization, people get frustrated when another department causes a delay.
With that in mind, here is one final study, “2020 DevOps And Testing Report,” which was commissioned by Diffblue. In it, 81% of developers say the biggest hurdle to creating a “testing culture” is a lack of dedicated resources from management, while management itself is much less likely to think resources are an issue. Perhaps managers know they are funding a separate testing department. This would exemplify the conundrum faced by developers and DevOps teams that want to take on more testing responsibility. Can QA be done right if there is no dedicated QA/testing team in the organization?
Tricentis is a sponsor of The New Stack.
Feature image via Pixabay.
