preload

My Path In Exploratory Testing

Posted by Albert Gareev on Aug 02, 2011 | Categories: NotesNotes

Although it seems like just happened yesterday, it’s been well over a quarter since I took the course of Rapid Software Testing by Michael Bolton (the course is authored by James Bach and Michael Bolton). This is a major milestone in my learning of exploratory, heuristic-based testing approach.

To be fair, I was somewhat skeptical before attending the course. I wasn’t sure what it’s exactly about, and should I spend money only out of curiosity. Ironically, many testers in the community gladly share feeling of excitement about the RST course but I couldn’t find much of specific details. So I didn’t rely on facts but rather trusted the reputation of people recommending the course – and came to what, in my turn, I can call one of the most exciting experiences in my testing career. (I’ll see what I can do about facts, though – stay tuned).

Now this is a good time to look how I got here and where I’m going.

To begin with, I can say that I’m quite successful in the scripted testing domain, but not as a tester manually executing scripts – I work as an automation engineer. I have accomplished large scale (thousands of tests) automation projects; I have met and exceeded clients’ expectations. I designed and implemented my very own hybrid keyword/data driven automation framework; I practice and teach model-based automation approach (but sorry, critics, not a Finite State Machine modeling). I create and enable rapid creation of robust, reliable, and maintainable test scripts.

And yet I often felt uncomfortable seeing all the limitations in testing brought by the very nature of static scripts. In order to create comprehensive automation I explore applications a lot. While asking and investigating endless “what if..” questions I often find important problems (i.e. – bugs). Same happens when data sets are fed into the automation for the first time. But afterwards, when the scripts were developed and ‘frozen’, the automation suite dramatically loses in value. Yes, the same thousands of tests can be run unattended again and again, but testing is not happening anymore. Tests were degraded to “checks“.

Of course, as a creator of once valuable solution I feel sad knowing of what it’s been turned into. I didn’t know what I can do about this problem. Having the RST course taken, and a few follow up talks with Michael Bolton (he is very approachable!), I see new perspectives.

So, what takeaways I have, what new perspectives I see after taking the Rapid Software Testing course?

The takeaways

First of all, let me claim my opinion: context-driven, exploratory testing approach is not “the one approach to testing”, it’s the only testing approach.

Second, Rapid Testing approach is not automation-less at all! There are many ways how tests can be powered and / or boosted by automation.

Third, an automation engineer, if skilled in Rapid Testing, can thrive and deliver high value even in a scripted environment. Moreover, he (or she) can be of great help to the whole testing team.

The perspectives

Automation as a service

Alas, too often automation is seen as a way to mechanize testing and get rid of human testing activities. Hence the first challenge for an automation professional is not programmatical. You must begin from learning about real needs of the project and on the project, and discussing where and how automation can be of help (and where it can’t). Only after you have established understanding of what kind of service automation is capable to provide, and discussed how it is to be integrated into team’s working process, you’re down to technical challenges.

A tester or a toolsmith?

Let’s face it: it’s extremely hard to be everywhere. The time you spend coding scripts is the time lost to testing. But if you love both testing and programming (and proficient in both), the role of a toolsmith might be a good fit. See Michael Bolton’s definition of ‘toolsmith’ here.

Mastering the craft

That’s, probably, a very personal one.

I like to keep my options open. I love to explore and learn. Testing fits perfectly here. Static automation can only do this much – check expected results and serve as a change detector. Tools are limited by context, platform, budget.. Testing must not be. I am, personally, not willing to be limited, I’m willing to go beyond, – and that’s why I’m learning and practicing exploratory testing.


  • One response to "My Path In Exploratory Testing"

  • Dmitry
    4th August 2011 at 16:31

    Thanks Albert, your post has inspired me to continue doing what I have started. Now I am doing my first steps on the road of Exploratory testing with 6 years of real automation testing on background.

  • Leave a Reply

    * Required
    ** Your Email is never shared

Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported
This work by Albert Gareev is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported.