The Responsibilities of a Conference Facilitator

I have just returned from Let's Test Oz 2014, and like the CAST conferences, operates on a K-Card style facilitation format.

During the three day conference I saw the power a great facilitator can have. I got to experience first-hand the influence a good facilitator can have on the success of a talk, so I would like to offer my perspectives on what makes a good faciliator.

Very Short Blog Post: A date with test cases.

Here's a test case problem:

The requirement:

"Formatting is automatically applied to all date fields (dd/mm/yy formatted)"

 

Here are my findings after a 15 minute test session:

• Formatting is automatically applied when entering dates as

• 12.12.2014
• 12th Dec 2014
• 12 Dec 2014
• 12 December 2014
• 12th December 2014
• 12-12-2014
• 12-DEC-2014

•   Formatting is not applied to:

• 12.12.14
• 12122014
• 12th Dec 14
• 12th December 14
• 12/12/14

a) Did the requirement 'pass'?

b) According to some claims, it is best practice to write one positive test case and one negative test case per requirement. What would I have learned by writing and executing two test cases?

c) Some test management tools would report 100% coverage with 1 test case and if it passed, it would say that the requirement passed.

 

Maybe talking about testing in terms of test cases and of passes and fails isn't useful.

 

 

 

“Anyone Can Be a Tester” - Response

I was pointed to this article on twitter: http://www.morethanfunctional.co.uk/1/post/2014/04/anyone-can-be-a-tester.html by Jari Laakso who has already written a response here.

There are some things I agree with, some things I disagree with, and some things I think are just ugly.

Thoughts around Test estimation

The irony of being asked to provide an estimate as to how long testing is going to take is that, not only is this like asking us how long it's going to take us to find all the easter eggs at easter, but often, it's not really up to us to decide when to stop.

ISTQB: Possum Certification

In my last post, I talked about the concept of possum testing: Doing testing-related activities that the tester does not value, motivated on some level by fear.  I'd like to extend this concept out, and talk about the fundamental problem I have with ISTQB certification: It's a possum certification.

KWST & Possum Testing

(from http://irishchicklette.wordpress.com/2009/02/24/)

This last weekend, I had the pleasure and privilege of attending the first ever KWST (Kiwi Workshop on Software Testing). Seventeen leaders in the software community came together in Wellington to discuss the topic of test professionalism.  You can read about the workshop here and here.  Two very interesting terms came out that Brian Osman had coined to described his observations in the testing profession.  One was stealth testing, which I'll talk about in another post, but the first was "Possum Testing".

"Learn from others' mistakes"

We're always told to learn from others' mistakes.  I read a lot of testing blogs, and take the lessons that other people have encountered and learnt the hard way, and go "phew,  glad I get to learn this the easy way."  But I'm discovering that it's not really good enough, especially when it comes to personal credibility.  I can cite anecdotes from other people and explain why I accept their reasoning and points of view for certain things, but until those stories are mine, and until those lessons are mine, I can't credibly pass those lessons on to others. 

Traditionally, when faced with a situation, I would throw my hands up and go "Nooo, I read about this in Michael Bolton's blog, it's a bad idea cos X, Y, Z!" or "Oh James Bach did a talk on this and why it's bad, let me find it!"  Learn from others' mistakes, right?  Don't repeat them, right?

Well, it may be to the detriment of my own experience.  I'm not seeing first hand the lessons others have learnt the hard way.  So I am now going to consciously try and do things I'm told to do, even if I've read it's bad to do, just to experience it first hand. 

Perhaps I can go into work tomorrow and declare that all our testing should be automated.  Perhaps not. ;)