Digital Ruminations: QA Conscience of Quality

?A while back I was going over some of the misconceptions around QA, and Quality in general, within the Software Development Industry. From there, ruminations went back and forth and an image of what the role is like came to my mind, QA is the Conscience of Quality.

A bit of a stretch perhaps but, nonetheless, the analogy is valid. A quick definition in Google states that Conscience is “an inner feeling or voice viewed as acting as a guide to the rightness or wrongness of one's behaviour.” Following with the metaphor, in the most general sense, we can map the later aspect to an attitude toward processes, rather than people.

After all, in most situations Quality is nothing but a balancing act between many factors, some of them mutually exclusive. An abstract discussion between right and wrong in a particular situation and context. In the specific case of Software Development, QA acts as the conscience, bringing to the foreground what is right and what is not.

If we were extremely adept to political correctness we would have to rephrase the above as “presenting what could be right or what could be wrong in a specific moment of time, and the particular set of circumstances that surround it”. This because, as we learn more about the product, some assumptions and our understanding of it are bound to change over time.

Bug reports are nothing but nagging about the wrongness of a feature, functionality, or even, perhaps, our understanding of the requirement or how we are building the solution. There is no mandate that states that all bugs have to be fixed. The team, or those in higher places, have more things to take into account before deciding if that whisper of an issue gets dealt with or not.

Let’s not forget that QA comes up with those problem reports after finding, identifying, isolating, and confirming that there is something not-right in there. It is not a whim, or at least it shouldn’t be, it has a reason of being given by the Requirements, User Stories, User Needs, conversations, Acceptance Criteria, the Technology or Business Context, or, failing all that, the reporter’s experience on the matter.

From there comes the incident, the concerned whisper to the team and those above. Like when Jiminy Cricket, from Disney’s animated Pinocchio, warns the animated wooden puppet that what he is doing, or about to do, is wrong. It is up to him to decide if to pay heed, or not.

Of course, decisions in Software Development are not always as easy as “fix” or “don’t fix”. There are various factors to take into account. But by this point QA has already done its job as Conscience; the warning has been given, the report is in the logging system (or tool). Quality and those driving or enforcing it, are now the ones who need to take action.

As time goes by, there might be cases in which we need to remind everyone why certain issues should be addressed, there are always as few places for it or at least there ought to be. Bug Triage meetings, Parking Lot discussions, Grooming meetings, or a Pending Issues report.

Failing all that there is the Daily Scrum, or the equivalent used by the team, where QA can start discussions to get answers or an action from the people present, in regard to what will happen with those problem reports. Even a “not a bug” or an “expected behaviour” note is better than an open ticket. Because the later, will keep nagging you at the back of your head. Like your conscience.

* * *