The four sicknesses of kendo (and software testing)

Posted on Posted in Everything, Kendo, Software Testing

I began writing this entry and almost immediately discovered this entry from Michael Bolton on emotions and oracles, which explains things probably more eloquently than I am trying to. I can’t really speak as to why emotion isn’t valued by some testers. I haven’t encountered any situations where this has been the case – I live a sheltered life, apparently. It seems obvious to me that emotion is a useful indicator when testing. I have no problem testing with emotional detachment, but when that state changes, understanding the reason is important. I haven’t encountered a situation where this would not be the case.

In kendo, there is said to be four ‘sicknesses’ that will lead you to defeat (or the exploitation of which will allow you to defeat your opponent). The four sicknesses are doubt, confusion, surprise and fear*. One could argue that there are many more emotions that you need to pay attention to. I would argue that the majority of them are a reaction arising from one of these four states. Ultimately, it doesn’t matter all that much as long as you recognise that the emotion being provoked is useful to you.

It is important to recognise these states within yourself (so you can correct it), as well as to strive to engender them in your opponent (so you can take advantage).

In terms of testing, the same is true. Whether you are analysing requirements, evolving your test plan, doing the grunt work, reporting or anything in between.

If you are testing something that an end user will use, the sorts of things that provoke these responses in you are likely to do the same for them. If you can recognise when something provokes one of the four sicknesses, then stop and examine what and why. It might be bugworthy, it might just be one of those things you mip, but at least it’s something that you’re aware of. Recognising emotion in yourself is useful for testing.

It’s unlikely that you’re going to cause actual surprise and fear to your system under test, though you might stretch the analogy as far as doubt and confusion. Do something unexpected and see if the system handles it (or gets confused). It might be for example, renaming a binary file extension then opening it in a text reader, pulling out a network cable halfway through a transfer, I’m sure there are plenty of examples you could come up with.

The point is, not only are emotions a useful indicator that something is an issue, they’re also a useful heuristic for creating tests. How might I cause confusion in this system? What is going to scare stakeholders? How sure are the developers that the functionality maps to the spec (or needs to)? Engendering emotion in others is useful for testing.

If you’re not paying attention to your emotions and the emotions of others, then you’re robbing yourself of opportunities to be a more effective tester.

__
* one nerd point to anyone who thought of suggesting ‘an almost fanatical devotion to the pope’, redeemable for one being hit on the head lesson.

Leave a Reply

Your email address will not be published. Required fields are marked *