Here’s an extended quote from the book “Steal Like An Artist” by Austin Kleon:
Every artist gets asked the question,
“Where do you get your ideas?”
The honest artist answers,
“I steal them.”
How does an artist look at the world?
First, you figure out what’s worth stealing, then you move on to the next thing.
That’s about all there is to it.
When you look at the world this way, you stop worrying about what’s “good” and what’s “bad” – there’s only stuff worth stealing, and stuff that’s not worth stealing. Everything is up for grabs…
What a good artist understands is that nothing comes from nowhere. All creative work builds on what came before. Nothing is completely original…
If we’re free from the burden of trying to be completely original, we can stop trying to make something out of nothing, and we can embrace influence instead of running away from it.
To summarise, every new idea is just a mash-up or a remix of one or more previous ideas.
In order to test things, you first need to come up with test ideas – this requires creativity! So how do we go about it?
When I first started testing, I was a helpless little lamb, so I didn’t generate test ideas. Rather, I imitated the procedures described in a test plan to the best of my ability. After some time, I realised that in order to develop my skills as a tester, I’d need to be able to generate test ideas by myself.
Unfortunately, I made a huge mistake – my model of a skilful tester generating test ideas was the tester going away, doing some “magic” (thinking based on experience and knowledge of the product), and ending up with a test plan chock-full of good ideas.
I have no doubt now that this model is severely deficient. The problem with just relying on your personal skill to generate test ideas is that, unfortunately, you can’t know all the relevant things, and more importantly, you have a strongly biased perception of what matters about the thing you’re testing.
I have seen for myself the limitations of this model! I remember the first time that I attempted to write a test plan; I went away, read the spec, read some RFCs, and then produced a document that I proudly called a test plan. Fortunately we had processes in place that meant that the document I produced got review from wiser people than me, and they helped me to do a far better job. Crucially, the thing that made the test plan better was the collaboration involved between different people in order to generate good test ideas.
So, what do we replace this model with?
My current model of how to effectively generate test ideas is to be a thief. And I’m not talking about stealing like the occasional shoplifter, but rather I’m talking about stealing rapaciously as if your very life depended on it! I’m talking about stealing as shamelessly as a pirate! I’m talking about employing every sneaky trick you can think of in order to steal the ideas you need!
For example, if you’re attempting to generate test ideas for testing product P, you could start by interrogating every possible stakeholder until you’ve extracted every useful idea from them that you can.
Suppose developer D wrote the spec – you should 100% organise a meeting with them until you know everything that they care about (regarding product P) and all the test ideas they can think of. And if coder C wrote the code, you should do the same to them. Has tester T tested product P before? If so, plunder their brain until you’ve stolen all their best ideas. Do you know what the customer cares about, and how they’re going to test product P? If not, make it a mission to ensure that you know that information, stealing as appropriate.
You can put this model into practice today! The next time you write a test plan, start by making sure that you probe deeply into all the ideas that all the relevant stakeholders might have. Then let your brain do its magic by remixing and synthesising all the ideas, and marvel at the test plan that you will create.