Tag Archives: CDT

Rapid Software Testing – Reading Recommendations

Having just completed Rapid Software Testing twice in two weeks with James Bach, I’m feeling motivated and inspired to continue learning.

Here’s a list of books recommended by James during the course. These will enhance your skills and change the way you look at testing.


The first book may be the most important, and the most difficult to read. I’m still getting through my copy. The content is excellent, and there’s a lot to take in.
The next 4 books are real page-turners, explaining important and complex information is a way that’s enjoyable to read.
I haven’t yet read the last book on this list.

An Introduction to General Systems Thinking by Gerald Weinberg
Thinking, Fast and Slow by Daniel Kahneman
Tacit and Explicit Knowledge by Harry Collins
Lessons Learned in Software Testing: A Context-Driven Approach by Cem Kaner, James Bach, Bret Pettichord
The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully by Gerald Weinberg
Discussion of the Method: Conducting the Engineer’s Approach to Problem Solving by Billy Koen

If you’ve already read these books, I’m interested to hear your thoughts. For example, what was the biggest takeaway you got from each book, and how has that helped you with software testing?


Posted by on August 14, 2015 in Learning, Software Testing


Tags: , , , ,

ER: Learning exercise on the Implicit Principles of CDT

This is a detailed experience report on a learning exercise I completed recently, following my post about James Bach‘s opening keynote at Let’s Test Oz (LTO) 2014:

…There was one slide in particular which I could’ve questioned James on for another hour, called Implicit principles of the Context-Driven School of Testing. This slide contains ideas which could fill a book, if James had time to write another book.. I think I need to read some more books before I can fully fathom the concepts presented! The beauty of this conference is that I have many opportunities to find James in the hotel and ask about this slide in more detail…

On day 3 of LTO I tracked down James and we spent the better part of an hour walking through these principles. Please click on the image below and take a moment to review them in detail.

Implicit Principles of CDT - Slide from James Bach's Keynote at Let's Test Oz 2014

Presented by James Bach at Let’s Test Oz 2014

At first glance I found these Implicit principles intimidating. In hindsight, I’ve attributed this to 3 main reasons:

1. My immediate impression was that the principles are based on a lot of assumed knowledge. I’ve since concluded that these ideas stand alone, and the impression of assumed knowledge was due to the number of unfamiliar terms. In fact the only assumed knowledge is a basic understanding of software testing and an above average English vocabulary.

2. The principles include words which I couldn’t define, such as primacy, non-linearity, cybernetic and authorship. I’ll define these simply here, in my own words:
Primacy – Most important
Non-linearity – Unpredictability
Cybernetic – React to observations
Authorship – Creation

3. I couldn’t understand the reasons behind the creation of these principles. If James covered this in his talk then I missed it. I was wondering what was wrong with the original list of seven basic principles (shown below). I wanted to understand not just the new principles themselves, but also the need for them, and the thought processes that went into creating them. As an aspiring CDT practitioner, understanding this process of articulating the CDT approach is important to me.

Original CDT Principles by Cem Kaner and James Bach

Original CDT Principles by Cem Kaner and James Bach

The Learning Exercise

While discussing these principles with Anna Royzman over dinner, I mentioned that the new list seemed unapproachable for the masses. Anna agreed with the need for a shorter and more simplistic version, which I’ve called the marketing version. Anyone reading the marketing version and looking for more information could read the full version of these principles to find out more context and detail.

I approached James about this on Skype and offered to create a first draft for review, to get the ball rolling. James disagreed with the need for a marketing version of the principles, but he did agree to support me in the process of creating it. I was quite confident in the need for a new version…

Draft 1 of my marketing version

I have to remind myself now that I was proud of this version when I initially created it, while the ink was still wet. I felt that I’d captured the key points from James’ 10 Implicit principles and presented them in a user-friendly way. Here’s what I came up with:

  1. We constantly adapt test processes to changes in our real-world environment (covers point 1 from updated list)
  2. We learn through investigation and present facts based on evidence (covers points 2 & 4)
  3. Due to systems complexity, we observe and react to uncertainty (point 3)
  4. Systems are developed by people, for people (point 5)
  5. Testers have a duty to add value and behave ethically (point 6)
  6. Testers work with the team and share responsibility for quality (point 7)
  7. Testers must continue to learn a variety of skills and practices, in order to adapt processes to suit each project (covers points 8, 9 and 10)

I sent this list to James for review, and we started to review point 1 together. Based on James’ questions and comments, I had a basis to further review my own work. These are my brief notes from that review.

Self-review 1:
2. ‘Facts based on evidence’ doesn’t seem to tie in with heuristics.
3. No longer sure that this sentence makes my point clear
4. Therefore… what?
5. I want\need to do this, it’s not just a duty. This sentence [as written] currently applies to everyone in the company…
6. Sounds like I’m describing Agile testers. “The team” – which team?
7. This point isn’t terrible.

This version is vacuous. I’ve abstracted too far, it could almost be describing procedure-driven testing. Start again…

Taking a Step Back

During Skype coaching James posed the question, “If you had to tell someone a few things that would get across to them the *gist* of CDT what would that be?” This expanded the learning exercise for me, as I’d have the freedom to create a whole new list, rather than devising a simplified version of the 10 implicit principles.

I decided to first work out which concepts were lacking in the 7 Basic CDT Principles, in order to understand the need for the 10 Implicit CDT Principles. I came up with a working list of the differences (shown in the image below, initially without the information in italics).

Comparison of CDT Concepts

Comparison of CDT Concepts

While reviewing both lists so closely, I gained a greater appreciation for the initial list of principles. I really started to doubt the need for a new short version, and I also doubted whether my creation could come anywhere close to the original.

When reviewing some of the differences I’d identified with James, he said something very interesting. His updated list of 10 principles was not intended to replace the original list! Therefore the original list still stands, and my marketing version is redundant. The new list was designed to clarify the implicit concepts which were behind the creation of the original principles.

The implicit principles were created by the main principles…
… I wrote the ten by asking myself what did I mean by the seven and what must necessarily be true to achieve them.

This was my aha moment. Now I understood that there was no need for a new short list. The original list was not being replaced at all, only expanded upon in more detail.


Although I’d started out on a fool’s errand due to a misunderstanding, this turned out to be a productive learning exercise. I can now speak confidently about the principles of context-driven testing and will continue to champion them. I’ve suggested two changes to James which he has agreed with. The first was the re-introduction of the concept of software solving a problem. The second is that community status was not implicit in the original principles and has been added in this new version.

This exercise has prompted me to finish reading Thinking, Fast and Slow by Daniel Kahneman, analysing my own thought processes.
And finally, it helped me to “keep my brain sharp” between contract roles.

Notes on Complex Language

I remain concerned that the complex language used in these principles will hinder the widespread communication and adoption of the concepts.

My concerns are valid, according to this paper by Daniel M. Oppenheimer – “Consequences of Erudite Vernacular Utilized Irrespective of Necessity: Problems with Using Long Words Needlessly”. Essentially, as the level of complexity increases the text becomes harder to understand and less likely to be accepted by the reader.

Oppenheimer’s emphasis here is on ‘needlessly’ complex words.

…there are many times when a long word is appropriate, because it is more precise or concise…
…select the most appropriate word for a given argument such that decreases in fluency are overridden by increases by other positive attributes…

What are your thoughts?

Are precision and brevity (conciseness) more important than first impressions in this case?
Does the original set of principles serve the needs of newcomers adequately, lessening the need for the new version to be approachable?


Posted by on October 7, 2014 in Software Testing


Tags: , ,

Preparation for the Rapid Software Testing Course

In June this year I will be attending the Rapid Software Testing (RST) Course with James Bach, through Testing Times in Australia.

To say I’m excited is an understatement. I have high expectations of this course, based on many excellent reviews that I’ve read in blog posts from testers whom I respect.

What do I intend to achieve from taking the RST course?

  • Improve my testing skills, and add new skills to my testing toolbox
  • Explain my approach to software testing in a professional way
  • Discuss and debate various testing approaches with confidence
  • Approach unexpected challenges with confidence
  • Regularly re-prioritise my testing efforts towards areas of highest risk
  • Learn to grasp the key elements of new concepts quickly
  • Improve my critical thinking skills and questioning skills, particularly when faced with illogical statements that appear reasonable at first glance
  • Write a blog post discussing aspects of the question in my blog URL: Is it good enough yet?

This is quite a list of things to expect from a 3 day course on testing!
From everything I’ve read about this course from past attendees it is also completely achievable, which makes this course unlike any other.

Why didn’t I ask my company to send me? 

This question came up on Twitter. Adding course cost, international flights and 4 days off work including travel time, RST costs a lot of money. Yet I’ve chosen to send myself to the course. Why?

  • Fear of being told no if I had asked my company to send me (i.e. I fear I might find out that I work for a company which doesn’t recognise the innate value of this course)
  • Lack of confidence in my negotiating skills (James Bach is not usually mentioned in a positive way at my company, so I suspect that I’d have some convincing to do…)
  • To prove to myself that I take my career seriously
  • Knowledge that this is a worthwhile investment, and excellent value for money

How am I preparing for the course?

Wow. This started as a short list, and the more I researched, the longer it grew. If I do even half of the things on this list I’ll be a much better tester, without even taking the course! I need to remind myself that they don’t ALL need to be done in the next three months, and practise prioritising.

  • Read some blog posts and resources on
  • Read blog posts about RST experiences (- tick)
  • Lessons Learned in Software Testing – flick through it again
  • Read RST slides and appendices
  • Keep playing the dice game
  • Basically try to prepare myself so that James can’t catch me out. Then acknowledge and accept that I will be caught out, that I will feel uncomfortable, and that I’ll learn something from it
  • Read ‘Thinking fast and slow’ (- in progress)
  • Read ‘Explore It!’ and practice as I read (- in progress)
  • Learn about experiment design
  • Watch 7 Samurai movie (?? This came from David Greenlees)
  • Read “Things that make us smarter”
  • General Systems Thinking – read it again
  • Bill Anders (Also from David’s blog post. “Failure is not an option”? I need to do more research here)
  • Learn some basic Ruby. Everyday Scripting with Ruby: For Teams, Testers, and You, by Brian Marick
  • What are Decision tables?
  • Practise drawing State Models
  • Brush off my dusty Unix shell scripting knowledge (I hope it’s still in there somewhere)

What do I need to remember most during the course?

  • Don’t be afraid to fall into a trap and learn your way out of it
  • Ask for help when you need help
  • Ask questions when you need more information
  • Verify or state your assumptions
  • Don’t get defensive
  • Don’t take anything personally

This post was written by me, for me. If you’ve also received any value out of it – awesome! Let me know in the Comments section.


Posted by on March 16, 2014 in Uncategorized


Tags: , , ,

Context Driven Testing in a Bureaucratic Environment

After taking the Black Box Software Testing (BBST) Foundations course, I decided to try taking a CDT approach with my next project. As it happened, my next client project was part of a larger Enterprise release, at a large bureaucratic organisation, with multiple other test teams already using established testing processes and procedures.

I was brought in as the Test Team Lead with 2 Test Analysts. On Day 1, the Programme Test Manager (PTM)  handed our team an incomplete and out-of-date requirements document, which had been prepared by the development team and signed off by the business (yes, really). This document had been approved by all stakeholders, despite the most pertinent section of the document consisting of only a heading, with no content. This is when I really understood James Bach‘s comment about testers having a super power – the ability to read.

By lunch time I was asked by the PTM how many test cases my team would need for this release. I protested the futility and absurdity of the request (I was more diplomatic at the time). Why is the number of test cases a useful measure, when tests might take 10 minutes or 2 days to execute? If we do write a certain number of test cases, won’t that number be ever-growing anyway as testers learn more about the product? How can I predict total number of test cases using only an incomplete requirements document? But in the end, a number was needed, so I offered to make up a number – 300 test cases. I was frowned at, and told that a more complex product in the same Enterprise release had predicted only 250 test cases, and that surely we would need less than them. I changed my answer to 200 test cases and that got a smile. I felt that I had given the right answer. But my CDT approach was not off to a great start.

Note: I first presented this information at OZWST 1 in the form of an Experience Report.


Posted by on August 20, 2013 in Software Testing


Tags: , , ,

%d bloggers like this: