Last week in Dublin and Cork, I gave talks on testing the Internet of Things (or everything, depending on who you consult). I want to share a little idea or comment that I made during the Cork session. It seemed to come from nowhere – I certainly hadn’t prepped the comment so it might have come from somewhere deep in my subconscious. But if you know the source and it’s someone other than me, please let me know and I’ll acknowledge them.
You never know with live presentations. I don’t rehearse (ever) so I never really know what is going to come out. To me, presentaitons are really stories, so I know the jist of the story, but it’s different every time I tell it. My talks are always kid of “live” so to speak, and with the adrenalin flowing, I tend to go into autopilot. Sometimes random (but good) thoughts come out in the flow. From nowhere.
Anyway. What I said was…
“In projects, we tend to let the pilot of a plane – the developer – take off with a general heading and let them go. The navigator – the tester – waits at the other end, and after a rather long wait says ‘you were 65 miles off target, and you crashed into a mountain’.
Why on earth do we leave the navigator off the plane? Why do we separate testers from developers? For heaven’s sake, why don’t we put the navigator on the plane with the pilot in the first place?”
This is the best illustration I can think of for “test early, test often” (a mantra some of us have preached for 20+ years). I’ve been calling testers “navigators” for ages, but the new idea was suggesting, by putting testing ‘after’ development, it’s like asking the navigator to wait at the destination.
So, if you are trying to argue for “test early, test often”, “shift-left” or “testers embedded with developers” you might use my “waiting for a plane” analogy.
Of course, you might have heard this idea somewhere else (and maybe I did too, but forgot). Do let me know – I’d like to thank them.