The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.
My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.
Suggestion #53: Ask yourself (and answer) the fundamental questions like "why do we need testers?","what is good testing?", "what should I document, why and for who?"... The greatest value in questions like these is not the answer but the thought process of getting to an answer. - Erik Brickarp
That's as specific a suggestion as could be made. No rewording or repurposing necessary.
Note, these are good questions. They are not the only questions you should be asking, but they are a very good place to start and a good anchor for this workshop.
I agree whole-heartedly with the second part of this suggestion. The important part is not a "correct" or "canned" answer. It's an active examination about what you think, why you think it, and what aspects of your current everyday environment either allow you to think it, or demand that you think it. Note: I'm using demand here not in the "you will do as I say" sense, but as "this is the reality of my day to day work world, and therefore, to be effective, I am choosing to do this to operate in my environment").
Note, these are good questions. They are not the only questions you should be asking, but they are a very good place to start and a good anchor for this workshop.
I agree whole-heartedly with the second part of this suggestion. The important part is not a "correct" or "canned" answer. It's an active examination about what you think, why you think it, and what aspects of your current everyday environment either allow you to think it, or demand that you think it. Note: I'm using demand here not in the "you will do as I say" sense, but as "this is the reality of my day to day work world, and therefore, to be effective, I am choosing to do this to operate in my environment").
Workshop #53: Ask yourself (and answer) the fundamental questions like "why do we need testers?","what is good testing?", "what should I document, why and for who?"... The greatest value in questions like these is not the answer but the thought process of getting to an answer.
In this case, I cannot tell you what the answers to these questions are. More correctly, I cannot tell you definitively what they should be. I can tell you what I think the answers should be, or what my thought process is to getting to these answers, but each of you should do this yourselves and see what your answers are.
-
-
-
-
-
-
-
-
-
-
...why yes, I am putting in dash marks to act as "spoiler alerts" ;).
First, start with what you would consider for these questions:
-
...why yes, I am putting in dash marks to act as "spoiler alerts" ;).
First, start with what you would consider for these questions:
- Why do we need testers?
- What is good testing?
- What should I document, why and for who?
-
-
-
-
-
-
-
-
-
-
-
Have you come up with your answers?
Have you come up with your answers?
-
-
-
-
-
-
-
-
-
-
-
-
-
Are you sure you're not trying to peek at my answers ;)?
-
-
-
-
-
-
-
-
-
-
-
-
-
Actually, as a tester, I would expect you to peek at my answers. Perhaps you will consider them, and agree. Perhaps you will scoff. Perhaps you will take issue with my approach and way of thinking… and that's great!
The point is to not have you parroting my answers back, but considering what these questions would mean to you, and how you come to the answers. They will tell you a lot about your way of thinking, how you internalize your testing approach, and other aspects that are probably very much specific to your circumstances.
My answers may align with yours. they may not. Ultimately, it doesn't matter what I think or how I approach software testing unless we will be working together on a project. In that case, I will gladly explain my rationale and the way I think about software testing and any other topic. I would hope you'd do the same. Together, we'll reach some "common ground" and find a way to be effective for all involved.
My answers may align with yours. they may not. Ultimately, it doesn't matter what I think or how I approach software testing unless we will be working together on a project. In that case, I will gladly explain my rationale and the way I think about software testing and any other topic. I would hope you'd do the same. Together, we'll reach some "common ground" and find a way to be effective for all involved.
Bottom Line:
It's important that we take the time to consider these fundamental questions, not because they are right or wrong, but because they will tell us a lot about ourselves, our values, what we hope to bring to a team, and what our own personal expectations and standards are. There are, of course, many other questions to consider, but for a day's thinking, these three are ample.
-
-
-
-
-
-
-
-
-
-
-
-
-
---------
Well, aren't you persistent ;)?!
OK, if you've gotten this far, you must be interested in what my answers for these questions are. Again, that's exactly what they are, my answers, for right now, in the world and context that I currently work. If I were to change jobs tomorrow, and the business needs were different, then my answers might be different as well. Having said that, I would like to believe these answers would be "evergreen" i.e. they represent what I consider to be "principles" and reflect what I really think, and I hope would be applicable anywhere.
Why do we need testers?
For me, this comes down to the fact that software is developed by human beings. Fallible, imperfect, brilliant at times, impatient at times, all over the map human beings. Programmers are not super human, and issues compound over time, within systems, and between systems. Programmers will not consider every scenario (for that matter, neither will we as testers) but we can provide additional insights, craftiness and focused attention that goes beyond what programmers and automated tests will typically provide. We also need explorers, trappers, adventurers, swashbucklers and buccaneers. think of the people in the Renaissance and the age of sail that would willing ship out to sea for months or years. they were called many things in their day. I like to think many of them would be testers today.
What is good testing?
I consider good testing to be performed when the mind is free to engage on "what it's…" What if I were to work for another company? What if I were to consider how our product performs in competitive settings? What if I were to think of ways that our product could be used that no one has considered yet? What if I were hell bent on finding the ways our product could be exploited? Good testing happens when people drive the process and with a mind and aim towards making software easier to use, more effective, more fun, and more accessible. Good testing happens when programmers feel they can trust a software tester to help them find issues, be explicit, and be direct. Good software testing happens when minds are engaged, people are happy and energized, and when software testers believe that they can steer their own course. Good testing happens when exploration and creativity are encouraged and rewarded.
What should I document, why and for who?
Document what is necessary to help others see what you tested, why it's relevant, and the information you gathered to help key individuals make important decisions. I believe in documenting "enough" to do that. How much is enough? It depends entirely on what I am testing, the ability to communicate directly with the development team and my proximity to our stakeholders.
For me personally, if I am documenting for other software testers, a mind map or a rapid reporter session may be sufficient. If I am communicating with a programmer, then inside the story with details about what I am seeing specific to acceptance criteria and feature development may be fine. For stakeholders, a high level update on story completion, which stories are still in testing, and which stories may be on deck in the next several days may be what's warranted. In some cases, a cumulative summary of the week's automated testing runs will be something people will have interest in, or a list of bugs I feel we should decide a course of action for. In short, I document what I feel needs to be communicated, and what my team has decided needs to be communicated.
If it seems like I am not a fan of "documentation for documentation's sake", your assessment is accurate.
For me personally, if I am documenting for other software testers, a mind map or a rapid reporter session may be sufficient. If I am communicating with a programmer, then inside the story with details about what I am seeing specific to acceptance criteria and feature development may be fine. For stakeholders, a high level update on story completion, which stories are still in testing, and which stories may be on deck in the next several days may be what's warranted. In some cases, a cumulative summary of the week's automated testing runs will be something people will have interest in, or a list of bugs I feel we should decide a course of action for. In short, I document what I feel needs to be communicated, and what my team has decided needs to be communicated.
If it seems like I am not a fan of "documentation for documentation's sake", your assessment is accurate.
No comments:
Post a Comment