Hello to all quality enthusiasts. Today’s article is not technical. Sometimes it is nice to talk about processes and quality in general. Today I would like to share some thoughts on quality gates. How many times have you heard this word? None? Once? Every day? It doesn’t matter if you have heard it or not, I believe you have used it in the past. Maybe you know it, maybe you don’t, but I think you can do it in your current project.
The goal of this article is just to put books we already have into the shell. Including my books too 🙂 But before we start cleaning up our library, let’s try to remember what quality is?
From Quality to Quality Gates
According to the ISO 9000:2015 standard, quality is defined as the “degree to which a set of inherent characteristics of an object fulfills requirements.
In the case of a software product, quality simply represents the grade or level of excellence of the product. However, it includes various aspects, including functionality, reliability, performance, security, usability, and maintainability, all of which contribute to meeting stakeholder expectations and requirements.
How can we control the quality of our work? We achieve this through quality gates, which serve as checkpoints to ensure standards are met at every stage of development.
A quality gate is a checkpoint placed at critical stages of the development process to assess whether the product meets predefined quality standards before moving forward. These gates act as control mechanisms, preventing defects and ensuring compliance with requirements at each phase — from requirements gathering to deployment.
When we talk about quality gates, we often associate them with the coding phase. However, quality gates are not limited to coding — they apply to the entire Software Development Life Cycle (SDLC), ensuring quality at every stage, from requirements gathering to deployment.
Each phase in the Software Development Life Cycle (SDLC) has a set of defined criteria that must be met before progressing to the next stage. To move forward, all mandatory criteria must be fulfilled, while some criteria may be optional. However, failing to meet the required criteria should block the transition to the next phase, ensuring quality control.
This, however, is a high-level perspective. Technically, each phase may consist of sub-stages, where progress happens incrementally within the phase before moving to the next major milestone.
Our next goal is to walk through each stage of the Software Development Life Cycle (SDLC). However, we won’t aim to cover all possible criteria, as they can vary depending on project specifications and specific needs. Instead, we will focus on key aspects that are commonly used to ensure quality at each phase.
Requirements
Before moving to design, requirements must be well-defined, clear, and testable to avoid costly changes later.
In my opinion, this critical stage is often overlooked, leading to issues in later phases of development. Several factors contribute to this, including lack of domain knowledge, inefficient processes, and time pressure.
To effectively control this stage, the best approach is to use Task Management Tools (e.g., JIRA, Azure DevOps, Trello) combined with structured checklists. These tools help track progress, enforce review processes, and ensure that requirements meet defined quality criteria before moving forward.
Of course, the exact approach depends on your team’s workflow, project complexity, and available tools, but implementing a structured validation process can greatly reduce risks in later development stages.
Possible Criteria:
- Requirements Completeness: All functional and non-functional requirements are documented.
- Clarity: No vague, conflicting, or unclear requirements.
- Feasibility Check: Requirements are technically and practically achievable.
- Stakeholder Approval: Business and technical teams have reviewed and approved.
- Traceability Matrix: Each requirement is linked to business objectives and test cases.
Design
Before development begins, the software architecture and design must be well-structured and aligned with the requirements. Coding guidelines should also be defined, both general and specific, such as API design standards, UI design standards, and more. You might want to pass these quality gates before start coding phase.
Possible Criteria:
- Architecture Review: The system architecture is scalable, secure, and efficient.
- Design Consistency: Follows design patterns and best practices.
- Performance Consideration: Addresses scalability, response times, and load capacity.
- Security Measures: Threat modeling and risk assessments are completed.
- Stakeholder Approval: Design is reviewed and signed off by architects and key stakeholders.
Coding
Code should be well-written, maintainable, and tested before moving to the next phase.
This is probably my favorite quality gate stage because it offers numerous opportunities for automation. Are you conducting code reviews on pull requests (PRs)? Are you measuring unit test coverage? Do you have static analyzers and security code scanning in place?
These, and many other critical questions, help ensure code quality before moving forward. The best part? Many of these steps can be automated, preventing progress to the next stage until all requirements are met — without requiring manual effort.
Combining these approaches with the Testing Pyramid can have a significant positive impact on software quality. By aligning automated quality gates with a well-structured testing strategy, you ensure that different layers of testing — unit, integration, and end-to-end tests — work together efficiently, reducing defects early and improving overall stability.
But we are a little bit hurry. Let’s move to Acceptance testing stage.
Possible Criteria:
- Code Review: Peer reviews are conducted to ensure best practices.
- Coding Standards: Code follows predefined conventions and industry standards.
- Static Code Analysis: Automated tools check for code smells, security vulnerabilities, and maintainability issues.
- Unit Testing: A minimum percentage of test coverage (e.g., 80%) is achieved.
- Security Compliance: No critical vulnerabilities in the codebase.
Acceptance Testing
The software should meet business requirements and be validated against acceptance criteria before release.
This stage is also a great candidate for automated testing, especially for regression testing. However, it’s not just about running tests — it’s about ensuring the application is truly ready for release. At this stage, the acceptance criteria we define serve as our quality gates, determining whether we can confidently proceed with deployment.
To streamline this process, Continuous Delivery (CD) and Continuous Deployment are two powerful approaches that can be implemented:
- Continuous Delivery (CD): Ensures that every change is tested and ready to be deployed at any time, but requires manual approval before going live.
- Continuous Deployment: Pushes every validated change directly into production without manual intervention, ensuring rapid and frequent releases.
Both approaches rely heavily on automated testing, security checks, and deployment pipelines to maintain stability while delivering new features quickly.
Quality Control (QC) and Quality Assurance (QA) engineers are probably very familiar with this stage. But ask yourself: Do you truly understand what the quality gates you have in your project? Or would it be better to discuss and define them explicitly to ensure clarity and alignment across the team?
Possible Criteria:
- Functional Testing Passed: All test cases for key business flows are executed and passed.
- User Acceptance Testing (UAT): End-users confirm the system meets their needs.
- Regression Testing: No critical issues introduced in previous functionalities.
- Performance Testing: The system behaves correctly under expected workloads.
- Defect Triage: Any open defects are reviewed, and critical/blocker issues are resolved.
Release
Before deployment, the software must be stable, secure, and ready for production use. A release strategy can be a key document that outlines quality gate items. It’s essential to consider all necessary steps before proceeding with the release, as they can be crucial. The best approach is likely to have a checklist. However, Continuous Deployment with automated steps can also be a good option. You may even think about automated documentation steps.
Possible Criteria:
- Deployment Checklist: All pre-release activities are completed.
- Rollback Plan: A tested rollback procedure is in place.
- Security Audit: No major vulnerabilities exist in the system.
- Infrastructure Readiness: Production environment is prepared and meets system requirements.
- Sign-offs Received: Business, development, and operations teams approve the release.
Maintenance
Our software has been released — mission accomplished! Time to relax. Take my beer!
But wait… unfortunately, that’s not the end. Post-release, the software must be continuously monitored and maintained to ensure ongoing quality and performance. Also today is very popular Shift-Right testing approach when you continue your testing activities on released product. Maybe run some automation scripts that does not heart a data.
Possible Criteria:
- Monitoring in Place: Logs, alerts, and monitoring tools are active.
- Incident Response Plan: Clear procedures for handling production issues.
- Bug Tracking: Reported defects are logged, prioritized, and addressed.
- Performance Monitoring: System meets up-time and response time expectations.
- Continuous Improvement: Feedback is collected and analyzed for future enhancements.
Review, Plan and implement a Quality Gates
The first step in building Quality Gates is to take a look at what we already have. That means doing a quick internal audit to see if there are any existing quality checkpoints — even if we haven’t thought of them as “Quality Gates” before. It’s also helpful to map them to the different stages of the Software Development Life Cycle (SDLC) to get a full picture of where we stand.
Once we know what’s already in place, the next step is to brainstorm what else we might need. This could include checks for things like code quality, security, performance, or compliance. The goal is to come up with a list of potential Quality Gates that could help improve our process. Here is important to focus on the quality gates that definitely can help you to resolve some problem.
From there, we can start prioritizing and discussing which ones make the most sense to implement first. A step-by-step approach works best — starting with the most critical gates and then expanding over time as we gather feedback and refine the process.
In the end
Quality gates act as checkpoints to prevent issues from progressing further in the SDLC. While the specific criteria may vary depending on the project and business needs, having well-defined quality gates ensures a structured approach to delivering high-quality software.
One more thing I forgot to mention: it’s always good to document such things for transparency, to put everything on the table, and to make it easier for newcomers to get involved.
How do you feel? Do you have good quality gates on your project? Or have you found something you can improve? Good luck and may the force be with you!
Original article : https://medium.com/@dneprokos/quality-gates-the-watchers-of-software-quality-af19b177e5d1