Quality Assurance as Policemen

At the French border, 5 Belgians, travelling in a Quatro, were stopped by a French Policeman. He told them that Quatro means four and since they were 5 Belgians, he would have to fine them. The Belgians were aghast and told them that Quatro was a five-seater car and so what was the problem. They took out the manual and showed it to the French Policeman. The French Policeman did not agree and said Quatro means four and so it had to be maximum four. The Belgians abused the French Policeman and told him to call his Boss as he was stupid. The French Policeman told them that it was impossible as his boss was dealing with 2 Italians travelling in a Uno.

This is just a joke and not reality. This is not a real incidence. However, I use this to drive the below discussion.

Have you ever come across a Quality Assurance Department modeled in the way of the French Policeman? If yes, how did you deal with such a Quality Assurance Department? What methods did you use to remodel such department?


  1. Dear Mary,

    This is just a joke and I am sure such things do not happen. However, in my work life, I have come across quite a few instances where someone has tried to follow the book according to his/her interpretation and not understanding the spirit of what has been documented.

    I will give you an example. See if I am making sense.

    We had an agreement with Reliance to supply changes to the supplied systems every month. The appointed date for the change delivery was 28th of every month. So, as a process, we had defined that we would baseline our system in the configuration management tool on 28th of every month. We would not make any changes to the system between 26th and 28th of the month. We would create the build from the configuration management tool and conduct regression testing on the same. After the regression tests were passed by the testing team, we would baseline the configuration management tool and supply the build to Reliance.

    However, during the month, we made many changes to the system for 2 purposes.
    1. For enhancement of the product for the new requirements.
    2. For fixing bugs as reported by Reliance.

    When we fixed the bugs, we created the builds and deployed at Reliance.

    Now, we had a new Quality Assurance Manager. His first objection to our process was that whenever we made a release to Reliance, we should baseline the system. This was required even if we had to do this 10 or 20 times in a month. The logic was that every release made to the customer must be baselined. As a concept, he was possibly correct. However, our understanding was that this was not practical. Moreover, we proved that there was no risk to the customer in our present practice as we had an extensive documentation regarding every change made in the system. Thus, if something did malfunction, we could rollback that bit without causing any impact on other intermediate deliveries. Also, we always conducted smoke tests before any intermediate release. There was no risk to our organisation as well we were doing precisely what we had documented as a process and thus not violating the quality process.


Request you to kindly leave a reply.

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: