Saturday, 6 July 2013


I spent the last two days at KWST3 and I wanted to capture my thoughts from the event before they escape. I am unsure whether others will get any value from this brain dump!


You can't teach how to test, but you can teach how to ask.

The path to education; Conflict -> Curiosity -> Critical Thinking -> Networking -> Community. When a tester hasn't experienced a conflict that sets them on this path how can we create a catalyst?

How do we offer experiential learning outside of a project context? In a classroom or training course the opportunities for hands on learning may be limited by the number of applications available for testing? Suggestions included basic applications like WordPad, online mazes / games / puzzles, or asking someone with an interest in coding to create a small application for this purpose.

There is risk associated with testing activities; should we allocate resource in a project based on this risk? Although in a scientific context the risk of failure can be great, such as experimenting with corrosive acid, in the world of software the risks can be smaller. When we assign low-risk tasks to juniors, are we robbing them of an opportunity to learn? Perhaps the benefit in them learning from failure far outweighs the risk? Have we become too risk averse at the expense of education?

BBST has a creative commons license, so not only is it a great course for learners it is also one that's accessible to educators for use in their own teaching.

uTest and Weekend Testing are worth investigating!


Passion and aggression are not the same thing. We need to be aware of how our rhetoric, and that of our community, is perceived by others, so it remains challenging without being off-putting.

How to escape a situation where you've reached a "quasi-agreement"; a manager stops fighting you, but instead of accepting your approach they choose to ignore it? When being ignored is jarring and you believe others could benefit from what you're doing, what can you do?

  1. Inception - present the idea to the person with whom you've reached an impasse and then make them think it's their idea. Get them to take ownership and champion further adoption. Requires an element of selflessness, as you will no longer get any credit for the idea taking hold.
  2. Challenging with kindness - question the person until they start to draw their own conclusions. Pull them towards the same answer as you, but get them to take the journey and reach the conclusion themselves, rather than presenting only the conclusion to them.
How to address a situation where you believe that a person is unaware of beliefs they hold that are holding them back or could be used to make them a better tester? Be kind, but confront them about it. Often sharing something about yourself is a good way of prompting honesty in others. Identifying these beliefs and challenging someone to dispel or harness them can be a way of breaking people out of their ruts and setting them on a path to learning.

Testers who do not challenge, question and criticize may be constrained by their culture.

Shifting to CDT

What's more important, maintaining the test scripts or doing the testing? When the answer is always b) then perhaps you need to focus on doing the best testing possible without the scripts!

When shifting to a CDT approach you may notice that:

  • Testing outcomes improve despite deterioration of testing scripts.
  • Testing without scripts finds the issues that actually get fixed.
  • Staff turnover drops.
Stay tuned for the case study...

These thoughts were formed with / stolen from the following amazing people: Aaron Hodder, Oliver Erlewein, Rich Robinson, Brian Osman, Anne Marie Charrett, Jennifer Hurrell, Erin Donnell, Katrina McNicholl, Andrew Robins, Mike Talks, Tessa Benzie, Alessandra Moreira, James Hailstone, Lee Hawkins, Damian Glenny, Shirley Tricker, Joshua Raine and Colin Cherry. A handful are my own.

No comments:

Post a Comment