Those of you that have not watched Star Trek, are not probably familiar with Kobayashi Maru. Wikipedia defines it like this
It is a Starfleet training exercise designed to test the character of cadets in the command track at Starfleet Academy.
Rescuing the civilian vessel Kobayashi Maru is the notional primary goal in a simulated battle with the Klingons. The disabled ship is located in the Klingon Neutral Zone, and any Starfleet ship entering the zone would be in violation of the Organian Peace Treaty.
The approaching cadet crew must decide whether or not to attempt rescue of the Kobayashi Maru crew – endangering their own ship and lives – or leave the Kobayashi Maru to certain destruction.
Overall you will be put into a situation where you have – seemingly – no-win scenario ahead of you. Test will test how you will handle the situation. As there is no one right solution and you are under pressure, your actions will reveal your weaknesses (and strengths).
My personal Kobayashi Maru (a.k.a. Rapid Software Testing -course)
Last week I spent three days at Rapid Software Testing -course held by James Bach at Helsinki. After the course I realized that the course was like Kobayashi Maru. Lots of different challenging tests that had us go through situations that didn’t have one right solution. We didn’t have to sacrifice our crews, but we had to figure out how we can test our products as well as we can with our given resources.
The tests (or challenges) also revealed a lot about ourselves. At least it did in my case. I was lucky to have some sort of reputation which led to James knowing me in advance. This on the other hand led to me being given more challenges than perhaps anyone else on the course. Someone might see this as a negative side, but I thought (and still do) I was privileged to participate to those. So what did those challenges reveal about myself? At least these things:
- I can control myself rather well when being questioned and criticized (to certain degree)
- Even under pressure I can solve problems
- I’m able to listen other peoples suggestions (by colleagues for example) about solving the problem
- I need to have deeper knowledge of testing techniques (in a level that is available even under pressure)
- I have a habit of forgetting details under pressure so I need to make sure I have resources that help me coping with my weaknesses (e.g. screen recording and notes)
- I need more experience of different testing problems
- I need to create (or find) heuristics that help me perform under pressure and when dealing unfamiliar subject
- I especially need to develop my ability to ask questions that help me perform the task given (this is related to previous one)
- I need to stop making assumptions! (About things that matter)
Assumptions
Photo by Jacob Bøtter. Used under the Creative Commons license.
If there is one thing I want to raise out of the course, that is definitely making assumptions. The problem that I faced again, again and again during my challenges.
I kept thinking about it and especially why I ended up in that assumption trap several times. First I realized that when we are under pressure, we are not thinking logically always about the situation. I mean stopping for a minute and think what we are being asked of. The challenges that I was given – and face in my job on daily basis – ask me to solve something. Before you can move into solving the tasks, you need to be rather confident about the fact that you have understood the given assignment as the one who gave it understands it.
If someone asks you to “test this door”, you need to be sure that the door you are going to test is the one you were being asked to test to. Secondly you want know what the person who asked you to test the door really wants. What sort of information is he interested of? Does he want that through that door needs to be accessed 24 hours 7 days a week? Or that it is enough secure to keep people from breaking in? If you just jump into testing the door, you will make assumptions on the purpose of your testing and the needs of the person asking for the testing.
In the end assumptions are a tempting and easy way of doing your job. It’s so tempting to just go with your assumption instead of having the trouble of asking the questions that will test your assumption. But as testers it is our responsibility to test our assumptions. Because if we don’t do that, who will? How can we held our heads high and look back with confidence if we haven’t saw trouble of testing our assumptions? Think about it the next time you discover you have been following an assumption that led you into trouble. What question should you have asked and what point?
Impossible is possible
McFadden, Strauss, Eddy & Irwin (public relations firm) for Desilu Productions.
Wikipedia tells about James T. Kirk’s attempts to beat the Kobayashi Maru:
James T. Kirk‘s back-story defines that he took the test three times while at Starfleet Academy. Prior to his third attempt, Kirk surreptitiously reprogrammed the simulator so that it was possible to rescue the freighter.
This fact finally comes out in Star Trek II: The Wrath of Khan, as Kirk, Saavik and others appear marooned, near death. Saavik’s response is, “Then you never faced that situation…faced death.” Kirk replies, “I don’t believe in the no-win scenario.” Despite having cheated, Kirk had been awarded a commendation for “original thinking.”
Kirk doesn’t believe in no-win scenario and therefore he will find a way to solve a problem, no matter what. As a tester I want piece of that mentality. We have to respect the laws and act ethically, but otherwise there is a lot room for creativity and bending the rules. Even as simple as asking the programmer if he can provide us a logging functionality for a product. An act that can help our testing a lot but is not an option for several people. Or they don’t see it as an option (“it’s impossible” / “he will never do that!”).
During the RST-course I had several moments where I did not use all my resources. I was too busy trying to figure out the solution inside my head. When instead I should have considered how I can get the answer without figuring it from scratch myself? Who has the information? Who can help me? Asking for help is not sign of weakness (to a certain degree). Not being able to ask for help IS a sign of weakness.
I also gave too much respect on my thoughts about what I can do and can’t do. Who is stopping you to do whatever you prefer (with respect to laws and ethics) to solve the problem in hand? And if you are being stopped, at least you have tried and learned something.
De-Focus!
Last thing I wanted to mention from the course is de-focusing. I’ve found it to be rather powerful technique for varying your testing. First of all frustration is the emotion that
Creative Commons Attribution
triggers de-focusing. When you are frustrated and don’t see progress in your testing, you rely on de-focusing. Find pattern in your previous tests and then violate that pattern as much as you can. Prefer MFAT (Multiple Factors At a Time) and vary your observations as well. Observe for sections that you previously did not. Imagination is the limit here.
I witnessed several times during the course that de-focusing helped to solve a problem and will use it on my work also. It can be as simple as using random numbers or help of a colleague, but breaking the pattern is the point.
Few words about James Bach
I’d like to end my post by saying few words about James Bach. I had heard a lot of things about James and knew his reputation as an aggressive and difficult person. At least that’s the impression I had. Before the course started I had a hunch though that James can’t be as bad as his reputation is. I mean, who would hire him as a consultant?
And my hunch was correct. I felt that James was probably the best teacher I’ve had. Amazing amount of knowledge and experience of our field and also entertaining, but demanding style of teaching. I talk about teaching, but he actually enabled me to learn. I had my hard times on being pressured by him but accepted it as a way to learn more. And, boy did I learn. Still have those moments of hard questioning by him clear in my mind. Because of those experiences I was able to find immediately after the course few critical bugs in my current project.
I hope I’ll meet James again at Let’s Test 2013 along with all the other great testers. All these people like James show me the journey I still have ahead of me as a tester, but also motivate me to surpass them.
Flow of Testing 