Skip to main content

Lessons Learned in Rapid Software Testing


Give a man a fish and he'll be fed that day. Give a man a fishing rod and he'll be fed for a lifetime.

On James Bach's Rapid Software Testing course, you are that man, but Bach is not tossing you a fish, nor even giving you a fishing rod, instead he's swinging open the doors of his huge angling arsenal, throwing his arms out wide, gesturing at you to take a good look at the contents and smiling broadly.

Inside there's stuff you recognise - poles, rods, nets, lines, hooks, waders, harpoons, reels, bait trays - and stuff you don't - crazy-looking doodads with springs and dials, big hairy ovals, bags of green seeds, assorted heavy machinery and wispy bits of fuzz. Some might have been used only once, some might be go-to tools for every day.

One wall is a posterboard covered with lists; lists of half-acronyms, lists of instructions and heuristics as long as your arm, lists of reminders, mindmaps with lists and sub-lists and sub-sub-lists bursting out of the centre like catfish whiskers. In the back there's a work bench, littered with the  tools used to make everything you can see and to the side of that a vast library of books on seemingly unrelated topics, each marked up for the nuggest of information that breaks open a new way of reeling one in.

You are stunned and bewildered but Bach is already started with the mantra pinned to the back of the door:

  • You do not know all the answers
  • You know there are many tools that could help you find them
  • You do not know which is the right tool for any given context
  • You have experience which helps you learn which to try and when
  • You have experience, and the use of heuristics
  • You have intuition, and you should codify it when you see it working
  • You need to be self-aware, of your biases, that you don't know things
  • You need to reason and you need to think laterally
  • You need to be ready to try a different approach
  • You need to think about risk and target your effort based on the perceived risk
  • You need to refine your approach based on the evidence you've obtained
  • You may have to test to find out what it is that you are testing (for)
  • You need to be clear about your assumptions
  • You need to ask questions
  • You need to own whatever you create or use

It goes on, and he'll come back to it again and again, extending and refining it, but for now he's turned to pick up a piece of piscine technology, and polish it, and demonstrate it, and, a little misty-eyed, tell you how he used it to land a whale that time, and give you an example of the student in a previous class who used it in an exercise a whole different way, a way so imaginative that you wonder what kind of fish that student had been eating.

Then he'll point at you and ask you a seemingly simple question. And then you'll be doing that exercise and for the next fifteen minutes you might be a fish out of water, wriggling on the end of his hook. He'll gently lift you up and guide you into his keep net, trapped, circling, round and round and round. Until you're battered and then he'll review the whole thing, praising or constructively criticising before moving on.

For the rest of that day, you'll be thinking about the responses you could have given. How his set up and his line of questioning led you down a line of reasoning. How your instinctive answers were not the best answers. How your previous experience counted for nothing in the face of the interrogation. How daft you felt when it became obvious that there was another level of thought that could be applied, and one beyond that. Then, how good it felt to have that clarity of vision, even after the fact. How much you wanted to apply it to a new project right away. How you're already thinking about what you're going to need to stock your own shack with.
I attended the Rapid Software Testing course in Cambridge, March 7-9th 2012. There's a slideshow from it here.
Image: digitalart / FreeDigitalPhotos.net

Comments

Post a Comment

Popular posts from this blog

Can Code, Can't Code, Is Useful

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "If testers can’t code, they’re of no use to us" My first reaction is to wonder what you expect from your testers. I am immediately interested in your working context and the way

Testing (AI) is Testing

Last November I gave a talk, Random Exploration of a Chatbot API , at the BCS Testing, Diversity, AI Conference .  It was a nice surprise afterwards to be offered a book from their catalogue and I chose Artificial Intelligence and Software Testing by Rex Black, James Davenport, Joanna Olszewska, Jeremias Rößler, Adam Leon Smith, and Jonathon Wright.  This week, on a couple of train journeys around East Anglia, I read it and made sketchnotes. As someone not deeply into this field, but who has been experimenting with AI as a testing tool at work, I found the landscape view provided by the book interesting, particularly the lists: of challenges in testing AI, of approaches to testing AI, and of quality aspects to consider when evaluating AI.  Despite the hype around the area right now there's much that any competent tester will be familiar with, and skills that translate directly. Where there's likely to be novelty is in the technology, and the technical domain, and the effect of

Testers are Gate-Crashers

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Testers are the gatekeepers of quality" Instinctively I don't like the sound of that, but I wonder what you mean by it. Perhaps one or more of these? Testers set the quality sta

Am I Wrong?

I happened across Exploratory Testing: Why Is It Not Ideal for Agile Projects? by Vitaly Prus this week and I was triggered. But why? I took a few minutes to think that through. Partly, I guess, I feel directly challenged. I work on an agile project (by the definition in the article) and I would say that I use exclusively exploratory testing. Naturally, I like to think I'm doing a good job. Am I wrong? After calming down, and re-reading the article a couple of times, I don't think so. 😸 From the start, even the title makes me tense. The ideal solution is a perfect solution, the best solution. My context-driven instincts are reluctant to accept the premise, and I wonder what the author thinks is an ideal solution for an agile project, or any project. I notice also that I slid so easily from "an approach is not ideal" into "I am not doing a good job" and, in retrospect, that makes me smile. It doesn't do any harm to be reminded that your cognitive bias

Test Now

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "When is the best time to test?" Twenty posts in , I hope you're not expecting an answer without nuance? You are? Well, I'll do my best. For me, the best time to test is when there

README

    This week at work my team attended a Myers Briggs Type Indicator workshop. Beforehand we each completed a questionnaire which assigned us a personality type based on our position on five behavioural preference axes. For what it's worth, this time I was labelled INFJ-A and roughly at the mid-point on every axis.  I am sceptical about the value of such labels . In my less charitable moments, I imagine that the MBTI exercise gives us each a box and, later when work shows up, we try to force the work into the box regardless of any compatiblity in size and shape. On the other hand, I am not sceptical about the value of having conversations with those I work with about how we each like to work or, if you prefer it, what shape our boxes are, how much they flex, and how eager we are to chop problems up so that they fit into our boxes. Wondering how to stretch the workshop's conversational value into something ongoing I decided to write a README for me and

A Qualified Answer

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn ,   Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Whenever possible, you should hire testers with testing certifications"  Interesting. Which would you value more? (a) a candidate who was sent on loads of courses approved by some organisation you don't know and ru

Rage Against the Machinery

  I often review and collaborate on unit tests at work. One of the patterns I see a lot is this: there are a handful of tests, each about a page long the tests share a lot of functionality, copy-pasted the test data is a complex object, created inside the test the test data varies little from test to test. In Kotlin-ish pseudocode, each unit test might look something like this: @Test fun `test input against response for endpoint` () { setupMocks() setupTestContext() ... val input = Object(a, OtherObject(b, c), AnotherObject(d)) ... val response = someHttpCall(endPoint, method, headers, createBodyFromInput(input) ) ... val expected = Object(w, OtherObject(x, y), AnotherObject (z)) val output = Object(process(response.getField()), otherProcess(response.getOtherField()), response.getLastField()) assertEquals(expected, output) } ... While these tests are generally functional, and I rarely have reason to doubt that they

ChatGPT Whoppers

Over Christmas I thought I'd have a look at ChatGPT . Not to "break" it, or find more examples of its factual incorrectness , but to explore it sympathetically, for fun. And it was fun. In particular, the natural language generation and understanding capabilities of the system are really impressive. However, even without trying it's not hard to expose weaknesses in the tool. So much so that I doubt I would have bothered to blog about what I found, except that I enjoyed the accidental semantic connection between a handful of my observations. I asked for ASCII art to celebrate my 600th blog post on software testing and got this whopper! . .: :: :; ;: .;; .;;: ::;: :;;: ;;;:

Farewell AST

After four years, three of them as Vice President, I'm standing down from the board of the Association for Software Testing . Let me say up front that I am an unapologetic romantic about my craft. (And, yeah , I called it a craft. Sue me.) I believe in what AST stands for, its mission , and in context-driven testing , so it's been an absolute privilege to be involved in running the organisation. It's also been fun, and full of difficult situations and choices, and hard work on top of family life and a day job. There also was the small matter of the global Covid pandemic to deal with. The immediate impact was on CAST, our annual conference , and in some ways the beating heart of the AST. We had to variously cancel, reschedule, and move CAST online and we are still experiencing the after-effects as we organise the 2023 in-person event . So why am I leaving? Well, first, I'm not leaving the organisation, only the board. I am a life member and