(Almost) Everything I Know About Testing I Learned Playing Poker

When I was in high school, I always enjoyed weekly poker games with my friends. Little did I realize back then that those weekly matches were preparing me to be a software tester.

As I began my software testing career, I realized that many of the poker skills learned years ago in my youth are similar to skills I need to be a good software tester.

Assessing the Situation

When you sit down at a poker table, the first thing you do is size up the competition. It’s very important to know their skill levels, i.e., are you facing someone who has a World Series of Poker bracelet, or is this the first time they have ever played poker? Similar questions need to be asked of your testing team; do you have anyone who is a seasoned tester, or is your team made up mostly of analysts who have been “stuck” doing testing?

Next, risk assessments begin almost immediately: Do the players at the table with you pose a risk? Do you think the two cards in your hand have a chance to win the hand? What is the risk if someone has a better hand than yours? What is the risk if you bluff and get called? Thus, good poker players are constantly doing risk assessments, as are good software testers.

In poker, resource allocation (betting with chips) is easier when you’ve done a solid risk assessment that includes the cards and knowing your opponents. Similarly, in testing, it helps to know how much business, testing and technical knowledge each team member has so you can allocate resource efficiently and effectively.

As more cards are dealt you can begin predicting hand outcomes: What hand do you think you will end up with? What hand do you think others at your table will end up with? Have your risk assessments changed? Can you predict the quality of the next code drop? Using various tools, the answer is a surprising yes. Having this information can help improve the accuracy of the risk assessments.

Making Your Moves

Now, with a solid risk assessment and a (hopefully) accurate prediction of your opponents’ hands, you can begin planning the rest of the game: What if you receive favorable cards? What if the cards are not nice to you? What if cards are dealt which you think significantly helps your opponents? Being able to plan out what to do in these various situations can be critical to your poker survival – and the success of your testing effort. Can you predict the quality of the next code drop? What are you going to do if the quality is poor? Or great? Over time, predictions can become quite accurate and an invaluable tool in our testing tool belt.

Test Plans are a common document in the waterfall testing world. In the second hand of Texas Hold ‘Em, we use Test Plans to help us reduce the risk uncertainty. But does it work? Do test plans created prior to any knowledge of what is being changed actually reduce the risk? Or increase it?

There are many more skills I have learned in my years as software testing professional, and some have direct correlations in poker, others don’t. The core of what I do every day, however, is rooted in my youth playing poker with my friends. I’m not going to say you should quit your career as a software testing professional and become a professional poker player. But I will say playing poker can definitely help your day-to-day testing efforts, and vice versa.