Let me start this blog post with a question: Is a gate designed to keep things in or let something out? Depending on your mood, you may have different answers to this question which may not be limited to the options I have provided. However, if I am to be diplomatic and keep my emotions out, I would say a gate is designed to control what is allowed to pass through its threshold. For this discussion, what we are looking at controlling, is quality.<\/p>\n
Moreover, it is essential to note that a quality gate is only as strong as the will of the gatekeeper.<\/p>\n
Each stage in the software development lifecycle provides us with several opportunities to implement quality gates. At each quality gate, the gatekeeper could be a person, personnel, or a tool. The main goal of the gatekeeper would be to regulate what goes out and what is restricted. This is easier with tools like Sonar, which provides the facility to configure the quality gates. Such tools can monitor the health of the codebase based on several criteria and indicate where quality aspects such as maintainability and dependability are lacking. The situation gets a bit sticky when people are involved, where added timeline pressures will test the will of the gatekeeper. As I have mentioned earlier, a quality gate is only as good as the will of the gatekeeper. It is a symphony of integrity, accountability, bravery, and negotiation skills of the gatekeeper that provide high-quality products and components to the next set of stakeholders.<\/p>\n
Now that we\u2019ve discussed the gatekeeper’s mindset (or ruleset), let\u2019s evaluate which quality gates we should use and when we should use them.<\/p>\n
Why, What, When, Who, and How. These are the questions you should ask yourself, your audience, and the stakeholders to understand the purpose behind introducing quality gates. If we are to search online to find out the best quality gates to use or which are the most attractive quality gates used in the industry, we will end up with a long list of promising options. However, a report or a dashboard should never be ‘everything-but-the-kitchen-sink\u2019\u2014this approach will most definitely confuse, distract and overwhelm your audience. You need to avoid falling into this trap.<\/p>\n
Given below is a simple depiction of how your thought process could best work to achieve a carefully curated yet effective report\/dashboard containing quality gates.<\/p>\n
| Why<\/th>\n | What<\/th>\n | When<\/th>\n | Who<\/th>\n | How<\/th>\n<\/tr>\n<\/thead>\n | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| How effective is the time spent on requirement gathering?<\/td>\n | To check the quality of my requirement specifications<\/td>\n | Before the subsequent team starts work on the requirements (e.g., Development Team)<\/td>\n | By: Development & Testing Teams To: Requirement & Management Teams<\/td>\n | \n 1. Requirement Clarity Index \n 2. Q&A document summary and progress\n <\/td>\n<\/tr>\n | ||||||||||||||
| To check the effectiveness of work done by the development team.<\/td>\n | \n 1. To see how good the development codebase is \n 2. The amount of defective code introduced \n 3. The amount of rework required\n <\/td>\n | Before handing it over to the testing team<\/td>\n | By: Development & Testing Teams To: Testing & Management Teams<\/td>\n | \n 1. Code quality measurement tools (e.g., Sonar) \n 2. Code reviews \n 3. Development unit test pass rate \n 4. First-time test pass rate \n 5. Number and criticality of defects identified \n 6. Defect removal efficiency \n 7. Defect Aging \n 8. Defect severity index \n 9. Defect density\n <\/td>\n<\/tr>\n | ||||||||||||||
| To check the effectiveness of work done by the testing team.<\/td>\n | \n 1. To see whether test case coverage has been met \n 2. To see if there is no risk to meeting project milestones \n 3. Number of invalid defects recorded\n <\/td>\n | Before handing it over to the client<\/td>\n | By: Testing Team To: Technical, Management & Client Teams<\/td>\n | \n 1. Test case reviews \n 2. Test execution progress \n 3. Defect to remark ratio \n 4. Test coverage verification \n 5. Test case walkthroughs\n <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Why<\/strong><\/p>\n What<\/strong><\/p>\n When<\/strong><\/p>\n Who<\/strong><\/p>\n How<\/strong><\/p>\n How effective is the time spent on requirement gathering?<\/p>\n To check the quality of my requirement specifications<\/p>\n Before the subsequent team starts work on the requirements By: Development & Testing Teams To check the effectiveness of work done by the development team.<\/p>\n Before handing it over to the testing team<\/p>\n By: Development & testing teams To check the effectiveness of work done by the testing team.<\/p>\n Before handing it over to the client<\/p>\n By: Testing Team<\/p>\n To: Technical, Management & Client Teams<\/p>\n Now that we have collected all the pieces of the puzzle, it’s time to put them together to create the picture(s). The most exciting part of this stage is creating multiple visuals for different audiences using the same set of quality gates. The mastery is in the selection, benchmarking, representation, and the placement of each KPI related to each quality gate. Also, there is no foolproof way of getting this right the first time. Perfection is a perception that is subjective to the audience.<\/p>\n Below are few examples of quality gates for further clarification:<\/p>\n When<\/strong><\/p>\n Quality Gate<\/strong><\/p>\n Benchmark<\/strong><\/p>\n Accepting a requirement for development<\/p>\n Requirement clarity index<\/p>\n Q&A status<\/p>\n The confidence level should be 4 or more Over 90% of the questions should be answered<\/p>\n Accepting a development release for testing<\/p>\n Code review<\/p>\n Development unit test pass rate<\/p>\n Smoke test case pass rate<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Completed<\/p>\n Greater than or equal to 80%<\/p>\n Equal to 80%<\/p>\n Completing testing of a release<\/p>\n Test execution status<\/p>\n Number of defects<\/p>\n Defect severity Index<\/p>\n Completed<\/p>\n No Critical\/Major\/Minor defects<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Less than or equal to 1.9 1. Ruthless selection<\/strong><\/p>\n Selection is all about asking yourself tough questions and coming up with decisive answers. Can we justify why we need this quality gate? What do we hope to achieve with this KPI? What visual medium is best suited to reach the end goal? Once you have all the decisive answers, consider your audience and their expectations. They may require information or recommendations and need to make decisions based on them.<\/p>\n 2. Clever prioritization<\/strong><\/p>\n Based on what your audience is looking for, consider the most important and the least important. Another consideration is the medium of communication. If this is a report sent via email, place the most critical information needed for decision-making at the top. The low-priority KPIs should be placed at the bottom, where the user can consciously scroll down and read more. If this is a dashboard view, the KPIs should be set from left to right, top to bottom, in the order of importance. This is a standard that UX specialists follow as it is in line with the eye’s natural movement when we look for information. Also, consider different reading practices adopted by audiences in different geographies.<\/p>\n 3. Graceful acceptance of criticism<\/strong><\/p>\n As discussed already, quality gate selection and implementation is a journey rather than a task. This is because we may have to listen and adapt to feedback from the audience to make necessary changes to help them achieve what is expected of them. What may seem perfect now may not be so after six months into the project. The stakeholders will need to bring in more quality gates or take off some that they feel unnecessary to maintain the flow of work. Therefore, we will have to practice a high level of maturity while receiving feedback and negotiations.<\/p>\n 4. Personal preference<\/strong><\/p>\n Go with your gut when it comes down to selecting, implementing, and representing quality gates. There could be situations where a quantitative indicator is better than a qualitative indicator and vice versa. You may have to ask the questions: What is my audience’s confidence level in me? Will my audience need complete transparency of the decision-making process based on the Quality Gate?<\/p>\n My recommendation is to always go with the quantitative approach with numbers and trends as a rule of thumb. It is more of a scientific approach to decision-making, relatable to almost any type of audience. But as the topic says, it is indeed a personal preference. <\/p>\n As discussed in the sections above, you may feel quality gates are a lot of work. Hence, let\u2019s weigh in the pros and cons. If I begin with the cons, the only trouble with quality gates is that you will have to spend time working on the 4Ws & H, which would need collective brainpower to set up the framework you plan to follow. But once that is done, the rest of the tasks\u2014adhere, monitor, and adapt\u2014are quite simple.<\/p>\n The main benefit of quality gates is that we take all possible preventive actions to ensure \u2018shift-left testing,\u2019 which is all about practicing a quality-focused mindset from the very early stages of the project until the very end. Shift-left testing guarantees less rework effort and ultimately helps in delivering high customer satisfaction.<\/p>\n Another attractive characteristic is that quality gates have no restrictions considering the scale of the project. As a QA professional who has been in the industry for a decade, I have been fortunate enough to work on diverse projects scaling from the small web and mobile applications to large ERP applications. Looking back at projects that adopted quality gates and projects that didn’t, it is a clear win for quality gates. The domain, scale, technology, complexity are no barriers to implementing effective quality gates, which can significantly benefit the quality and ensure the project moves forward according to the timeline.<\/p>\n To conclude this blog post, I will jump back to my title\u2014the ‘fuss’ with quality gates. The main idea I want to convey is if you are serious about the quality of work you produce, invest some quality time to identify quality gates.<\/p>\n Successfully implementing quality gates can deliver many advantages to a software development project. A few are listed below: <\/p>\n As discussed throughout this article, not only do quality gates control the flow of quality throughout the project lifecycle, but they can also be converted to KPIs. These KPIs can be a handy tool to monitor the quality, a gamechanger for effective decision-making.<\/p>\n Written by:<\/p>\n","protected":false},"featured_media":14299,"template":"","meta":{"_acf_changed":false,"content-type":""},"industry":[],"service":[69,68],"class_list":["post-10289","blog","type-blog","status-publish","has-post-thumbnail","hentry"],"acf":{"blog_render_type":"legacy_acf","sections":[{"section_title":"What is a quality gate?","section_content":" Let me start this blog post with a question: Is a gate designed to keep things in or let something out? Depending on your mood, you may have different answers to this question which may not be limited to the options I have provided. However, if I am to be diplomatic and keep my emotions out, I would say a gate is designed to control what is allowed to pass through its threshold. For this discussion, what we are looking at controlling, is quality.<\/p> Moreover, it is essential to note that a quality gate is only as strong as the will of the gatekeeper.<\/p>","section_image":"","table_rows":null,"pro-tip":""},{"section_title":"Role of the gatekeeper","section_content":" Each stage in the software development lifecycle provides us with several opportunities to implement quality gates. At each quality gate, the gatekeeper could be a person, personnel, or a tool. The main goal of the gatekeeper would be to regulate what goes out and what is restricted. This is easier with tools like Sonar, which provides the facility to configure the quality gates. Such tools can monitor the health of the codebase based on several criteria and indicate where quality aspects such as maintainability and dependability are lacking. The situation gets a bit sticky when people are involved, where added timeline pressures will test the will of the gatekeeper. As I have mentioned earlier, a quality gate is only as good as the will of the gatekeeper. It is a symphony of integrity, accountability, bravery, and negotiation skills of the gatekeeper that provide high-quality products and components to the next set of stakeholders.<\/p> Now that we\u2019ve discussed the gatekeeper's mindset (or ruleset), let\u2019s evaluate which quality gates we should use and when we should use them.<\/p>","section_image":"","table_rows":null,"pro-tip":""},{"section_title":"4Ws & H","section_content":" Why, What, When, Who, and How. These are the questions you should ask yourself, your audience, and the stakeholders to understand the purpose behind introducing quality gates. If we are to search online to find out the best quality gates to use or which are the most attractive quality gates used in the industry, we will end up with a long list of promising options. However, a report or a dashboard should never be 'everything-but-the-kitchen-sink\u2019\u2014this approach will most definitely confuse, distract and overwhelm your audience. You need to avoid falling into this trap.<\/p> Given below is a simple depiction of how your thought process could best work to achieve a carefully curated yet effective report\/dashboard containing quality gates.<\/p> Why<\/strong><\/p> What<\/strong><\/p> When<\/strong><\/p> Who<\/strong><\/p> How<\/strong><\/p> How effective is the time spent on requirement gathering?<\/p> To check the quality of my requirement specifications<\/p> Before the subsequent team starts work on the requirements By: Development & Testing Teams To check the effectiveness of work done by the development team.<\/p> Before handing it over to the testing team<\/p> By: Development & testing teams To check the effectiveness of work done by the testing team.<\/p> Before handing it over to the client<\/p> By: Testing Team<\/p> To: Technical, Management & Client Teams<\/p> Now that we have collected all the pieces of the puzzle, it's time to put them together to create the picture(s). The most exciting part of this stage is creating multiple visuals for different audiences using the same set of quality gates. The mastery is in the selection, benchmarking, representation, and the placement of each KPI related to each quality gate. Also, there is no foolproof way of getting this right the first time. Perfection is a perception that is subjective to the audience.<\/p> Below are few examples of quality gates for further clarification:<\/p> When<\/strong><\/p> Quality Gate<\/strong><\/p> Benchmark<\/strong><\/p> Accepting a requirement for development<\/p> Requirement clarity index<\/p> Q&A status<\/p> The confidence level should be 4 or more Over 90% of the questions should be answered<\/p> Accepting a development release for testing<\/p> Code review<\/p> Development unit test pass rate<\/p> Smoke test case pass rate<\/p> Completed<\/p> Greater than or equal to 80%<\/p> Equal to 80%<\/p> Completing testing of a release<\/p> Test execution status<\/p> Number of defects<\/p> Defect severity Index<\/p> Completed<\/p> No Critical\/Major\/Minor defects<\/p> Less than or equal to 1.9 Selection is all about asking yourself tough questions and coming up with decisive answers. Can we justify why we need this quality gate? What do we hope to achieve with this KPI? What visual medium is best suited to reach the end goal? Once you have all the decisive answers, consider your audience and their expectations. They may require information or recommendations and need to make decisions based on them.<\/p>2. Clever prioritization<\/strong> Based on what your audience is looking for, consider the most important and the least important. Another consideration is the medium of communication. If this is a report sent via email, place the most critical information needed for decision-making at the top. The low-priority KPIs should be placed at the bottom, where the user can consciously scroll down and read more. If this is a dashboard view, the KPIs should be set from left to right, top to bottom, in the order of importance. This is a standard that UX specialists follow as it is in line with the eye's natural movement when we look for information. Also, consider different reading practices adopted by audiences in different geographies.<\/p>3. Graceful acceptance of criticism<\/strong> As discussed already, quality gate selection and implementation is a journey rather than a task. This is because we may have to listen and adapt to feedback from the audience to make necessary changes to help them achieve what is expected of them. What may seem perfect now may not be so after six months into the project. The stakeholders will need to bring in more quality gates or take off some that they feel unnecessary to maintain the flow of work. Therefore, we will have to practice a high level of maturity while receiving feedback and negotiations.<\/p> 4. Personal preference<\/strong><\/p> Go with your gut when it comes down to selecting, implementing, and representing quality gates. There could be situations where a quantitative indicator is better than a qualitative indicator and vice versa. You may have to ask the questions: What is my audience's confidence level in me? Will my audience need complete transparency of the decision-making process based on the Quality Gate?<\/p> My recommendation is to always go with the quantitative approach with numbers and trends as a rule of thumb. It is more of a scientific approach to decision-making, relatable to almost any type of audience. But as the topic says, it is indeed a personal preference. <\/p>","section_image":"","table_rows":null,"faq":null,"pro-tip":""},{"section_title":"Is it worth it?","section_content":" As discussed in the sections above, you may feel quality gates are a lot of work. Hence, let\u2019s weigh in the pros and cons. If I begin with the cons, the only trouble with quality gates is that you will have to spend time working on the 4Ws & H, which would need collective brainpower to set up the framework you plan to follow. But once that is done, the rest of the tasks\u2014adhere, monitor, and adapt\u2014are quite simple.<\/p> The main benefit of quality gates is that we take all possible preventive actions to ensure \u2018shift-left testing,\u2019 which is all about practicing a quality-focused mindset from the very early stages of the project until the very end. Shift-left testing guarantees less rework effort and ultimately helps in delivering high customer satisfaction.<\/p> Another attractive characteristic is that quality gates have no restrictions considering the scale of the project. As a QA professional who has been in the industry for a decade, I have been fortunate enough to work on diverse projects scaling from the small web and mobile applications to large ERP applications. Looking back at projects that adopted quality gates and projects that didn't, it is a clear win for quality gates. The domain, scale, technology, complexity are no barriers to implementing effective quality gates, which can significantly benefit the quality and ensure the project moves forward according to the timeline.<\/p>","section_image":"","table_rows":null,"faq":null,"pro-tip":""},{"section_title":"Conclusion","section_content":" To conclude this blog post, I will jump back to my title\u2014the 'fuss' with quality gates. The main idea I want to convey is if you are serious about the quality of work you produce, invest some quality time to identify quality gates.<\/p> Successfully implementing quality gates can deliver many advantages to a software development project. A few are listed below: <\/p> As discussed throughout this article, not only do quality gates control the flow of quality throughout the project lifecycle, but they can also be converted to KPIs. These KPIs can be a handy tool to monitor the quality, a gamechanger for effective decision-making.<\/p> Written by:<\/p>","section_image":"","table_rows":null,"faq":null,"pro-tip":""}]},"yoast_head":"\n |