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. ;)

Inattentional Blindness in action - Anatomy of a testing session

 Inattentional blindness...the phenomenon of not being able to see things in plain sight.  This is how it just happened to me:

Building an exploratory test plan redux: Software cartography

A map is a visual representation of an area—a symbolic depiction highlighting relationships between elements of that space such as objects, regions, and themes. - http://en.wikipedia.org/wiki/Map

Testing software is like exploring new lands.  The same principles apply: There is an unknown something out there, and we want to turn it into a known something.

Putting systems into System Testing

System - A group of interacting, interrelated, or interdependent elements forming a complex whole.  - http://www.thefreedictionary.com/system

People mean different things when they call themselves testers, and people think different things when they think about what it means to test something.  People generally distinguish between unit testing, integration testing, system testing, and user acceptance testing.  But what does system testing actually mean?  Why is it, when we're "taught" about system testing, noone ever explains what a system is?

"Exploratory Testing" is a pleonasm

It's time to stop talking about Exploratory Testing as a subset of testing.  There is no "exploratory testing" and "other testing".  All testing is exploratory.  If it's not exploratory, it's not testing.

Building a test plan from Woe to Go using Heuristics, Mind Maps, and Test Charters

Creating a test plan can be a daunting task, especially when under time pressure.  "We need you to test this application and, oh, we go live next Monday."  How do you create a plan to test that is accountable, transparent, and structured, yet lightweight enough that can quickly be understood by developers, project managers, other stakeholders, and new testers that may be brought on to help out?  And not only that, but be created quickly?

We should be aiming to automate all our testing

You've heard it.  I've heard it.  This is my response:

Don't (explicitly) charge your clients for testing

Software development houses who write bespoke software will usually provide a quote to develop or customise an application.  Often, it's broken down into "Project management, requirements gathering, development, testing/QA, etc etc".  In my experience, it is a mistake to break testing off as a separate quote to give to clients.

Why?