Sunday, April 12, 2015

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.

4 comments:

  1. Great post and i will check for this course of software testing . Keep sharing such posts.

    ReplyDelete
  2. Hi, Thanks for sharing this valuable blog.I was really impressed by reading this blog..
    software testing training in mumbai

    ReplyDelete
  3. Nicely explained. Here you described the well written article from your in-depth knowledge. Truly impressive and nice information

    Java Training in Chennai Core Java Training in Chennai Core Java Training in Chennai

    Java Online Training Java Online Training JavaEE Training in Chennai Java EE Training in Chennai

    ReplyDelete
  4. thanks
    https://shipexusa.com
    https://cronvideo.com
    https://videoud.com

    ReplyDelete