Releasing quality software is not an accident!  It is a work of art requiring executive sponsorship and the coordination of several stakeholders.

I am an advocate of the Three Amigos Development Strategy.  This approach requires stakeholders from the Business, Development and Testing teams to reach a common, shared vision of what is being built.  All groups involved should agree on Acceptance Criteria and the Definition of Done.  

This strategy helps to shape a better product by improving communication, forcing clear requirements, removing ambiguity and allowing each represented group to give valuable input based on their skills and experience.  Software features do not exist in a vacuum. They must be created, shaped, nurtured and supported. Consensus on what to build is an often overlooked first step on the path to high quality software.  

“Software testing” encompasses several disciplines including manual, unit and automated testing; validation; verification and continuous integration.  Testing is best done throughout the development cycle by an integrated team and should not be treated as an afterthought after the code is “thrown over the wall”.  Defects are typically more expensive to address when found later in the cycle.  

Just because a company has the technical ability to move code quickly through the pipeline does not mean that it is always best to do so.  It is important to know your industry and understand your customer’s risk tolerance.  Moving quickly and deploying code several times a day can introduce risk.  Some customers may tolerate bleeding edge features and occasional instability but many “high value customers” often view the most important features as speed, stability and security.  

Although there is obvious value in internal testing, some of the most valuable testing is arguably done in Production.   Slow rollouts to targeted customers is an ideal way to gather real-world customer feedback and performance metrics.   Software is never “done” and we should expect to have to tweak and iterate based on feedback, associated metrics and support cases.   

There is more to software than its code.  Just because the “code is done” does not necessarily mean the feature is ready to be released.  The Three Amigos should decide on the Definition of Done to keep the company aligned.  

For example:  

• Has the test suite been updated?  
• Does the documentation require updated screenshots?  
• Does the website need to be updated?
• Will there be any impact on pricing plans?   
• Has the Support team been given a chance to test the feature and ask questions?  
• Will the feature behave differently on a new install vs. an upgrade?  
• What is the rollout strategy?  
• Do we need to add new performance metrics for the Infrastructure team to monitor?  
• Etc…

I drive my teams to release “testable code” that is simple to deploy, monitor, support and iterate.   Once code is deployed, the Engineering team must continue to take responsibility for it.  “Abandoned code” is often very expensive to maintain and support.