To continue our discussion on the different forms of the software supply chain, this month we look at the best-practices for working with third-party software suppliers. (See: How to Work Better With the Open-Source Community.)
The largely successful philosophy of why-build-when-you-can-buy has inspired Original Equipment Manufacturers (OEMs) building software and systems to buy software components from third-party providers. Every software module within the system, regardless of its source, is an integral part of the OEM brand. Hence, it is necessary that every piece measures up and is tested.
When it comes to testing, there are some idiosyncrasies specific to the software supply chain. For example, each instance of a physical part is different and needs to be tested for flaws. Software rarely has flaws from copying, but defects in the code can cause integration difficulties and stability problems during testing, or, worse, after deployment to customers.
By using automated code testing, you can clearly demonstrate that you care about the quality of the software you provide. Here are a few processes that our customers have implemented:
- Put it in the contract:
- Expect a report indicating the quality of every software version received:
- Auditing mode:
Modern static analysis solutions provide vendors with a cost-effective, automated, and repeatable way to ensure the quality of software they create and ship. Because static testing produces results that are measureable, objective, and repeatable, OEMs can require it as a contractual agreement with a third-party software provider.
A high-level report of the testing effort and quality should be necessary with every drop of software received. A report indicating that all bugs and defects are fixed may be an unrealistic expectation. However, if a report indicates untested parts or many defects that have not been reviewed, it serves as a strong signal that quality is not up to par. Additionally, a report can provide an indication of quality compared to industry averages.
OEMs that purchase source code can reserve the right to analyze the supplier's code and report the results back. It could be implemented as part of the integration. This helps in multiple ways. Firstly, the OEM has a way to measure the quality of what is received using the same measuring stick that it uses internally, and secondly, by providing recommendations and results of the analysis back to the supplier, it gives the supplier an opportunity to fix the defects.
As with every aspect of the value chain, successful processes create value for both parties involved. For a company purchasing software components, these methods improve and support the brand by ensuring that externally sourced code is held to a high standard. For a supplier, it's an objective way to represent the quality of the product and strengthen the relationship with the customer.
These are just some of the lessons we've learned from working with our customers who are on both sides of the software supply chain. What are your thoughts on these testing solutions?