The 5th Birmingham Testing Club Meetup was held last night at the Birmingham Science Park, Aston; or just plain old Aston Science Park to the locals. As ever it was good to relax with some testing fraternity peers and talk about what’s happening in our respective roles, workplaces etc. Typically the attendees are made up of quite a diverse range – often with WAG’s in tow. Although the number of testers has dropped quite considerably since last year, this has turned out to be something of a blessing in disguise.
Small groups make it far easier to experiment and try out different things without fear of losing people at the back or having to deal with large crowd dynamics. I kicked things off by sharing some of my thoughts about the use of Oracles in testing. I’m not going to go into great detail here (though I will try to upload the slides at some stage) – suffice to say that I’m very grateful to Michael Bolton, Kem Kaner & James Bach for writing so extensively and authoritatively on the subject.
We were joined for our discussion by a group of Perl enthusiasts (one of whom appeared to be asleep), and they couldn’t seem to get their heads around the fact that sometimes as a tester, you get asked to test stuff without a formal specification in advance. Even when you do get one [a specification] – just because the product matches it in some way doesn’t necessarily mean it’s fit for purpose. This seemed to mystify them also. The ability to deal with unknowns and pull information from whatever sources (Oracles) they can to guide and inform testing activities is what separates good testers from the crowd in my opinion and, despite their initial reservations, the developers left our gathering with food for thought (and a handful of Testing Planet’s!)
Surprisingly to me though, there was also some degree of skepticism from one or two of the testers present. Test cases must be specified in advance and test results must align with pre-specified expectations! Sometimes I forget that I too have worked in this space, though I’m grateful that I could never quite buy into this philosophy. The BBST material I used to inform our discussion did much to dispel the ceremonial testing myths in our midst.
In essence the game is very similar to the Dice Game which is sometimes used as part of the Rapid Software Testing course. The Master uses a set of pieces to devise a rule with corresponding positive and negative koans. The student[s] must then work towards identifying the rule by recreating it with a koan of their own. Not surprisingly, testers and especially those versed in exploratory testing are quite good at this sort of thing. Much (thoughtful) hilarity followed and a good time was had by all. I’ve posted a couple of pictures below. Definitely the highlight of the evening – thanks Chris!
If you’d like to get involved, come along or have any questions at all, feel free to drop me a line below!
P.S If you're interested in learning more about performance testing, checkout my Performance Testing 101 course here.