Recently I’ve been revisiting the awesome book Lessons Learned in Software Testing (Kaner, Bach, Pettichord). This book was the primary inspiration for me to begin really learning more about our craft. I wanted to look at various lessons a bit more in-depth and thought I might write about them as a way to drive that analysis. Not sure how many I’ll end up doing, but here goes…
After this one I’ll be doing the old ‘open a random page and point my finger with my eyes closed’ trick. That way I can ensure I don’t stick to my comfort zone.
Lesson 1: You are the headlights of the project.
No better place to start really, and what a lesson to start with. This is very much a holistic lesson as those headlights can (and should) shine throughout the entire project. As I’m analysing this lesson I’ve just started my first Miagi-Do Test Challenge and this lesson was very prominent from the get go. The first thing I did in the challenge was to turn on the headlights, well flood lights in that instance. I’ll write about that challenge in a separate post.
I think analogies have a very good place in testing, well in anything that is not commonly understood (headlights and their purpose are). There are some really dodgy ones out there, and there are those that try to come up with ‘fancy’ ones in order to coin a new phrase perhaps, but this one is solid.
The interesting part for me here is powering the headlights… yeah we can be the headlights, but how do we keep them bright, or how do we turn them on in the first place! This lesson mentions the programmers and managers having the map, or even bickering over the map, but the key is questioning. Who asks the right questions? Who is forever seeking the context? Who asks the hard questions? Who asks the wrong questions? Who? The testers. The questions power the headlights, and the answers determine how bright they are. If you don’t like the answer, or it’s not providing enough light, then send some more power to the headlights and ask more!
There is a also a test of humility in there for us testers. Even though we light the way via seeking of information, we have to remember that we aren’t driving the car… we aren’t paying for the fuel… we aren’t paying the premiums on the insurance policy, etc, etc. So when it comes to the age old question of “should we release this product?” Take a step back. If the driver or the owner does not have enough information to make that choice, then maybe your job as a tester is not quite done yet. To keep the analogy going… the driver has reached a cross road. They need to decide if they go left or right. It’s dusk and they can no longer see the sign that points them in the right direction. What do they do? Take a high risk approach and turn left because it feels right? Or do they turn on the headlights, make the sign visible and lower the risk of going the wrong way significantly?
A quote from Gerry Weinberg in Perfect Software and Other Illusions about Testing:
“Testing can provide information that reduces risk. Different people, different projects, different times, may mean different perceptions of risks and thus different sorts of questions that testing is designed to help answer.”
Notice the use of the word help? Yep, I did too. One little word which is very powerful in its meaning in the above sentence.
Yeah, some will say that it’s an easy choice for the driver because all they have to do is flick a switch and that doesn’t happen so easily in the world of testing… but think about the car battery (middle management perhaps?). As soon as you turn on the headlights the power drains from that point quite quickly, especially if it hasn’t got the support of a running engine. The stress will always be felt somewhere, no matter how simple the scenario seems.
Powerful lesson, but one that is quite simple to achieve (mostly). ;0)