In this blog we take a look inside the world of the quality gates. In an earlier post we described what quality gates are (link). In this post we will give you some background information for the choices you can make around this topic.

 We’ll split it up in three parts:

-Level of Quality Gates

-Breakdown structure of the checks

-Form of the procedure

 There are many other ways to divide them, butwe took this one because it describes some basic choices and questions that have to be answered before you can start with quality gates.

 Level of Quality Gates

There are some point of views to analyze the level of QG`s. Everyone has his own characteristics. The characteristics workout in less or more work, checks and parties that are involved. The level of QG`s has an impact at the team. The position and the level of detail are two high-level views that have a influence.

-The position of the QG`s has an impact on the quantity of QG`s and the workload. You have two options: you can place the QG`s between different parties or place them between the different phases in a project.

-The first one delivers (most of the time)less QG`s, because there are mostly not so much parties compared to phases in the development lifecycle. This approach results in less control at the details. But if some gates aren`t reached it is possible that you have to do a lot of rework. Maybe you have to do some rework divided over a couple of phases. This approach can work really well if the parties are familiar to each other. And if they do many project together and are know with the quality of products.

-The second option can create more QG`s for one group in the development lifecycle. This is caused by the fact that each phase in the cycle has an QG. Much of these QG`s delivers a detailed view at the different phases in the project.

-The level of detail and the goal of the QG`s can also have an impact at the amount of work and checks you have to implement.

-If the QG is primarily focused on the testing practice, there are checks related to testing. The responsibility lies within the test team and also the execution of these checks. With this approach you don`t have much influence at the other parties, because it is not necessary for them to give commitment to your checks.

-The other way around is to define QG`s for the total project in each different phase. In this way is it a common approach. This approach is preferable because the other parties will influence testing. As a tester or test team you`re part of a bigger team. This team has a common goal. And you can reach this as a team if all separate tasks are finished. Besides that every discipline in the lifecycle knows that a testers can start with the test execution if the application is delivered to him. And he can start with making the testcases if there is the right documentation.
You can imagine lots of other interaction. These interaction needs common QG`s.

 Breakdown structure of the checks

If you implement QG`s you may have to think about the way you need to structure them. If they are structured and work intuitive, the acceptance of the use of QG’s gets better. If you look at them from the test perspective you can use the following breakdown structure, behind this structure each point has different checks.  

-Controls regarding the documentation: define the requirement for the documentation that are part of the test documentation.

-Controls regarding the software and architecture: define the requirements for the custom made software or standard software solutions.

-Controls regarding the infrastructure: define the requirements for the technical infrastructure and the requirements that make that an acceptance test can happen.

-Controls regarding the test that is executed and the testware: define the requirements for the tests that are executed and the testware (scripts, reports and defects etc) that is made.

If you use the project team perspective add some more categories.

Form of the procedure

Make the choice between a formal sign-off procedure or the more informal method; just using a checklist without any management control. Both ways have their pro’s and cons:

-The formal way gives you a good insight in the quality of the products and a lot of management control in each phase of the development. This gives the organization formal go/no-go possibilities.

-The informal approach can work if a team is well disciplined and do their job right. In this case the QG`s are a checklist as a final check. You can compare this with the checklist that a pilot has. He knows how the airplane works and he’ll do his job very precise. But he has to use a kind of checklist to be double secure nothing is wrong. Because the damage is to high if something happened. Hopefully reached our software in the future that maturity level, that the QG`s are only needed for a double check.

 Beside this all, it is really important to anchor this in your organization and processes.

1. How I Lost 30 Pounds in 30 Days Without Diet Says:
   July 23rd, 2009 at 20:48

   Thanks for posting about this, I would love to read more about this topic.