Early in 2016 I attended the the Rapid Software Testing Course which was run, in my case, by Michael Bolton and organised by the Ministry of Testing. Throughout the three days there were numerous resources mentioned by Michael and my fellow course attendees.
I’d been looking forward to this course for years and was very fortunate that DisplayLink paid for my place. Another member of the test team joined me in Brighton for the course which certainly enhanced the learning experience.
If you get the chance to go you won’t regret it.
The course material is made available and can be found on James Bach’s, co-author of the course, website. This coupled with the fact that if you are aware of the work of James, Michael, Cem Kaner, Gerald Weinberg, and Bret Pettichord (to name a few) then you may think there is less value in attending personally. This can’t be further from the truth.
Over the three days there was very little conceptually that I hadn’t read before, but having it explained first hand and with such clarity really helped my understanding of some of the material. In particular I doubt I would have understood session based test management like I do now without the context and real world examples that Michael used.
A secondary, and equally as important, take home from the course was the opportunity of working closely with my testing colleague. It should come as no surprise really that pairing with another tester can bring such valuable insights. Katrina Clokie has a good blog post on the matter.
In one such pairing exercise we used the Heuristic Test Strategy Model to create a product element map of a program we were going to to explore. To create the mind map I used the opensource Freemind. This is defiantly something I will be taking to other testers about, and encouraging more use of in future projects.
It was also good to be reminded of some useful mnemonics such as ‘People Working‘ for bug reports
Problem, Example, Oracle, Polite, Literate, Extrapolate, Workaround
and ‘Midtestd‘ for Project Environment Heuristics
Mission, Information, Developer Relations, Test Team, Equipment / Tools, Schedule, Test Items, Deliverables
So, putting aside all the excellent practical examples, models, exercises, and the learnt experiences of two of the most prominent people in software testing what else did I bring back with me. I’ve listed the ones below that surprised me.
- Bug reports. Yes, really. I’m pretty pleased with my companies bug reporting. It’s been refined over a number of years and matches a lot of what is suggested by the BBST course and this course. But I returned back to work with more ideas and suggestions on how we could be better.
- Changing our language. We have a ‘Test Automation Team’, not for much longer. It will now be called simply the ‘Automation Team’. I also use the phrase manual testing a lot, especially when talking about automation. For now on I will be using ‘testing’. Just as how I don’t refer to programming as ‘manual programming’.
- Note taking. The course really highlighted how important good note taking, while testing, was. I know this, but wasn’t expecting to have it reinforced in such a useful way.
So would I recommend this course? If it wasn’t already obvious from the above, then yes I would. Whether you are just starting on your testing journey or have been around the testing block a few times you will find the information contained in the course highly valuable, useful, applicable, and very relevant to the testing you do today.