Development testing offers a new way to look at code quality and security by moving testing upstream, earlier in the software development lifecycle (SDLC). This enables developers to detect and fix key defects and ensure critical code is covered by an automated test as the code is written, while allowing all affected teams – development, QA, security and others – to do their jobs more effectively and efficiently. However, the need to test code automatically as it is written can require a significant cultural change for any organization.
So how can you best prepare for this transformation?
Purnam Sheth, Vice President of Engineering at Pelican Imaging, has implemented development testing at multiple companies – from small start-ups like Pelican Imaging, to large organizations like Cisco. Based on this wide range of experience, he has identified 3 key steps to building a business case for development testing in any organization:
Step 1: Identify business drivers
Recognizing the need for automated testing and the business drivers fueling that need is the first step. For some organizations, it is as simple as needing to find and fix defects. Or, needing a solution to accelerate the testing process and complement or even replace manual code reviews, thus increasing developer efficiency and time to market (TTM). At Pelican Imaging, the drivers for adopting development testing were multi-faceted, as Sheth shares:
“The penalties for not delivering high-quality software and with a very fast TTM are huge for our company. We’re a start-up. We want to beat everybody else to market. We also want to do really well, and we want our customers to be really successful. Using tools like Coverity allow us to really have that business advantage, as well as in some respects have happier engineers.”
Sheth goes into more detail in this 4½ minute video: Building a Business Case for Development Testing: Business Drivers.
Step 2: Evaluate purchase criteria
Once business drivers have been identified and there’s a clear need for an automated testing solution, evaluation and purchase criteria follow as the next step. A critical element to determine at this phase is not only the product performance and scalability, but also how the solution will fit in the developer workflow. As we’ve heard from many of our customers, if a solution isn’t easy to use and makes a lot of noise, developer adoption will no doubt be a struggle and in some cases impossible to overcome. Sheth adds:
“Engineers and processes by their nature try to standardize things, and introducing a new standard always has challenges. [The differentiators] found when using Coverity compared to a number of the other tools is a lower number of false positives, as well as the integration and partnership across a very large code base, 10-20 million lines of code. It was a very interesting process both from how you manage engineers, how you mange release, and how you manage product to get it in place. We had a very successful roll out of Coverity in that environment. As I moved to a startup environment, even though it’s much smaller, all the same issues are there, just at a different level and pace. Both the tooling and the partnership is what made a great implementation and cost savings, as well as TTM for the company.”
Sheth explains more about Pelican Imaging’s experience in this 2½ minute video about Evaluation and Purchase Criteria.
Step 3: Realize the ROI
After purchase and deployment, justifying the investment is the next step, which is often on-going. The ROI of implementing development testing can be measured in many different ways – some measure it in time savings (time to market and resources or man-hours saved), some measure it in terms of the number or type of defects fixed, and some measure the actual cost savings (estimating the cost of a known defect or product recall, the cost of resources and time saved, etc.). Providing customer satisfaction by delivering a reliable product typically makes the list as well. Sheth shares his experience:
“It’s not just about delivering the product faster and better to the customer, it actually changes the culture of the company to be one that expects higher quality, and [recognizing] that we have also given the tools to the developer to allow them to succeed at doing that. That actually has a very subtle, but almost just as large of an impact on the whole business outcome of how you deliver great software to your customers.”
For more information regarding Sheth’s experience, watch this 4½ minute video on Realizing the ROI of development testing.
The post 3 Steps to Building a Business Case for Development Testing appeared first on Software Testing Blog.