Egoless Testing

Posted: August 28, 2014 in Random Ramblings

I recently popped my head into the public speaking space to give a lightning talk at the local (i.e. Brisbane) Tester Meetup.  It’s a rare occurrence, but it was generally well-received, so I thought I would etch my words of wisdom onto virtual paper (for posterity).

About three years ago, I read one of Gerry Weinberg’s more well-known books: The Psychology of Computer Programming.  Tangent alert: do yourself a favour and take a look at it.  While aimed at programmers, a surprising amount of it is still relevant for testers.  For a book written over 40 years ago, it was a very prescient and still insightful look at how software development teams work.

Amongst the cornucopia of topics discovered in the book, the concept of egoless programming was especially striking (in the non-violent way).  An attempt to address the “problem of the ego in programming”, Weinberg cites the example of John von Neumann (one of the earliest programmers), who continually sought others to check his programs for errors, omissions and “clumsiness”.

It’s an instructive little section, and I immediately began to think of it in terms of testing.  Egoless programming appears quite common these days: a Google search shows plenty of sites referring to the concept (particularly the “ten commandments” of egoless programming), and the code review in an Agile sprint appears the formal successor to Neumann’s persistent reviews.  But “egoless testing”, so to speak, is perhaps not as prevalent in our thoughts and deeds as it might possibly be.
There are three scenarios that come quickly to mind where egoless testing may yield large benefits.  They are common, every day episodes in our testing world, but in many cases we fail to handle them particularly well.

  • Not thinking to review their work with others.  Possibly a by-product of being a “lone tester” (though it could happen to any tester), the thought of having someone look over their work just doesn’t occur to them.  It’s not part of the organisational culture, it’s not a personal work habit, and so it slips by the way-side.
  • A self-imposed expectation to think of everything test-related.  People declaring (perhaps explicitly, perhaps not) themselves “testing authorities” and thus free from the need of having grubby hands (especially those non-testers) paw at their work.
  • Under too much time pressure to review their work with others.  The classic “death march”, “no time to chat” scenarios that often plague testers.  It’s not that they wouldn’t like to have their work checked, but they’ve got to have at least 78 test cases executed by close of business, the test report (in ISO-29119 format) written by tomorrow morning and the requirements review for next sprint done by Friday afternoon.

Enter egoless testing.  If we used the “25 words or less” format that cereal boxes were once so fond of applying to competition entries, it could possibly be summed up as this: actively review your work with others, and do likewise for them.  But being the verbose character I am, the following is a slightly more voluminous list of concepts that have been largely distilled from Weinberg and flavoured with a dash of testing perspective.

  • Don’t identify or confuse yourself with the work.  Good testing is difficult, and we won’t always get it right.  There WILL be omissions, errors and clumsiness in your work and that is completely natural.
  • In the research / exploration / test design stages (however you do this), actively seek ideas from others.  Even if you think everything is covered, it probably isn’t.  I’m fond of citing an example where a university student with minimal testing experience gave me some great ideas while testing a banking application.
  • Once you have some test ideas or test notes, get them reviewed for errors, avenues for deeper investigation, gaps in your testing or ambiguities.
  • Having work reviewed can be either a very formal or very informal process.  See below for some ideas on how this might be conducted.
  • Don’t limit your review panel to other testers.  Developers, BAs, product managers and users can all provide major insights into the product and your testing of it.
  • Having your work reviewed is going to take time, but the benefits that can come from it will often far outweigh the overhead.

When we do this, we’re effectively addressing any ego-driven problems that could adversely impact our testing.   But not only is our testing is improved, our skills are also developed as we’re exposed to new ideas and different ways of doing things, not to mention shining a light on the blind spots that haunt the edges of our thinking.  We also build rapport with the software development team.

When it’s couched in such glowing terms, egoless testing sounds fantastic!  So naturally you’re going to want to start practicing it as soon as possible.  And when it comes to that, there are a few options available.

  • Pair testing.  One could argue we’re practicing egoless testing simply by working with someone else, as a feedback loop for each person naturally occurs as the session progresses.
  • Conversation and reflective questioning.  Talking through a tester’s work not by criticising, but gently probing their thinking and approaches in order to help them “self-discover” any weaknesses or gaps.
  • Using a program that has a “review” step (e.g. JIRA).  A more formal method, it can nevertheless be useful for prompting team members to review each other’s work regularly (though by making it a procedural step, reviews may devolve into “tick and flick” exercises).
  • Walk-throughs of tests and/or test sessions, which could be either retrospective or in advance, for those who still favour more prescriptive testing.

So, maybe you’re not an egoless tester yet.  Or maybe you occasionally do it when you have the time.  However often you’re doing it, take it up a level.  Help others become egoless testers. Find new or better ways of doing it. And why not try this tomorrow?

  1. majd says:

    This is a very nice suggestion to try egoless testing. We did have a practice of test plan / test case review in one of my old teams where one member would explain the tests and the rest of the gang would give suggestions to improve them. But yours is a more planned out approach and I’ll try some of the stuff for sure.

    • Thanks Majd,

      I like your suggestion, and there’s nothing wrong with that kind of (what sounds like a) semi-formal approach. In fact, I tend to favour that style: formalising things can start out well to help people get in the swing of doing it, but it can end up being “something else we just have to do” in the process and lose some of its value.

  2. […] Egoless Testing Written by: Dean Mackenzie […]

  3. Kim Engel says:

    All the little side comments in brackets at the start make this difficult to follow. Glad you found some rhythm halfway through…

    Testing Rocks! 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s