Acknowledgement: My thanks to Lee Hawkins and Lisa Crispin for reviewing my blog before publishing. I really appreciate you providing the time to provide feedback on my writing.
In my last blog Not everybody can test I noted the importance of being able to tell stories about your testing. If you want to people to grasp what you bring as a tester, and what good testers and testing contribute to software development, you must be able to tell stories that are clear, factual and compelling. If you want to elevate testing in the minds of non testers, if you want to see the “manual” drooped from the term “manual testing”, if you want to build a clear delineation between testing and automation in testing, tell stories that do this. Tell stories that have clear context, clear messages and are targeted at your audience (yes this means that one story does not work for all audiences). Perhaps some of you are wondering why I am using the term “stories” when I could say “talk about”, and that’s a fair question. The use of story is a deliberate choice because stories, good stories, are a powerful way of communicating to other people. Consider the following from Harvard Business Publishing.
Telling stories is one of the most powerful means that leaders have to influence, teach, and inspire. What makes storytelling so effective for learning? For starters, storytelling forges connections among people, and between people and ideas. Stories convey the culture, history, and values that unite people. When it comes to our countries, our communities, and our families, we understand intuitively that the stories we hold in common are an important part of the ties that bind.
This understanding also holds true in the business world, where an organization’s stories, and the stories its leaders tell, help solidify relationships in a way that factual statements encapsulated in bullet points or numbers don’t.
https://www.harvardbusiness.org/what-makes-storytelling-so-effective-for-learning/
There are some highly desirable outcomes listed in those two paragraphs. Influence, teach, inspire, forging connections among people and between people and ideas, solidify relationships. So here’s the first check point, if you want to influence how testing is viewed by non testers then you need to have stories and practice telling them. What is a good story? Well that’s up to you really and probably how much time you want to invest in building the story and learning to tell it well. I once asked a guitar teacher how much I had to practice to be a great guitar player. He said when I thought I was great, that was enough but cautioned other people may not hear my greatness in the same way. However before you can tell a story you have to have a story to tell.
Confession time. I write a lot of things that never get published because I can’t convince myself they are good stories. Often I write things where I need to get feedback to clarify that I am not talking nonsense. So I relate to the idea that telling stories can be difficult. I’ve been writing about testing for a while and still have episodes of feeling like an imposter (https://en.wikipedia.org/wiki/Impostor_syndrome). Having said that, while practice hasn’t made me perfect, writing blogs is easier now as I have practiced. Likewise I spent time building and refining testing stories that I can now comfortably use when talking about testing to new testers all the way up to CEOs (and weirdly I can do this without imposter syndrome – people are wonderfully strange).
So let’s set a scenario that I understand is not all that uncommon. You’re a tester, you sit at the end of the development queue. You are expected to gather test requirements, write detailed test cases, execute them (probably at some “average rate per day”) and report bugs. If this is how you explain your testing role, if this is your testing story, you are underselling yourself, and, painting a picture of somebody that could be “automated out of a job”. How might we improve this?
Let’s start with really breaking down what you do (or might do) if you relate to the above. As you gather test requirements for documentation you are looking for problems, ambiguities, statements that simply do not align with your understanding of the project or things you know about the system. So you raise these for discussion. In doing this you have reported issues for examination before they get into the code. You are influencing product quality, you are actively advocating for quality and finding potential problems others have missed. See the difference here? “I write test requirements” versus “I help people improve quality by identifying potential problems before they are coded. This helps my company reduce cost and improve client happiness”.
Have you ever noticed that as you are writing those detailed test cases that you sometimes think about scenarios not covered in the specification (to be honest that’s anything not sitting directly on the “happy path”). Do you take notes about these missing bits of information or add them to the detailed test cases (I used to do the former as I don’t like detailed test cases very much). So you could tell a story that says “I write test cases and execute them” or you could say “I write test cases and make notes about scenarios that aren’t explicitly covered, things that might not have been considered during design and coding. I talk to the BAs and developers about these gaps and then when I test I explore these scenarios for consistency with other similar established and accepted outcomes”. Which story would you prefer to tell? Do you think one is a more compelling story of what you really do as a tester and the value you bring to a quality culture?
Let’s summarise. Telling stories is a powerful way of delivering messages that resonate and have the ability to build relationships and understanding “in a way that factual statements encapsulated in bullet points or numbers don’t”. Sadly though your testing stories have to be created by you. Somebody else could create them for you but then they wouldn’t be your stories and they would lack the authenticity that great stories require. Telling stories is not a “five minutes before you need it” activity (unless of course you are really practiced and have lots of stories to share). Take some time, understand what it is you do that makes your testing work important, create your stories, practice them, refine them and be ready to tell them. I’ve used some very simple examples, and deliberately so, for the purposes of illustrating ideas. So take your time, unravel the complexities of your work, understand your skills and celebrate them in compelling stories.
@Beaglesays 
2 thoughts on “Creating your story”