92 lines
11 KiB
HTML
92 lines
11 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
||
<html>
|
||
<head>
|
||
<title>MacJournal: Serial Book Review, Part 1: Lessons Learned In Software Testing</title>
|
||
<meta http-equiv="content-type" content="text/html; charset=utf-8">
|
||
<style type="text/css">
|
||
body { background-color: #eee; }
|
||
|
||
h1.header { text-align: center; }
|
||
|
||
div.journalentry
|
||
{
|
||
background-color: white;
|
||
border-color: black;
|
||
border-width: thin;
|
||
border-style: solid;
|
||
-webkit-border-radius: 1ex;
|
||
-webkit-box-shadow: 0ex 0.5ex 0.75ex #888;
|
||
padding: 1ex;
|
||
margin: 1em;
|
||
}
|
||
</style>
|
||
</head>
|
||
<body>
|
||
<h1 class="header">Serial Book Review, Part 1: Lessons Learned In Software Testing</h1>
|
||
<div class="journalentry" id="mj-14A82035-4625-4CD6-AA9C-28030C2DC357">
|
||
<b>Date:</b> 19 Jul 2015<br>
|
||
<b>Time:</b> 14:57:31 CEST<br>
|
||
<b>Topic:</b> Serial Book Review, Part 1: Lessons Learned In Software Testing<br><br>
|
||
<p><span style="font: 12pt Helvetica;">A few weeks ago, a colleague queried me for advice regarding implementing a testing role on a project for which he is a product manager. Over the course of that discussion, one book frequently sprang to mind as an ideal tutorial for product managers and new testers, alike: the remarkable collaboration of [James Bach](http://www.satisfice.com/blog/), Brett Pettichord, and Cem Kaner, [*_Lessons Learned In Software Testing_*](http://www.amazon.com/Lessons-Learned-Software-Testing-Context-Driven-ebook/dp/B000S1LVBS/ref=mt_kindle?_encoding=UTF8&me=). </span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">Since then, it has ocurred to me that businesses relying on tech for their bread and butter -- especially startups and small ventures -- are really suffering for lack of awareness of this book. All around me these days, I see the symptoms: [profound](https://dzone.com/articles/qa-dead-long-live-qa) [ignorance](https://medium.com/product-management-weekly/why-product-managers-should-do-all-their-own-qa-testing-8481289dddd4), [hubris](https://mysoftwarequality.wordpress.com/2013/08/10/should-developers-test/), and [contempt](http://igaffa.blogspot.de/2015/07/on-bugs-and-qa.html) for the role of quality and testing in various organizations and projects. A chronic condition that, at the very least, might be treatable with books like this one. </span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">In lesson fifteen of *_Lessons Learned In Software Testing_*, the authors state explicitly, *"...Don’t expect anyone else to read [this book]. It’s up to you to let your clients know what you need in order to do your job effectively..."* As a tester and an individual contributor on any team, I definitely take this to heart. I try always to raise the "quality awareness" of the team, and to be sure that our quality choices are conscious decisions. </span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">But it seems to me that the lessons in this book would have far greater reach and far more impact if they were known to more than just a handful of good testers. It would broaden everyone's understanding of the nature of quality, raise the standard for what is expected from a good tester, help to rein in ignorance-borne attitudes like those I've linked to above, and ultimately, improve the output of an entire industry.</span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">So, I've decided to do a chapter-by-chapter review of this book in the hope that a public hearing might help to raise awareness and encourage conscious decisions about quality, not only for the teams in which I participate, but across the tech sector as a whole.</span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">Over the next few months, I'll cover a chapter per post, roughly once a week. This week, obviously, starts with chapter one. And its focus, appropriately, is perhaps the most pressing question for software development today:</span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">#The Role Of The Tester</span></p>
|
||
<p> <span style="font: 12pt Helvetica;"></span></p>
|
||
<p><span style="font: 12pt Helvetica;">No single question about testing could be more important than this one, or more misunderstood. As I noted above, we live in a world where the very notion of testing as a distinct role on a project is rapidly becoming synonymous with obsolescence. If testers do not find their voice in this new tech economy -- out here on the startup frontier, where the death of the elderly vertical giants is not a mere speculation, but an active and ongoing project -- then they will cease to have a voice at all. </span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">Is it possible that this death is necessary, like buggy-whip manufacturers in the age of the automobile, or lamp oil distributors in the age of the electric light bulb? Maybe. Or maybe the discipline just needs to learn to be flexible, and to pivot with innovations when they come, the way IBM managed to transition from mechanical tabulating machines into computers in the 1930's. </span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">*_Lessons Learned In Software Testing_* doesn't directly address these larger questions, but the implications are clear in the lessons discussed in chapter one. All throughout this chapter, the reader is constantly reminded to be mindful of his value to the organization. For example:</span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">> You serve the business... perform your work in a way that takes into account the short-term and long-term interests of the company... If you spend time and effort on requirements that your clients don’t care about, you risk being treated as irrelevant or counterproductive. </span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">For testers to remain valuable and relevant to any team, therefore, they must be clear about their mission, understand their value, and work to negotiate these things as equal partners with their team members. </span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">#Relationships</span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">An essential prerequisite to understanding your value, according to the authors of *_Lessons Learned In Software Testing_*, is to understand that you are in a **relationship** with your team (whether they are your clients, your coworkers, or your colleagues). Good relationships are built on an exchange of shared value, and that shared value is discovered and defined by negotiation. This theme is an explicit and urgent one for the authors:</span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">> A role is a relationship. That means you don't control your role, but you can negotiate it... If you can’t come to agreement on the mission, you won’t have a good foundation for anything you do... When you're clear about your role - when you have negotiated it - you have a foundation for setting expectations in any situation that may arise. </span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">The principle behind this lesson cannot be overstated. Every meaningful and lasting thing we do in life involves relationships, and requires our ability to engage in them and navigate them effectively. The more open, honest, and peer-oriented they are, the better we will understand what is expected, and the more satisfying and effective the relationship will be. </span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">However, if you or your teammates misjudge or misunderstand the nature of your relationship, everything you attempt together will suffer a much lower chance of success. If you see yourselves as adversaries, trust will be almost impossible to achieve, and negotiations will be frought with suspicion and deadlock. If you treat the relationship as exclusively transactional, you will limit opportunities for collaboration and cooperation, and lengthen the duration of your feedback loop. If you are trapped in a heirarchical mindset, the project will be encumbered by leadership bottlenecks and "down time.” </span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">One important factor to bear in mind is that all relationships are a two-way street. For negotiation to be successful, you must be as mindful of your negotiating partner's goals and desires as you are your own. *Empathy* is an important tool here. And, though the authors of *Lessons Learned...* were not explicit about this, I think they show an intuitive understanding of this tool in tips like this:</span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">> Your success is measured primarily by how well you serve your clients’ desires and best interests. That might not be so hard, except that testing has many clients. They all have their own needs, and their collective needs don’t necessarily align...</span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">Having a clear understanding of what the team wants to achieve means having a clear understanding of what motivates each role in the team, where the incentives and challenges lie, and how they all interact. All of this requires a good deal of empathy and curiosity. These are two traits I find indispensible as a tester, and two traits that have served me well in relationships outside of my profession as well.</span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">#Education</span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">Lastly, as I alluded to in the introduction to this post, the need to educate our peers -- and ourselves -- cannot be emphasised enough. </span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">The last lesson in chapter one addresses this problem exclusively. The authors focus on insuring that you clearly communicate the needs of your particular role within the context of the project. But embedded within this task lies a much more important goal for all of us:</span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">Salvaging software testing from the dustbin of ignorance and hubris. </span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">So say the the authors:</span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">> An important part of the role of testing is to explain testing to our clients. Your explanations are like a flu vaccine -- healthy and not that painful, but the effect wears off, so you have to do it over and over again.</span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">This is one of the largest reasons why this blog exists. I want to explain testing to more than just my teammates. I want to explain it to as many people as I can reach. It is one of the least well understood roles of the software development process, and as a consequence, one of the most endangered roles. </span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">This is also why I am eager to promote books such as *_Lessons Learned In Software Testing_*. Whether or not you necessarily agree with every position these authors take, what they've done with this book is to provide a plain-spoken manual, not only for the successful tester, but also for making the role of testing itself a success once again. </span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">#Conclusion</span></p>
|
||
<p></p>
|
||
<p><span style="font: 12pt Helvetica;">In keeping with this spirit, I will be continuing this series next week, with a review of chapter two from the same book, entitled, "Thinking Like A Tester". Wherein, I'll be enthusiastically bloviating on one of my own favorite subjects: Critical Thinking Skills. :D </span></p></div>
|
||
|
||
</body>
|
||
</html>
|