This was originally published on my blog, https://unremarkabletester.com/.
"Can we release this feature?" is usually a question answered by humans, not machines. From what I have seen around, even teams that practice continuous deployment seem to take a step back to consider whether they are ready to expose new functionality to their users. My impression is that "release decision" time might vary from a couple of hours to days or longer. Surely, a stable, meaningful deployment pipeline and a team's certain autonomy level are prerequisites to take a decision. But I was wondering, what other activities might influence such a decision and how we could reduce their time span?
Here is a list of the things I came up with.
Acceptance testing
Usually done by the product owner, it's a review whether the software produced meets the business expectations. Behaviour Driven Development (BDD) can reduce the time acceptance testing takes as it puts in place automated checks to cover that task. But even if you don't automate your specifications, just having a conversation as a team to get a clear understanding of the business' needs, produces software that requires less time to be verified before release.
Compliance validation
If you are working in a regulated industry, proof of compliance might be something that takes up a big chunk of your time before releasing. For checks that can be automated, a good idea is to include them in your deployment pipeline and automatically collect the produced artefacts, like reports of issues found. For things that cannot be fully automated, such as Accessibility aspects, raising awareness on the topic and educating the development team on good practices can improve the software quality without extended checks at the end.
Go-to-market activities
A new, prominent feature might affect marketing and user assistance aspects of your product. Pricing might change, new sales pitches might need to be created and some new documentation should help users in case they need it. To avoid surprises that cost time before release, it is a good idea to include technical writers and people from marketing or sales in the development process. They don't need to be in every meeting, but having an idea of how a feature is shaping up during development and working in parallel on their end to bring it to the customers, could reduce release decision time.
Exploratory testing
I have noticed many teams performing exploratory testing sessions, as a final check-point before releasing to their customers. Having a last look for risks that might threaten the quality of our work is a very human thing to do. On the other hand, waiting until the last moment to do such an evaluation might be too time consuming. By applying exploratory testing mindset throughout your development process, from specification of requirements, to API design and external services dependencies, you address potential risks earlier. So, when the release decision time comes, you already feel a certain level of confidence about the quality of your product.
I am sure that there are more "manual" activities we perform before we release our product and even more ways to reduce their duration. So the question that remains is, can we come up with an automated process to trim the release decision time to zero? And most importantly, do we really want to remove the decision from humans altogether?
Cover photo by Noah Silliman on Unsplash
Top comments (1)
Thanks for this thoughtful post Areti, I was struck by the human aspects that always remain somewhere: you mention some of these in 'go-to-market activities' and 'exploratory testing'. I found a couple of blogs from present & past employees of Amazon, and Contentful that give an excellent view of the human aspects:
jasoncrawford.org/two-pizza-teams
contentful.com/blog/2019/07/23/del...
My take on this revolves around: getting a good 'fitness function' (typically a financial measure but it can vary) in place early so everyone can see how delivery is going and autonomously correct course if necessary; including people in the team to cover all the aspects required to deliver to the fitness function, perhaps through the use of skills matrices as mentioned in the Contentful blog, or a Rose diagram for the team with essential capabilities on the axes; 'shifting left' and automating all the repetitive stuff as you describe, to shorten cycle times, surface issues quickly and provide confidence across the team that we can indeed release stuff :)