Tag Archives: QA

Lessons Learned from a 5 year old

This is in honor of my son, Jack, who turned 5 today. If you are in the testing field and you are interested in the world of patterns and perspectives, there is nothing quite like trying to detect those of a curious and creative toddler.

Here is a pic of Jack at his first White Sox game last year:

Perspectives: Everyone has a different perspective in life and that is definitely true for my son Jack. I wish I had time for a ton of examples, but am amazed when we have a similiar experience and/or encounter and I take it a certain way and then days later Jack will bring up that same moment with a completely different take on it. It makes me really think about my perspective.

  • Default: We discussed this in James Bach’s Tutorials at StarWest 2010 and is something that I have been trying to actively work on and remember to not be biased and stuck with my initial thought/reaction to a subject.
  • Historical: Learn from history and past actions and consequences.  When we are in the beer/wine aisle, he will ask if all the beers are mine as I am a beer drinker. When we are buying wine he knows that white wine is for Yia Yia (my mother) and red wine is for Abu (my step father). He knows that he has seen his Nana (my mother in law) drink both so knows either one could be for her. Although I every once in awhile throw off his pattern by having a glass of wine. So be aware of the exceptions to the rule you are working against.
  • User: Thinking from a user’s perspective: I can’t imaging a toy builder or game creator for kids could possibly think of the various ways in which my son “enhances” the game or what he decides to do with the toys he does have. In many ways, it is similiar to the application my team and I are currently responsible for testing. The permutations and ways in which our users can utilize the application is nearly infinite.

Patterns: And when detecting patterns, you learn a lot playing a board game or even a made up game using his matchbox cars and a race track.  They have a tendency to fit and evolve to enhance his chances of winning, but are generally consistent and plays within the set of his own rules that he come up with.

For example, the latest was if your car landed in a certain spot, you would burn in hot lava. But finding the boundaries where the hot lava stopped  and you were safe was very specific in his mind even if it was not to me.

I really just wanted to celebrate my son today, but this topic has been on my mind as i am really digesting and digging in to perspectives and patterns and continuing to drive my own education in the field with the help of others.

Conclusion:

  • Be careful of relying solely on your default perspective and allow yourself to think differently or how someone else might perceive the same problem.
  • Don’t be quick to force a pattern to be there as while it may look like the pattern, you might miss out on the bigger picture.
  • As well, learn from past successes and mistakes, there is always room to improve and learn.  have you seen this problem before? how did you resolve the problem before? what steps can you take to prevent similiar problems in the future?
  • Think of what the users can and may do with the application and not just what the functional spec or any documentation states. There is a great chance they will use your application in ways you never would have imagined.
  • Think like a 5 year old – Don’t constrain yourself by conventional wisdom and how it “should” be.  Obviously that is simple, but don’t let bias and what others tell you how something is, keep you from exploring and finding new ways to do something.
Advertisements

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.