Across the presentations and discussion we got some interesting thoughts on what other kinds of personas could provoke ideas too:
- putting yourself in the position of your colleagues; testing in the style of others
- putting yourself in the position of some aspect of your own personality
- putting yourself in the position of the software
I wonder whether personas are a way of cutting across testing heuristics we're already familiar with such as SFDPOT and HICCUPPS. Maybe we can part-define certain kinds of users as being particularly interested in some of the areas identified by those mnemonics. For example, choosing to test like a marketing colleague might focus on product claims and (apparent) satisfaction of current user desires but care less about how data flows around the system.
Karo's idea of putting yourself in the position of the software is one I found really interesting. It feels related to the notion of offers that James Lyndsay's recent improv/testing workshop suggested. In that context, the software interacts with the tester by making offers (click on this button, enter text into this field, retrieve some data ...) and, in this one, the software is not only offering but additionally an agent with its own needs. The potential for a perspective change when you're blocked for ideas seems huge.
We talked about when and whether it is important to consciously adopt a persona and then more broadly about the advantages of consciously adopting any approach that you might feel you already just do naturally or is common sense. Once you're aware of it as a technique, you can choose to apply it in certain circumstances, can gain inspiration from the fact that it's in your toolbox when you're after a new angle of attack. If you only have access to something unconsciously, then you're always waiting to see whether you happen across it. Which isn't to say that you shouldn't exploit the stuff that just happens, but try to watch how you do what you do - and how others do it.
My own presentation was on analogy and gave a specific example - joking and testing - that I've been exploring for a while. Analogies are incomplete and so are heuristic, but offer the potential for great value in bootstrapping, building and exploring models of the system under test.
Gabrielle made analogies between particular life skills and experiences and testing. For her, the risks associated with riding a motorbike, and the things she does to mitigate those risks, map well onto risk in the domain of testing; similarly, softer skills such as handling interactions with the various managers she's had at the charity shop she volunteers at.
Both Mike and Liz's talks included the question of where and when testing takes place in projects they've worked on. Giving testers permission to apply themselves in the design phase of a project, and getting buy-in from others on the project, was flagged up. Testing the gaps between stories and testing for gaps between stories seemed to be a couple of places where this is generally going to be relatively uncontroversial and could show how testers can add value.
We touched on the fact that ideas are sometimes kept deliberately ambiguous in order to keep all the stakeholders on board with a project. Each can feel that the thing being built will do what they want while it is still only an idea couched sufficiently vaguely.
The problem of when to try to squash the space of possibilities into a specific actuality was thought potentially difficult and links back to the point above about exercising caution when testing of ideas lest the progenitor of the ideas becomes disillusioned. It was suggested that presenting evidence of the current status and letting the stakeholders themselves recognise the way the wind is blowing might be a useful approach.
The timeliness of an idea and how that affects the traction it gets was something Neil talked about. He gave an example of a simple utility to collect logs and other trace files from multiple locations on a machine after a failure was observed. It was created by a tester who saw a need and taught themselves to code just enough to implement a solution.
The solution was shared with colleagues, who taught themselves enough code to modify and extend it and so on. It not only saved time, but its existence improved the skill set of the team as they inspired one another to do more with it. Management saw the tool and asked for the test team to develop it for inclusion in the product for collecting the same kind of data on the customer side.
An idea nurtured can bring unexpected value to unexpected people from unexpected places along the way. Neil emphasised this by talking about how he's taken the local Lean Coffee meetups format into his own team meetings and got positive results.
There were stacks of things we didn't cover much but might have with more time or had the discussion gone different ways. This is a just flavour of them:
- opportunity costs of ideas. Building a utility, learning to code etc are useful but what else wasn't done as a result?
- sharing ideas. Persuading others that your ideas are worth pursuing. Persuading others that you're no longer convinced by an idea.
- ownership of ideas. Who owns them? Who gets credit for them? How much does it matter?
- meta-ideas. Trying to analyse where your ideas come from and looking for ways to get ideas from other places.
- how to choose between ideas. Often the problem isn't coming up with ideas, it's a surfeit of them.
- prototypes and pretotypes. Getting a physical thing in front of people can elicit more, more useful responses than describing the idea of the thing.
The act of having those ideas, making those associations, creates an environment in which having further ideas is easier. And more ideas means, on average, more good ideas. And I think having a local workshop was a good idea. Let's try and do it again.