QA and the Long Snapper

Last year  I was watching  a Chicago Bears game. Their long snapper, Pat Mannelly,  made a huge blunder that turned the momentum of the game in their opponents favor. The ball was deep in their own territory and  were in a punting situation.  He made an audible to do a quick fake snap as he thought the other team had 12 men on the field. This would have been a penalty on the defense, but the 12th man got off the field in time and the audible backfired.

The conditions and setting were not right for this chance to be taken. They were deep in their own territory and the penalty would have given them 5 yards and would still be 4th down. The reward did not outweigh the risk in that situation.

After the game , he was surrounded by the media asking him questions about the play and the decision. He stated: (paraphrasing here) “Well I must have not done my job very well if you guys are sitting here talking to me.”  The key point is the long snapper is not a flashy, popular position and they go day in and day out executing their role effectively and quietly with little fanfare.

How many of us in the testing field have run into this same situation when an issue escapes into production and has a noticeable impact on the user?  Generally the first question out of people’s mouths is “How did this not get caught in testing?” Nevermind the 300+ CRs you did find and resolved prior to release to production. You generally do not get the credit for going about and doing your job well, but any slip or escape and it gets magnified.

We know that finding and detecting EVERY bug and touching all possible permutations of the systm is impossible.  In the past, this lack of credit for what we did find and thet magnification of what slipped through was maddening and a very high point of stress.

While I still take it very personally when something we have worked on generates an issue, I also realize that we are not going to find them all. In our testing cycles, we need to weigh the reward vs. risk, being able to question what is the most critical and what we feel is less critical.

This can sometimes lead to a missed defect that we overlooked or underestimated its criticality. These still hurt, but are easier to swallow knowing that the team was diligent, thoughtful and proactive in their efforts. You get up, dust yourself up, and work to resolve the issue and then remember this lesson for next time.

I guess my point or thought is, that if you are now just entering this field, be prepared to NOT get the credit you deserve as well as getting the blame you do NOT deserve from time to time.  Know the situation you are in, educate yourself with the skills to succeed and apply them when it counts in critical situations.


About Alex Bantz

Director of Quality Engineering at Salesforce in Indianapolis, Indiana. The views expressed here are my own and not those of Salesforce. I am a proud father of 3 wonderful boys. I have been involved in the field of software testing 15 years as both an individual contributor and in managerial/leadership roles. I enjoy not only learning new techniques but also assisting others in their growth and development and am a vocal supporter of the importance of software testing. View all posts by Alex Bantz

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: