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 #19: Learn From Other Tester Mistakes - Mantas
Suggestion #20: True, but learn from your mistakes first :-) - Mauri Edo
There's no way that I can make the point that I want to without duplicating effort (well, I suppose I can, but I don't really want to). Therefore, #19 and #20 are going to be the same recommendation, but from two different perspectives. In both cases, I'm going to suggest the same thing.
The fact is, testers are human. We make mistakes. Note the emphasis "we make mistakes". That goes for beginners and veterans. Long time testers are just as prone to fatigue, boredom, misunderstanding and patience as anyone. However, we have an opportunity to do two things that will help us get better and learn how to be better focused going forward.
Workshop #19: Perform regular "Bug and Story Autopsies"
The bug database of any company is often filled with carcasses of unclaimed and unloved bugs. Think of it as a morgue where the remains of a deceased individual have never been claimed. At least with the stories and bugs that have been worked, resolved and closed, they have received proper burials. While there are plenty of opportunities to go there and see what could have been done better, a much better and more fertile place is the "morgue" or "the icebox" or whatever your organization calls the myriad list of bugs that have not risen to the level of "important enough to do something about".
Why do I suggest starting here? Because as testers, the most visible aspect of what we do is the bug report. We may not like that fact. We may wish that a broader interpretation of what we do is considered. Nevertheless, to most people, bugs make the tester, and bugs break the tester. That's how many people see our role and our value. Therefore, if we really want to "learn from our mistakes", the lowest hanging fruit is to be found in the bug database, and any bug that does not rise to the level of "we need to work on this".
Please understand, there are a lot of reasons why bugs do not get worked on. It could be a time limit. If could be a resource limit. It could be "out of the scope" of the development team's mission and goals. All of those are legitimate, and there will be bugs that fall into those categories. Instead, I'm asking you to focus on the bugs that have been filed and haven't been picked up that you really cannot put into those categories. If you can see the value and validity of them, yet don't understand why they haven't been picked up yet, it's possible that you have a chance to learn from and improve on the past.
As in the advice given in Workshop #17, "Be Critical but Do Not Criticize", it's possible that we could do a much better job with selling the bug. Bugs need marketing campaigns, too, and for a campaign to be successful, there needs to be an emphasis on key areas. In the previous example, I suggested using the RIMGEA method to make sure that the bug gets the best shot at being seen for what it is, and what the potential impact can be. That advice will also work here, too.
Additionally, take the time to triage these areas regularly. If possible, have the test team look through this bug database and see which "top ten neglected issues" stick out. Winnow these issues down to see why the issue isn't being addressed. As you identify these "neglected" issues, see if the marketing campaign for these bugs is effective. Look over the marketing copy (i.e. how the bug is written). If you can improve it, do so. As you do this, report on the ten most underrated issues in the bug database at a weekly team meeting, and see if you can make some movement on getting these issues addressed. You won't be able to win all of the time, but you may be surprised at how many issues get second looks when we clarify the details and help others see why the issues are important.
Workshop #20: If you haven't already, start a blog
For me personally, this has been a great way to examine my own mistakes and consider ways that I could do better. For too many people, a blog is considered a "mouthpiece of authority" and therefore, to have a blog, you need to speak as though you are an expert. That's ridiculous. One of the most valuable kinds of writing for potential readers are "Lessons Learned", examples of where things didn't go well, a course was changed or a potential solution tried, and the outcome of those experiments. The fact is, most of us don't write about amazing successes. Usually, we write about areas that frustrate us, or confuse us, and how we have endeavored to clear up the confusion or errors. A lot of my blog posts are, on the surface, embarrassing. They show more of my deficiencies than they do my strengths, and that's wonderful!
By sharing the errors of our ways, and providing a context for them and solutions that have worked for us, we show others that there are other ways of doing things. We show that a fair amount of trial and error is often necessary to accomplish certain goals. This also shows others out there that we are actively engaged and genuinely considering other options, and not just blindly doing the same thing or following the "best practice". Have you found yourself following a best practice and discovering that it's either not helpful or that it's actually detrimental to what you are doing? Other testers deserve to know about that! Many of my most successful blog posts have not been where I said "hey, I have this cool new idea". Usually it's "hey, I tried doing something, and it totally blew up on me, but here's what I discovered in the process." Maybe it's the tragic nature of humankind, or we just like seeing when others take their lumps, but there it is.
Writing a blog also helps out in another key way… it gets you in the habit of seeing if your ideas make sense to others. The feedback you receive through various avenues (rebuttal blog posts, comments, tweets and retweets, shares on Facebook, Tumblr, LinkedIn and Reddit, etc.) can all help you develop your ideas and write them better in the future. This has certainly been the case for me. It also acts as my "institutional memory" of things that I once believed to be true, but on further investigation, proved otherwise. That's important to know, and it's important to review where you have been, what you have subsequently learned, and updating and revising with new posts to compare to where you used to be.
Key admonition: under no circumstances should you edit older posts to reflect a current mode of thinking. Typos and bad grammar fixes are fine. Wholesale changes of opinion or ideas should be handled in separate posts, and supplemented with a "Here's what I thought in 2010. Here's what I think in 2013. Here's why I think this update is needed."
Bottom Line:
Perfection does not exist, in software or anywhere else. We all make mistakes, and we all have the opportunity to learn from one another and get better at what we do. Even when something seems like an ironclad rule or principle, there are context that can appear that will challenge the validity or soundness of those principals. Seek to understand where those areas might be. Improve on issues where you can. Learn from issues where you can. Most importantly, share what you learn with others. Be willing to be one who makes "break-throughs" and "breaks-with", no matter how embarrassing the journey. One one hand, you will learn a lot along the way. On the other, many other testers will be enlightened, and quite possibly entertained, by your travelogue.
No comments:
Post a Comment