So What?
In that last post, I tried to roughly describe what software testing is, but when I first did so, I wrote:
Writing Test Plans...Write Tests...My co-author Isaac said, "I don't do those things!" I said, "bull feather!", because as one of his employees, I know what he does. He totally writes high level plans. He did it with a 'war board' strategy a few months ago. And what about that story for updating the tests we have documented? He begrudgingly agreed he did so, but that he HATED those words as they bring up a very different idea in his head. An idea of these extensive documents that go on and on. He basically couldn't (easily) get out of his head his own idea of the connotations of those words.
Now, you might notice those words were edited some, because I too did not want someone to read that and apply something more detailed than I had intended. The problem is, the activity, any way I might describe it, is either going to be too heavily attached to MY context or so generic as to be meaningless. This goes back to my Context Driven Test post, however, I'm really not trying to talk about approaches too much. So, what is someone to do?
Please allow me to go on a small tangent for a moment. I have a pet theory that we, that is to say, the human race, is story driven. We tell each other stories all the time, and we are engaged by stories but not technical details. Only a few of us can even deal with technical details, but almost everyone loves a ripping yarn. That is why agile and people like Joel Spolsky tell you to try to tell stories, even for technical people. I may write more on this later, but just think about it a little.
So how do I communicate to you, my audience? Using a story driven system, without either inserting my own language or context, to avoid using words and concepts you already have attached meanings (your context). It is much easier for me to avoid those words using analogies than it is to struggle to shake off your preconceived notions about a particular word. So, what if I tell a story with my analogy? Let us consider a example:
When legislation is written, multiple parties participate. At first, the city mayor notices a problem; there are too many stop lights being installed that are imping the flow of traffic. Like a business person, she sees a solution, which she proposes and brings to the attention of the people who would have to perform the fix, the local road development dept. Maybe the solution is installing roundabout in newer streets so that traffic need not stop. The road development crew might create a detailed plan, and to validate that the solution is feasible they pass their plan to another dept. In legislative terms, the solution might go to a feasibility study dept, and like QA, they test the solution, to see if this is even possible for the newer roads, given the budget, etc. Computer simulations might be created to verify the fix, testing the traffic flow, verifying that the road ways will work. Accountants are contacted, the legal dept might get pulled in during the study. Even if it gets past this point, you might raise the proposed solution to the citizens, much like deploying to beta, who may note that they don't want their yard taken up by a roundabout. Perhaps the ordinance gets some modifications, going back through the process with the addition that it won't include residential areas where stop signs would better serve. The mayor and her constitutions are happy to see an improved road system....
If you are in an area where the local government doesn't do these sorts of activities, the story will likely not work. So let's consider a very different story from a different story teller:
Well, when I create software, I think of the developers as Jedi, who when they have completed a feature, pass it on to the Emperor of QA, who orders his team to start on order 66 and find every last issue in the feature without mercy. Next thing you know, the developers are struggling to survive under the weight of all those bugs.
Lets consider these two stories. In the first case, I was attempting to describe a process and how that process worked using a comparable process. My coworker would have likely not objected to that as an example of 'what development is like' as it would not have used words he disagreed with. Now maybe he would have gotten caught up in the details and argued about how legislation really works, or pointed out flaws in the analogy (technical people tend to do this), but it would have been easier for us to not get stuck in the weeds. Even if he did so, it would be more likely to be clarifying remarks rather than argument about what activities we really do.
In contrast, the other story is about how feelings, how someone felt. The process details are less than clear, but it doesn't matter (to the speaker). If you know Star Wars, you will know the story teller sees QA as the bad guys, creating more issues in a unfair way. Perhaps to a person who hasn't seen Star Wars, this wouldn't be a useful story, but to someone who has, it would be easy enough to pick up the gist. The problem is, without interconnecting the details of what the environment is like to the details of the story, it becomes unclear just how far I should take the analogy. Is this a whiner or is there really an issue? Is this QA's fault or management? Is this one person, the QA manager (or the story teller), or is it entire teams?
In this sense, an analogy is a tool, used to help create a picture and a conversation. The risk with an analogy is that either the audience doesn't understand the analogy or that the reader take it too far. Analogies, some of which are referred to as parables, have been around since the dawn of story telling. We preach morals, teach and inform with them. Why? Well the reason is because when you learn something, you take what you already know and extend it slightly. With that in mind, my attempt to consider software development like something else comes down to me attempting to extend my knowledge of one subject and make it like another, comparing the items, attempting to learn new truths. This concept is sometimes referred to as "System's Thinking."
Isaac after looking at a draft of this said he thought the TL/DR was "Tell stories." While I won't disagree with that, I think a second bonus TL/DR is to keep your mind open and look for things you can learn from in areas you aren't a specialist in. If you twisted my arm for a third TL/DR, I might add that this entire blog is my attempt to learn via the process of teaching. So here goes:
TL/DR: Learn by teaching using stories.
No comments:
Post a Comment