Rapid Software Testing with James Bach returns to New Zealand

I count myself as extremely fortunate to have been able to take James Bach's Rapid Software Testing course back in 2012 - it's hard to believe he's not been back to repeat the course since!

If you've never done Rapid Software Testing, I highly recommend it - for myself, it was one of the most influential courses I've taken on software testing.  Indeed use Google and check out other testers opinions of the course - what I've seen has been universally positive and it seems everyone has a different tale to tell.

The course is full of clever insight - indeed, I'm forever going back over my course notes and learning/remembering additional details.  Most of all the course worked for myself as a mirror - it confirmed a few things about the direction I was working in, it suggested a few new ways of working, and I learned a few of my weaknesses.  All these things led to me becoming a better tester.

This is a list of some of my personal take homes from the course,

• Documenting what you're going to test isn't as important as recording/documenting what you've tested #RST  [Indeed this became an important part of our approach here]
• Boundary testing is important, but it's not the be-all. Be sure to check behind them #RST
• Visualise the testing you've done. Are there large expanses untested? Are you sure nothing's hiding there? Maybe check again. #RST
• When you think you've tested all you can. Defocus, and try a new approach to using software. Maybe get someone to try #RST
• Always know the purpose and values of the software you've been given. #RST
• Engage with customers and question them to tease out ways you can aid them better #RST
• A test action which repeats/rewords a requirement has no real value #RST
• An oracle is any method or person which means you have an expectation of the system under test #RST
• Oracles can be fallable though #RST
• We keep a list of expectations in our head about software. It only triggers when something is unexpected. You can't write them down #RST
• Most testing methods feel instinctive. But sometimes we need to challenge & ask more questions to explore other aspects of the s/w #RST
• My main heuristic is thinking how I'd code a piece, and the ways it could mess up if I did #RST
• Don't be afraid to ask for a log file from developers if it makes your #testing easier.  #RST
• But even log files are fallable #RST #dontTrustTooMuch
• The people who most impressed me and who I'd want to work with aren't necessarily the same as ppl the instructor liked #RST #differentValues
• If someone has an idea I feel has value, but the expert disagrees, I need to be braver, speak up & support them #RST
• Experts in testing can advise me.  But as a tester on MY project, I am ultimately master of my own destiny. #RST
• As a tester, I have things I do well, & things I do badly. Build a team around me which balances out my bad & harnesses my good #RST

If you're based in New Zealand, and have never attended, I cannot recommend this course enough.  Fellow tester Kim Engel has been putting in a lot of hard work organising his return in August - and you can find out more about booking here.