QA as vehicle inspection

​Even today in many companies the group or department of QA, if any, is still an external component of the projects. People who, when the testing phase begins, are given a deliverable to test and validate.

In such cases, it is usually considered the QA department to play a role of “quality certifier” or “gatekeeper”. The result of the testing phase must be a KO or OK for production or later phases of the project. The equivalent of a seal issued by an external entity certifying that the deliverable item is suitable.

From my point of view, although this approach may be necessary for certain types of projects where the degree of quality requirements are very high, either because of the criticality of the system itself or because of compliance with laws, it does not represent the projects that are carried for the vast majority of companies.

In general, the role of the QA team of being merely auditor only involved in the final phase of the project does not add much value to it.

That is why I think there are similarities between this way of working on projects and how drivers face a vehicle inspection (MOT).

These are different types of drivers we can meet:

Model driver

She enjoys driving, she likes to feel that everything is in order and to feel safe. Always has the car ready, takes care of every last detail, checks the oil and pressure of the wheels on each trip, cleans it by hand every week and stores it in the garage. This types driver goes to the inspection confident that everything is in order and that she simply has to pass that legal procedure to be able to continue driving.

Average driver

The car is a necessary means of transport in her daily basis. She has more worries and takes care of her car as much as possible. She passes the revisions stipulated by the brand and washes the car when she considers it to be very dirty. This type of driver, if she has time and money, maybe should go to a garage before the inspection to check that everything is in order.

She faces the MOT with some uncertainty. She believes that everything is in order and she is almost sure that she will pass the inspection but if she has a slight defect she will try to solve it as soon as possible.

Careless Driver

She has a car because she has no other choice, she owns an old car that barely takes care of and only wants to invest the essentials so she can keep moving and be able to take her from one point to another. She does not worry about oil levels or emissions.

She goes to the inspection knowing that it will be several defects, She will solve in the cheaper garage the most serious defects that made the inspection to fail and repeat this process until she gets the certificate that allows her to continue driving.

I think there are very similar situations in software projects. Since the first two are the most desirable, it is not unusual to find the third one many times. Obviously it is not always the fault of the developers (drivers) to work that way. I would distinguish several situations

  • The “It hurts me more than you”

    Adjusted delivery dates, cost reduction, contract fulfillment, unforeseen events, bad planning are some of the circumstances that can cause a forced and premature delivery to QA knowing that the quality will be low

* The "I need help"

    Similar to the previous point. The development team does not have the means or qualified personnel necessary for the testing phase and passes it to the QA team knowing that they will find errors. They are waiting to receive them to solve them while they advance with new features.

* The "It's your job"

    "You are QA, right? your job is to find errors, testing is your responsibility." The teams that have this mentality (that there is in abundance) go to minimums of quality. They are aware that their product could be better and very possibly has serious errors, but if the QA team does not detect them and gives the version an OK... work completed!. Unfortunately, this lack of professionalism in many cases generates extra costs and greatly delays the delivery dates of the projects.

A QA department should not be a mere quality auditor nor should it make the decision that a version is ready for production or not.

What do you think?

2 Likes

I agree with your analogy @morvader . I have witnessed the ‘throw it over the wall’ mentality towards test on numerous occasions which I think aligns with your ‘it’s your job’ categorisation.

I’ve found teams sometimes need reminding that quality is not just the job of the test department but the entire team. I have thankfully found that framing conversations with language such as, “how can I help you ensure what you are working on is easily testable and has a clear definition of done” can promote a more positive relationship.

This usually results in earlier discussions when work is being defined relating to clear attributes that have to be fulfilled in order for the work to be considered ready to test. I encourage testers to try and educate themselves about the technologies their team is using so they can apply their inquisitive test minds to helping reducing rework for the development team.

It’s usually a slow process but hopefully it can help create an accepted requirement of the developers to ensure they have at least prepared the work for test more than they had previously.

Would be keen to hear about how you are approaching these kind of behaviours?

2 Likes