Let my story be a warning.

About 4 years ago, being a successful test automation engineer, I felt strong enough to challenge James Bach and Michael Bolton, who were loudly advocating for exploratory testing approach and, specifically, a methodology for a structured exploratory testing – Rapid Software Testing.

So I challenged them…

Oh, It didn’t go well. I’m still confident in some of the arguments I made back then, but overall – I was professionally smashed and even lightly ridiculed.

You see, back then, I didn’t realize that all testers must be skilled in rhetoric. And proficient in many other disciplines that can hardly be called “technical”.

What happened next? I didn’t take my defeat lightly. Felt somewhat insulted. And big time inspired for a re-match.

So I came up with a plan: to beat your enemy you’ve got to know your enemy. I will systematically review their methodology, try out the practices, find weaknesses, identify false claims, – then build the case and strike back.

I have been studying and practicing since then. Read hundreds of articles. Took BBST course. Joined Weekend Testing, first as a participant, then stepped up as a facilitator of Weekend Testing Americas. Took Rapid Software Testing course with Michael Bolton.

Somewhere along the way I forgot about my evil plan. Found myself in a camp of the only right approach to testing. Met great thought leaders and made connections in the context-driven community. Career-wise, transformed from the mono testing specialty into broad and deep technical problem solving leader.  While still being a prime lead of the automation practice, proudly carry a title of Testing Practice Lead, often serving as a Test Jumper.

My worries also went through a kind of a transformation.

If back then it was around job security, now I can better distinguish myself: being on both sides of the interviewing process, I know how desperately IT industry needs sharp testing professionals, especially with a vision and ability to lead.

But now I’m worried how much shallow understanding of testing dominates the workplace. Those, who are in great need of visibility into their projects, in great demand for information about how their product would turn out after release, at the same time reject the idea of learning about the product and insist on having only verification of (documented) requirements. Moreover, as the quality standard falls and information technologies at the same time grow into all areas of life, I’m getting increasingly worried about where it goes. And lives it may cost to start taking testing seriously.

For sure, things looked simpler back then. So beware of Rapid Software Testing if you’re willing to stay in your comfort zone.

Or share your story if you stepped up to the challenge.