The ‘Omerta’ of Testers (Mafia)

Show me one tester with a considerable exposure to IT industry, who never engaged himself into “The Blame Game” intentionally or unintentionally with Developers or Analyst.

“Tick, Tock, and Testimony”
Each test team and opponents are asked for justification or tell their side of the story. Old mails are sought out for evidences to prove their point until both were out of time.

“You did It, Now Admit it!”
Now team held responsible will be penalized for committing that horrendous crime

“Jury of your management”
Management would decide to show mercy or no mercy and the convicted to be added to “Do Not Trust This Blame Game Loser”

Let’s not dig deep into what causes quality failures or defects in the production, we are trying to understand lot of psychological problems and people issues that often lead to slinging mud at each other.

After a detailed discussion testing teams from different leading organizations, following are identified as main culprits:

1. DREAD:
a) Fear of missing a bug.
b) An anxious feeling of not able to find all the bugs.
c) A lack of confidence due to nature of our job where exhaustive testing is not possible in the time given.
d) Scared of the no. of possible permutation and combinations that exist.
e) Panicked by the scarcity of time or resources.

2. BALL IS NOT IN MY COURT:
Most of the time testers think only when the build comes to them and during the execution phase they are “Accountable” for the quality. That means they can relax and chill out at the time of requirement, design, coding and deployment. Testing and Production is the only phase they can be held responsible.

3. ACCOUNTABILITY:
If anything goes wrong, testers are usually choked by “The Family” (Dev, Analyst, and Management). It’s not that testers are not accountable for quality but the common misconception is that they are the ONLY discipline responsible for QUALITY against the principle “Quality is the responsibility of each employee in the team”

4. PRESSURE
Even Indian cricket team dies under pressure then think of a testing team shouldering the responsibility of a product that means both business and satisfaction for the end users.

Sometime imperativeness takes a toll on the testing efforts and affects the quality of the effort being put by the tester.

Continuously being bugged by managers often restrict the tester from thinking “out-of-the-box” scenarios and trying out some end user events by putting themselves into end user’s shoes.

5. QUANTITY OVER QUALITY
I don’t know how many times you would have seen that management want to know the no. of bugs to decide upon the performance of the testing team. Priority / Severity take a back seat and Dev / Management shrugs their shoulders to say “Is that all you found?”

Ultimately it boils down to quantity over quality in performance appraisal of testers.

The ‘Omerta of Testers’: STOP the blame game!!!

“Whenever a tester appeals to the management against his fellow developer or analyst is either a fool or a coward. A tester who cannot take care of himself without management protection is both. It is as cowardly to blame an offender to justice, even though his offences are against yourself”

Remember Test and Dev are like wheels of a two-wheeler vehicle and only way to move forward is to make a clear distinction of each other’s responsibility and understanding of most important fact that we are working here as a team and for end user what matters the most is a high quality product at a low cost. The Industry, Client, End users don’t care if it is the dev fault or a miss from testing team.