How Japanese Chess has helped me become a better QA person…

Shogi is a game that I used to play with my dad when I was growing up.  My dad noted to me that my logic and my forward thinking/planning was weak.  Yes, he actually said that.  And it was true.  Rather than chastising me, he taught me how to play Japanese chess (Shogi).  When my dad was around and when he was willing to play, I’d always bring the Shogi board around to him and we’d sit down and play.  I not only valued the time I got to spend with him, but I also valued what he was teaching me.  Last year, when I visited my dad, I thanked him for playing/teaching Shogi to me when I was growing up.  I said, the reason for that was to teach me strategy and thinking ahead right?  My dad laughed and said yes, it was.

I was never really good with the game, and my dad whooped my ass big time, even with a handicap.  It did teach me a few good things though.

1) It taught me that you have to keep a good eye on your offense and defense.

2) It taught me how to plan ahead and strategize

3) It taught me to account for things that I do may end up coming back at me.

4) It taught me to try to account for the unexpected

Like in traditional chess, a lot of the moves are similar to some degree.  The difference is a) they are mostly forward moving pieces with a way to promote similar to checkers b) that the piece you take are in your possession to replay against the opponent and vice versa.  I view my opponent as bugs in the QA field.  Bugs are the opponent; developers are the vanquishers of them.

 

1) It taught me that you have to keep a good eye on your offense and defense.

This translates to QA as this… Get your ducks in a row when writing a bug.  You may not necessarily have a lot of time writing it, but if it’s clean cut, short and to the point; it may get attention. 

a) The summary of the title should summarize the bug so that a developer doesn’t even have to look at the steps most of the time to realize what’s going on.

b) The bug should be reproducible.  At least reproduce it once or twice more to make sure you understand what’s going on. or to confirm that you didn’t get into a state that you can’t reproduce.  If it’s not 100 % reproducible , then state it.  A developer may come back to you expecting a reproducible state otherwise.

2) It taught me how to plan ahead and strategize

Like in traditional chess, the more steps you can think ahead and lay out, and also predict the movement of your opponent the more likely you are to win.  In QA bug finding is similar to this.  The more likelihood of you trying to figure out where vulnerabilities, plan testing in accordance, the more likely you are in order to find a critical bug.  This is something I have to blog to show examples of rather than just state.  It’s hard for me to abstract and explain without actually showing.

3) It taught me to account for things that I do may end up coming back at me.

The bugs that I write that aren’t reproducible will tend to lower the respect that I have, so I should try to make sure that I can reproduce it, that my credibility for bug finding is good.  The better the bug in terms of crashing and such will also increase the value.  If I write a ton of small bugs, it doesn’t win me favors from the developers as they might think I am just writing a lot of noise.  Whatever they fix, I will have to end up verifying and testing around (I explained testing around in an earlier blog).  Some bugs might not be reproducible because of the way that the developers fixed another bug.  That’s also possible.  (ie not necessarily because the bug was fixed directly, but the bug could be masked by a fix because you can’t get to the same state as the bug was described.)

4) It taught me to try to account for the unexpected

When the planning and the thinking ahead didn’t go quite as planned, you basically have to be flexible enough to rethink, restrategize, and go with a different action.  Knowing when to do what is always a hard thing in life, and sometimes a bug can be found in the unexpected fashion, whether it be the timing of the bug or otherwise.  I think that’s true of all problems in life.   You never know when a curveball is being thrown your way.

 

Advertisements

About shizen008

Breaking things and getting in trouble for it since '74. Disclaimer: I am not responsible if I make your head explode reading this blog! The writings here are my own expression and not of any companies. I currently work on being a QA for B2G aka Firefox OS
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s