A defining feature of a mature software development process are quality gates. A quality gate is a strict barrier that all work items within a specified scope (e.g., all development artefacts of a project) need to pass in order to enter the next phase of their processing. The primary function of a gate between two stages of a process is to make sure that all work items within one stage share an agreed and explicit level of quality. In software development contexts, quality gates are most common near the point where a piece of implementation is finished. In due course, we’ll discuss the ‘near’ aspect of this characterisation.
Quality gates are tightly related to a system’s regression. Since the purpose of the gate is to establish a certain minimal quality at a given stage and since that quality is necessarily higher than any other gate at previous stages (if any), regression would contradict the purpose of a stage. This is why it makes sense to ensure at those gates at which regression is relevant that regression tests are considered. Note that not all gates cover regression, though.
This directly leads to automation considerations because regression testing is, again, tightly related to automation. Many professionals treat both concepts virtually synonymously. Regression tests need to be automated because otherwise something needs to yield. You may accept potentially diminished quality and keep a high pace in your release cycles. Alternatively, you may accept significantly slower release cycles at a higher quality. But if you want both—fast delivery at a reliably high quality—you need to automate at least parts of your regression suite.
Gates occur near points where a piece of implementation is finished, I said above. Implementations are not necessarily related to code, but, in fact, gates are commonly found at those points where code changes are involved. For example, when a code change is reviewed, or when it is merged, or when it is deployed to the next stage in a cascade of different environments. In general, however, there is no need to restrict the application of gates to just technical contexts. In fact, according to the Shift Left paradigm, the leverage effect of quality introduced at the very left of the software development life cycle is by far the highest.
This is why it makes sense to not just introduce one single quality gate—e.g., when code changes get merged—but many of them and in particular in early stages. It slows down progress of artefacts in those early stages. But the pros clearly outweigh the cons: less escaped bugs; quicker implementation; higher developer satisfaction; less in-sprint anomalies; etc.
Gates must be defined, transparent, and robust. There must be a specified number of gates with specified characteristics. Ideally, the gates are named appropriately to ease identification. Project members need to be aware of (i) the location of gate definitions; (ii) who needs to adhere to them; and (iii) when and by whom they are updated, if required.
Robustness means two things here. Firstly, you may always rely on them. They effectively do what they are defined to do. They block work items efficiently. They are clear and hard. Secondly, they have non-trivial implications. They really are a threshold. They may not be surpassed easily, except for very trivial changes to the code base.
It goes without saying that your checks and balances might include non-robust elements as well. For example, you might want to perform certain automated checks on your work items at a specified point of your process. You would let failing items enter the next stage. You’re just curious as to whether these items would have passed your tests. These failed tests might even trigger additional work. You may do all that. It’s just that by definition everything that, no matter the outcome, lets pass every work item is no part of a quality gate—even if its occurrence is perfectly correlated with such a gate.
Robustness comes with a variety of advantages. It establishes a stringent level of quality in your product. No significant changes in quality may be introduced beyond a given gate. There are virtually no surprises. (Theoretically, a gate might fail like any other artefact, but it’s relatively unlikely.) Work may be distributed more efficiently. Manual testers may take as given what has been defined at a gate. There is no need to double-check.
Overall, good quality gates contribute to higher product quality beyond the trivial sense that work items need to pass them:
• If you establish quality gates then all of the sudden quality becomes an integral part of your process definition, triggering project members to think about quality regularly.
• Work items have a high degree of prima-facie quality when they enter manual review.
• You make quality a defining feature of work item phases in your development life cycle, thereby fostering a quality-led approach to software development.
• Testing is more focused and hence itself of higher quality.
All this seems highly desirable. So, how would you implement it? Here are some ideas. Firstly, give quality a central role in your project. External pressure might help here, for example by competitors or rivalling products. If there is no need for high quality ‘by force’, try to advocate for quality according to your role in the organisation or project. Secondly, regularly talk about quality with your team, for example by defining and regularly updating a DoR and DoD. Thirdly, stick to the Scrum Guide’s advice and do not build in quality retroactively. The agreed-upon level of quality must be adhered to from the first iteration. Thirdly, make high investments in the beginning. Establish a high degree of automation and continuous integration, avoiding costs and risks at later stages of the project. Fourthly and finally, get rid of unnecessary gates (or unnecessary elements of existing gates) in order to increase developer satisfaction.
No responses yet