We felt the need to follow on from our previous blog on tracking testing results in the background using hidden ubiquitous spreadsheet or documents.  If all you have is a spreadsheet for tracking, then you make that visible to all relevant stakeholders.  If the company has a sanctioned or preferred way of handling “bugs” and we deliberately circumvent that process and tool then we are on a slippery slope.

So what is plausible deniability?  It is when a person can claim they have no knowledge on a particular truth that may exist because that person has been deliberately been excluded from that truth.

According to Ask.com “the term was first coined by the CIA during the Kennedy Administration to describe the withholding of information from senior officials in order to protect them from repercussions in the event that illegal or unpopular activities by the CIA became public knowledge.

So how is passing back the test results discretely between the test person and the developer contributing to “plausible deniability”?  Simple, the project manager is not in a position to know the state of the product under test quality.  The “facts” of the testing and the product’s ability are not readily available for review or critique.  In fact, we must have access to one of the people who in fact have the sheet.  We cannot look at the project test statistics see how it is going. There is no information available for the project manager or the executive management to assess the situation.  We have made it possible for these people to say the product is fit for launch, when it may in fact not be so.  They have no evidence before them to say the product is not ready for launch. There is a difference between using the tools you have at hand to track the test results, and subterfuge, obfuscation and hiding.