Bret Petticord did a presentation in 2003 called Four Schools of Software Testing. I’m not sure if he came up with these himself as I’m heard them attributed to James Bach as well. Regardless, they are an interesting segmentation of the industry; even if the slide deck does seem to be biased towards the school he is a member of.

Lets look at the core beliefs of the four schools as defined by him in case people are reading this offline or via RSS.

  1. Analytical School
    • Software is a logical artifact
    • Testing is a branch of CS/Mathematics
    • Testing techniques must have a logical mathematical form (there is only ‘one’ right answer)
    • Testing is technical
  2. Factory School
  • Software development is a project
  • Testing is a measure of progress
  • Testing must be managed (predictable, repeatable, planned)
  • Testing must be cost effective
  • Testing is following the rules
  1. Quality Assurance School
    • Software testing requires discipline
    • Testing determines whether development processes are being followed
    • Testers may need to police developers to follow the rules
    • Testers need to protect users from bad software
  2. Context-Driven School
    • Software is created by people. People set the context
    • Testing finds bugs. A bug is anything that could bug a stakeholder
    • Testing provides information to the project
    • Testing is a skilled, mental activity
    • Testing is multidisciplinary What I find amazing about these schools is how much people could be categorized by them, and yet not. I for instance land squarely in the Quality Assurance School, but yet have attributes of the other schools in my testing philosophy as well. This isn’t much of a shock as I learned to test in a large bureaucracy.

Using just the attributes listed above, here is a new school.
The Adam School*

  • Testing finds bugs. A bug is anything that could bug a stakeholder. This is a variant of What is Quality
  • Testing determines whether development processes are being followed. While I am not a CMMi bible thumper, it is certainly useful
  • Testers may need to police developers to follow the rules. I don’t like the word police, but I didn’t come up with the original bullets…
  • Testers need to protect users from bad software. Another word I don’t like is passion, but to me, this comes down to being passionate about quality
  • Testing must be managed (predictable, repeatable, planned). I don’t think anyone who has been reading along for awhile is shocked by this one 🙂
  • Testing techniques must have a logical mathematical form (there is only ‘one’ right answer). There is no such thing as a “maybe” bug. I suppose you could argue that it depends on the Context you are in, but if thats the case then specify the context you are presently working with in the bug.
  • Testing provides information to the project. Like ‘the product is ready to ship’

*witty name to be found at some point in the future

So which school are you?