Note. The reason of this posting is two-fold:

• While considering taking the Rapid Software Testing course I found surprisingly little of feedback information on testers’ blogs, and none of that addressed the questions I actually had. So I’m fixing this issue retrospectively.
• There are too many aggressive pseudo-education “courses” or scamming certification schemas advertised on every corner. I think it’s time for all the testers who care about the craft to start caring about signal/noise ratio. I do it with my personal endorsement.

And here it goes in a question-answer format.

– Why should I take the course if there are a lot of materials available online, for free? 

Yes, there are many articles, blog posts and presentations available online on James Bach’s and Michael Bolton’s web-sites. They are provided in a form of condensed knowledge. They are conclusions. And the course is rich with hands-on, practical exercises, which allowed me to digest the theory and acquire the conclusions as if they were my own. Plus the special exercises giving a chance to try what have just been learnt.

Yet the materials available online served another important purpose for me. Reading them, studying them, prepares for taking of the course at much deeper level, as there are many layers of knowledge there. 

–  What I wish was different?

 The first answer would be the length. I wish it was 5 days long. Some areas were touched too briefly. (Though Michael Bolton explicitly said that he leaves a lot for personal learning, and that’s what I’m doing quite actively). Anyway, if there was a “Follow up RST course” I would have gladly gone for it. Since we don’t have one, I channel my energy into personal learning and online collaboration with likeminded testers, especially at Weekend Testing Americas.

In technical aspects, I wish we talked more about multi-tier, large scale applications. That’s what I deal with at work, and that’s where I see – applying the heuristic-based approach gives especially critical advantages. 

– What this course does not teach?  (and some about what it does)

It does not teach abstract definitions and bookish techniques. However, it teaches to critically assess claims and statements without worshipping to labels and metrics.  This prepares to be comfortable and efficient as a tester in a variety of environments with their unique contexts and challenges.

The course teaches to develop and thoughtfully apply testing techniques as needed and as long as they make sense (dealing with the problem of “best practices”).

The course doesn’t teach testing politics or staff management. However, we were given some effective communication techniques that one can apply in all levels of the organization.

The course doesn’t teach either programming or ‘test automation’. However, Michael Bolton demonstrated some impressive examples on how use of tools and scripts amplifies effectiveness of tests. I’ve also learnt about the ways how an automation developer can increase his value for the testing team. 

– Which part I didn’t get? 

Or, at least, I’m not sure I got it the way it was intended.

This is test estimation part. I know from my own experience, and I totally agree with the concept that nobody really cares about “test estimation” – testing just absolutely must fit the development schedule (“Release date is written in stone!”). That is why, as a contractor, and a test lead, I pretty much do “test budgeting” trying to use the time given most effectively instead of demanding for the time budget based on the estimates. And budgeting time boxes for session-based exploratory testing – I get that. But how to plan “test execution phase”? How to bake in time for investigation of unknown problems and re-testing of unknown number of bug fixes? Possibly, these questions are addressed in “Rapid Software Testing for Test Managers” course? I’m definitely going to take this one. 

– What I found especially challenging in the course? 

The course is called Rapid Software Testing for a reason. Yet, I’m rather analytical type of person. You know – gather [all relevant] information, build a picture (model), carefully review, etc.. Of course, in testing, redundancy of information is a luxury one rarely has. As the course teaches rapid and fallible methods of assessment (heuristics) in conditions of lack of information and time pressure, I felt that my ‘natural habits’ anchor me. This was a bit frustrating at times. 

– Did I feel disappointed in some of my expectations about the course?

No, not at all. In fact, I gained more than I expected. However, I used to see some comments online expressing vague disappointment. With regards to those, I can say – the course is not a magical initiation which instantly turns students into testing experts. Instead, it shows the lead and charges with the inspiration to follow the road of continuous learning. And that’s the most valuable takeaway. 

– What I have gained I didn’t expect at all?

I have read some wide-known books about testing and even much more online article. I heard of the notion of a ‘testing story’ in online talks within the context-driven community. But the course gave me clear and concise points – what is that, why is that important, and even how to do that – telling testing story.

–  To whom would I recommend attending the course?

 Myself, 5 years ago. 

Another answer: anybody involved in software development, especially testers, programmers, business analysts – and their managers.