Warning: Science Content

As an April Fool’s joke, Google introduced the Gmail Custom Time feature which allowed users to date and timestamp an email being sent so that they arrive “on time, every time”. Google informed users that they could only date messages back until April 1, 2004, the day Gmail was launched due to a temporal paradox (sub classification: grandfather). A temporal paradox is “a paradoxical situation in which a time traveler causes, through actions in the past, the exclusion of the possibility of the time travel that allowed those actions to be taken”. A grandfather paradox occurs where a time traveler goes back in time and kills his grandfather before his father is conceived. It is a paradox because if this occurs, he will never be born, and therefore never be able to travel back in time to kill his grandfather, thus allowing himself to be born. This example is one type of causality loop.

Now that we had our Star Trek lesson for the day, how does a paradox relate to Quality Assurance?

In society, a paradox is “an apparently true statement or group of statements that leads to a contradiction or a situation which defies intuition; or it can be, seemingly opposite, an apparent contradiction that actually expresses a non-dual truth (cf. Koan).”

In Quality Assurance, it is called the “paradox of excellence”. Outside the walls of IT, software development is hard to understand, few realize how hard it is to release software with only a few bugs. When software has lower quality, users will identify and pick up on bugs and other issues with the software. When the software has high quality, users don’t perceive the absence of bugs.

The “paradox of excellence” states that QA doesn’t get credit for issues that don’t happen. When QA does their job right, they don’t get acknowledgement or kudos for the lack of issues in a release, in fact no one notices. When an issue arises and the development team scrambles to fix it, they typically get the kudos for the prompt solution and QA gets the blame for not catching it in the first place.

The typical argument I hear from co-workers is that it is QA doing their job, and they don’t need kudos for that. As a senior executive, how often do you reward developers, project managers and business analysts for delivering a project on time? When the last time you acknowledged the job QA is doing (and not just as a member of a project)?