Comments on: Chess & Testing

By: Rikard Edgren

Rikard Edgren — Sat, 06 Feb 2010 13:19:05 +0000

Rearding analogies, there are no rights or wrongs; so all additions are welcome and good!
But to clarify the subjects I chose, I should have written “Opening Theory” instead of Theory.
In chess it is very important to study openings, and to know exactly which moves you will make, commonly the first 15-20 moves for most games.
If you don’t study this, you won’t reach really good results in chess.
This emphasis on memorizing a lot of details is not applicable to software testing.

Instead of History, I should have written “Classic Games”. I would love if we could have more written details about successful testing projects.
So if you are testing a certain product, the History of Software Testing Expert could tell you: “You should read the test details of project X and Y, their solution will probably inspire you.”

By: Saam

Saam — Fri, 05 Feb 2010 10:53:14 +0000

Nice blog post. I’d like to add some input to the discussion regarding where you, Rikard, stated the following: “In chess the theory says “if I do this, she does that, I do this; and I have a slightly better pawn structure.” To try to do this for testing is flawed, too many elements are unknown.” Maybee I am slightly off topic here, but I think in both cases, testing & chess, it is a matter of how well you know your “fellow player(s)”. “she does that” is based on your expectations that “she” also read chess theory, and that “she” decides to apply it. The better you know your “fellow player(s)” the more confident you will be to rely on your expections, and I think this is true for both chess & testing.

By: Martin Jansson

Martin Jansson — Wed, 03 Feb 2010 13:32:45 +0000

I also disagree with “We don’t have this in software testing, and it is a pity.”. We have quality/test patterns, old risk or what you will call them. We have areas which we always know that developers forget… i.e. Large font handling, File handling etc. I consider this as a historical aspect.

I think we have a lot of Theory in testing. Your anology with opening moves can be seen as our various test strategies. For instance, we open with a build acceptance test, then move on to a more general smoke test… we then dig deeper into the top most risk areas. We also have the theory of always changing strategy in order to see as many faults as possible. Perhaps not able to compare to chess theories, but still.

By: Rikard Edgren

Rikard Edgren — Wed, 03 Feb 2010 10:40:58 +0000

Markus; nice opposite thinking! I guess Weekend Testing is playing, and having fun, in order to learning. I like weekday testing as well.

Zeger; you’re right, and wrong. For Theory it is good with experience and knowledge about other projects and models, but they are vague and give hints, they are useful tools, at the best. In chess the theory says “if I do this, she does that, I do this; and I have a slightly better pawn structure.” To try to do this for testing is flawed, too many elements are unknown.

History – yes, there are some really good books, and there are a lot of papers and presentations about (un)successful projects. But when you come down to the details, how tests are designed and executed, there aren’t so many examples, and those that exist are mostly about failures. And we definitely don’t have textbook examples that describes really good testing that at least some people think are musts for a tester prospect. Of course, the best material for this is probably confidential; maybe we will have a better situation in 50 years.

Here’s a blog entry on History of Software Testing: http://xndev.blogspot.com/2009/03/history-of-ideas-in-software-testing.html

And if you want more on chess & testing:
Blitz Testing at quicktestingtips.com – http://www.quicktestingtips.com/tips/2009/07/blitz-testing/
Jon Bach’s If you want to practice testing skill, play chess – http://www.quardev.com/blog/2008-03-24-1151885966

By: Zeger Van Hese

Zeger Van Hese — Wed, 03 Feb 2010 08:48:32 +0000

Hi Rikard,
I like the chess-analogy. I thinks there’s even more of an analogy with testing than it appears at first. You say that you don’t really see the analogy with regards to “theory” and “history”. But I think there is, in both cases:
- Theory.
You said “a player has a great advantage if he/she knows a lot about how to start games, and the typical positions and strategies that are likely. Since each project have a new starting position, we can’t have this in testing.”
Although I agree that the context at the start of every test project is different, I think that it does help if you have the theoretical and practical knowledge/experience of other projects. That way, you easily recognize similarities and differences between them. You quickly know and remember what worked in which context, what the possible approaches are. This can help you in choosing the right one for your current situation, or at least the one that will be most effective.
- History
You said “When learning chess you study the history, look at classic games that you learn from and get inspired by. We don’t have this in software testing, and it is a pity”.
I think that when learning software testing, we should study and look at “the classics”. Classic, noteworthy books of thought leaders in the field, that inspire you and sometimes encourage you to develop your own theories. We read about how they solved important problems, read experience reports, learn from those I’m practically sure you did all those. No?
–Zeger

By: Markus

Markus — Wed, 03 Feb 2010 08:31:18 +0000

If “Chess is a game, testing isn’t”, well, then we should probably make testing a game, which some people have already realized and started weekendtesting.com .
I think this is currently the closest we have as a “playground” in testing.