Wednesday Book Review: The Day the Universe Changed

Through the years, I have come across a number of books that I have used and valued. These may be new books, or they may be older ones. Each Wednesday, I will review a book that I personally feel would be worthwhile to testers.

A few weeks ago, I reviewed Thomas S. Kuhn’s book “The Structure of Scientific Revolutions”. In it, a very academic tone is used to describe how “controversy points” in the history of scientific development had to be worked through before new theories and new ideas could be explored, considered and ultimately accepted. As this book interested me, I wanted to see if I could find a title that would likewise address many of the same questions, possibly look at some other angles and, OK, I’ll admit it, do it in a way that didn’t make me want to run for a dictionary or Wikipedia every other paragraph. I do not consider readability to be a sin; in fact I consider it to be a very worthwhile goal.

As I was looking, I thought about James Burke, the English historian and television producer of the “Connections” series of television programs produced for BBC in the late 70’s. I had also heard that he had a series and book published called “The Day the Universe Changed”. Could this book be what I was looking for, i.e. a title with a broader coverage of epistemological ideas and, perhaps, also entertaining?

First, for those not familiar with James Burke, he is a pioneer in the idea of the interconnectedness of thought and development of culture, science and society. Developments and discoveries do not happen in a vacuum, and it’s rare that one person alone completely presents a new idea that changes everything. Much of the work and the phenomena of the world is interconnected, and it’s through those interconnections that future development is done and future progress is made.  Burke shows through ten chapters that the world that we know today has changed many times through the centuries and millennia that have passed before us. Actually, the world itself hasn’t really changed, but our models and institutions for communicating about and dealing with that world have been radically altered many times throughout history.

There are several areas that are discussed in the book. The Aristotelian and Ptolemaic views of the universe and the nature of the authority of the Roman Catholic church helping to make that universal view so prevalent. The development of measurement and Euclidean geometry, and the development of Algebra in the Middle east and how it came to the fore in Europe through the libraries of Cordova in Spain. The development of large mercantile institutions and families, such as the Medici in Italy and other areas, that required more streamlined methods of accounting. The development of optics that let observers make more refined measurements of the “celestial bodies” and better explain their behavior (leading to an understanding of a heliocentric solar system). The understanding of geology and fossil records that showed a greater age of the earth than previously considered, and a greater variety of life than was previously considered. How medicine had developed from focusing on the temperament of a patient to the understanding of how microorganisms played into both contagion and the development of immunity. How electricity helped to isolate elements, and how this led to a better understanding of the nature of matter and how it is composed, along with the understanding of positively and negatively charged matter. The development of Darwin’s theory of evolution is also discussed, and how that theory influenced numerous aspects of society. How the relative position of anything affects is ability to be measured in any meaningful way. Science and technology influence each other over and over, with a change in one often causing major disruption, time and again, to the established order of things, and that disruption leading people to consider new avenues of thinking to address the challenges raised.

Burke covers a large period of time in this book, a few thousand years. Many of the areas that are covered are compartmentalized so that the developments are seen through the context of their times, societies, and political & religious forces that dominated those periods. Some changes appear to happen relatively quickly, while others happen much more slowly, and often for reasons other than scientific inquiry or lack of it (politics and religion frequently take center stage, both at times acting as the champion and the hinderer of scientific discovery). Both religion and politics take a bit of a drubbing in this book.  While some may point to this as saying that Burke has an anti-religious bias, I would disagree. Burke is placing the struggles of political and religious life into the context of the ages in which changes were taking place, and in many cases, the resistance was not because of scientific discovery, but what the news of that discovery might have on the political landscape (i.e. who holds what power at what time). While there is a little editorializing regarding religion and science and which views prevail at which time, Burke is fair handed and lets the facts of the discoveries tell the story.

Bottom Line:

One of the things I strive to do with these reviews is to explain or highlight the reasons why they would be valuable to testers. What Burke shows in The Day the Universe Changed is that many discoveries and changes in the way issues are found and resolved occur by accident; two things that were studied separately, when combined, bring a greater understanding of both areas and a realization that they are actually related to each other (case in point, electricity and magnetism). Thus, the title of the book is a bit of a misnomer; there isn’t one day in which the universe was altered, and more to the point, the Universe wasn't altered at all. We as people discovered a new way to look at our world and to test against it (see, there’s that magic word again :) ).

What makes this book interesting is that we see the evolution of thought, and for those who are interested in Epistemology, “The Day the Universe Changed” is an engaging, interesting, and just plain fun way to consider the topic. Whereas Kuhn made a very academic exposition of how “Paradigm Shifts” took place, Burke makes the information, the times and the temperament of the times understandable to the common reader. A thorough understanding of the eras or the science involved is not necessary. Both books are aimed at a different set of readers, but both convey the same message; it’s our understanding or our world, or the lack thereof, which either spurs or hinders advancement in thought and implementation of technologies that aid us. The world is still much the same. We haven’t invented phenomena. Instead, we have just learned how to harness the phenomena that surround us in new and inventive ways, and have built upon the knowledge and experimentation of those that have preceded us. For those that would like to see where we have been, what we have discovered along the way, and to get excited about where we might go from here, The Day the Universe Changed should whet your appetite nicely, and then give the reader motivation to look for additional avenues to explore.

Pacific Northwest Software Quality Conference

I’m excited! I will be attending the Pacific Northwest Software Quality Conference, to be held at the Portland World Trade Center in Portland, Oregon October 18-20, 2010.


This will be the first time that I have taken part in any type of software development and testing conference. Well, OK, that’s not entirely true. Back in 1996, I had the chance to attend Interop in Las Vegas when I worked with Cisco Systems, and as part of that experience, I was able to attend a course track that was dedicated to performance testing for routers and networks, primarily from the perspective of lab managers and administrators and how to set up networks to test for performance. While informative and interesting, it had little to do with talking about actual testing techniques and testing skills.


For those who are interested, the theme of this year’s conference is “Achieving Quality in a Complex Environment”. Keynote will be provided by Tim Lister of Atlantic System Guild. For more in depth details as to what the conference will cover, check out the 2010 Conference At-A-Glance page.


I look forward to getting to know some of the testers that I have communicated with, especially those who call the Pacific Northwest home, and any others who will be attending.

BBST Foundations Course Starts July 4th, 2010

Calling all testers!!!

Are there any out there who have been working on testing but wished they had some fresh perspectives? Are you actively testing, but wondering if there are ways to look at testing differently? Are you a self taught tester who would like to have a chance to get some more specific test knowledge under your belt? Would you like to have me help you do it :)?

If the answer is YES, then I encourage you to sign up for the Association for Software Testing’s “Black Box Software Testing Foundations Course” beginning July 4th. This is a 4 week long coached course. Becky Fiedler will be the lead instructor, with assistance by a number of additional teaching assistants (including me). I took this course back in May and I found it to be an excellent opportunity to re-examine how testing works and how I can improve my process and methods. Even if you’ve been testing for years, there’s a good chance that you’ll pick up a few cool new tricks here.


For more information, check out the Association For Software Testing – BBST site and, while you are at it, tell your friends, too :).

Meetup Your Way To Better Selenium Understanding

This past week I had an opportunity to get together with other people in the community of testers, developers and IT professionals surrounding the Selenium suite of open source testing tools. As a lone gun tester, I have grown to value the opportunities to hear different approaches to using tools and to talk with other people who are using the tools in ways I either hadn't considered or who have a different focus than I do (plus, the pizza was really good, too :) ).

This particular meeting was hosted by the San Francisco Selenium Meetup Group, and was organized, as the name implies, using Meetup. For those not familiar with Meetup, it’s a way to find those people out there with general interests, or specific ones, and have an opportunity to gather together and discuss topics and opportunities that would be of benefit to the entire group. This was my first opportunity to join this group in a formal setting, and I have to say it made an excellent first impression.

The first aspect was that there are people using Selenium that I didn’t think would be. I had an interesting conversation with a small company that helped proofread and comment on university dissertations, and their approach to using Selenium to perform searches related to a particular paper’s contents to help determine what ideas were cited correctly, as opposed to what might be plagiarized, gave me an insight into an approach to using Selenium I otherwise might not have considered. Too often, when we use a tool, we only apply it to the scenarios that we can think of because of a sense of exigency. Getting other perspectives from other users is a valuable way to see that there may be other uses for your tool of choice.

The topic covered on this particular evening Meetup was to show how Selenium could be used with Hudson (a continuous integration environment) to control distributed builds and aid in the Unit test and Integration test steps. I will admit that this particular set of topics was not immediately applicable to my current work environment (our applications are not Java based, but .NET and VB based), so the specifics of the talk couldn’t just be dropped into my environment as is. The real value, though, was that it gave me a glimpse into some different ideas as to how to use a tool I currently have deployed (Selenium IDE and Selenium RC) and see how I might be able to apply some of the ideas in my current environment, if not all of them.

My thanks and appreciation to Sauce Labs, who hosted this month’s meetup, for letting a bunch of us invade their office space, eat pizza, drink their beer, soda and water, and have an opportunity to talk about how we use our tools and consider different implementations for those tools. For those in the San Francisco area interested in this type of interaction, consider joining the Meetup group and come out and hang with us. The next Meetup for the San Francisco Selenium Group is tentatively July 21, 2010 at Digg HQ in San Francisco, and will be a “Whiteboard Night” where contributors will set up and explain how they are using Selenium in their organizations, and allow others the chance to walk around and ask questions. More on this as the program draws closer, but I am already planning on being there. Here’s hoping some other San Francisco and Bay Area Selenium testers will be there, too :).

Wednesday Book Review: Beautiful Testing

Through the years, I have come across a number of books that I have used and valued. These may be new books, or they may be older ones. Each Wednesday, I will review a book that I personally feel would be worthwhile to testers.

Beautiful Testing is part of O’Reilly’s series of varied topics, with numerous professionals talking about putting into practice the various theories and tools that exist and sharing their insights with others.

Many of us who test as a dedicated profession realize two things. First, what we do requires a lot of emotional brain labor, and it isn’t easy to do. Second, we realize that there are a lot of people who do not share that view. Oftentimes, we have to go to great lengths to explain what testing provides for an organization and that (zoinks!), it’s not just the testers responsibility to focus on quality. In fact it’s the entire organizations role to focus on quality (repeat after me: testers cannot assure what is not there. Developers can create quality product and we can assure that the quality initiatives that are in place are effective, or we can show where quality issues are. We cannot manufacture quality out of thin air. Either it is already there, or it is not).

Beautiful Testing takes a great approach here, in that each chapter is written as a standalone case study. Each chapter likewise has a different author(s). Some of the details are very familiar to every tester, and some situations are unique challenges that many of us may not have faced yet . The first part of the book deals with testing as a people issue, and focuses on tester attributes and abilities. The second section of the book deals with test processes and procedures, and real world examples of those procedures. Part three deals with testing tools and how to make the most of them in real world environments and with real testing challenges.

What’s more, each author agrees to donate their portion of royalties for the books to a charitable cause. In this case, the charitable cause is “Nothing but Nets” a program to distribute mosquito nets in Africa to help stem the tide of malaria infections.

Chapter 1 : Was It Good for You? (Linda Wilkinson)

This chapter leads off the book and gives a great introduction to the mindset of a tester, and the reason and rationale they use to help a company get the most out of their software development time. It makes a clear case that “not just anyone can test” (or at least not do so and do it well), and it helps identify the areas testers really care about.

Chapter 2 : Beautiful Testing Satisfies Stakeholders (Rex Black)

There are many stakeholders that have a say and a personal vested interest in our testing being done well and providing a lot of information to help make good decisions. Those stakeholders range from customers, vendors and users, but also include such entities as law enforcement, elected officials, company shareholders and all of the other key contributors to any project (PM’s, developers, software developers, and yes, even our fellow testers).


Chapter 3 : Building Open Source QA Communities (Martin Schröder & Clint Talbert)

Using the example of Open Source projects, getting a community involved in the efforts will help get people excited about applications and give those who are part of that community a desire and drive to see it succeed. My own experience with this has been with the Selenium Users Group here in San Francisco. While I find using the tool itself to be interesting, getting involved with and getting to know others that are also actively involved gives me extra energy and motivation to learn and practice more so I can likewise share with the broader community.


Chapter 4 : Collaboration Is the Cornerstone of Beautiful Performance Testing (Scott Barber)

Scott shares some of his insights into the development of his approach to performance testing, and the idea that performance testing challenges can be tackled via collaboration with other groups.

Chapter 5 : Just Peachy: Making Office Software More Reliable with Fuzz Testing (Kamran Khan)

Fuzzing is described as a technique where deliberately corrupt data is entered into your application to see how the system reacts to the inputs (for good or ill). Kamran uses Excel as an example application and demonstrates using tools that fuzz input and data values.

Chapter 6 : Bug Management and Test Case Effectiveness (Emily Chen & Brian Nitz)

Emily and Brian share bug management techniques and methods defining defects as relates to their involvement with Bugzilla and the OpenSolaris Desktop development team.


Chapter 7 : Beautiful XMPP Testing (Remko Tronçon)

Remko walks through examples and issues faced with testing the Extensible Messaging and Presence Protocol (XMPP) and describes his approach to creating Unit Tests for testing protocol interactions.

Chapter 8 : Beautiful Large-Scale Test Automation (Alan Page)

Alan walks the user through an example of test automation on a grand scale, and shows that many of the approaches and methods that are used for small scale automation projects work the same way for large automation, but the scale is totally different. This chapter helps a lot in showing neophyte testers that the steps from one world to another need not be so scary.

Chapter 9 : Beautiful Is Better Than Ugly (Neal Norwitz, Michelle Levesque & Jeffrey Yasskin)

Python has made its way from an interesting yet obscure language back in the 90’s to becoming one of the go-to languages of the web and testing today. Testing an entire development scripting language puts a whole new area and emphasis on testing and stability.

Chapter 10 : Testing a Random Number Generator (John D. Cook)

Here’s a great example of taking an application that can be tested in a number of ways, and the correctness or incorrectness can be difficult to pin down.

Chapter 11 : Change-Centric Testing (Murali Nandigama)

Murali demonstrates a call system and makes the case that, instead of testing everything over and over again, make a series of tests that will focus on the change. By using a change-centric testing approach, the number of tests run nightly can be reduced dramatically.

Chapter 12 : Software in Use (Karen N. Johnson)

Karen describes the feeling and the responsibility of testing equipment that works in a Hospital’s Intensive Care Unit, the very definition of Mission Critical. This one hit close to home, as it described a situation my Dad (a retired physician) faced a number of years ago with a program and a glitch that almost cost patient’s lives in an infant ICU. Karen describes the process, ups and downs, and resolutions related to, in her words, working on a product that really matters.

Chapter 13 : Software Development Is a Creative Process (Chris McMahon)

Chris makes the case (and a really compelling one) that developing and testing software is artistic work. Evaluating software quality is evaluating art, and that, when we recognize the artistic aspect of creating software, Beautiful Testing becomes a reality.

Chapter 14 : Test-Driven Development: Driving New Standards of Beauty (Jennitta Andrea)

Jeanette introduces the idea of the Diderot Effect and relays it to test driven development and the unintended consequences of upgrading just one area of a process and thinking that it’s all done. To embrace the beauty of TDD, all aspects of the role and purpose of testing and embracing TDD have to be applied. Requirements, system design, he very act of writing code, the pace of work and the level of engagement of the testers involved all face changes when TDD becomes part of the landscape.

Chapter 15 : Beautiful Testing As the Cornerstone of Business Success (Lisa Crispin)

Anyone familiar with Agile Testing will notice the Mind-map that leads off everything, and gives a clear picture of the ideas that Lisa wishes to impart. The take away is clear, testing is part of the overall process of development, and testing is a process at every stage of development. Testing drives development, and development is not complete until tested.

Chapter 16 : Peeling the Glass Onion at Socialtext (Matthew Heusser)

Matt makes the point that, in mathematics, often the simplest solution is the most beautiful solution, and the same holds true for testing. Through examples at Matt’s company, Socialtext, he shows how they do not just test to show that they have done testing, but that the solution they have developed fits what their customers want to see.

Chapter 17 : Beautiful Testing Is Efficient Testing (Adam Goucher)

Efficiency and focusing on how to get the best bang for your buck requires setting some parameters, using some tools to help focus on the goal, and making a mindmap to capture test ideas and methods. Adam uses the mnemonic SLIME to help organize his approach ((Security, Languages, RequIrements, Measurement, Existing).

Chapter 18 : Seeding Bugs to Find Bugs: Beautiful Mutation Testing (Andreas Zeller & David Schuler)

Andreas and David discuss the idea of mutation tests, and the tool Javalanche to perform those tests.


Chapter 19 : Reference Testing As Beautiful Testing (Clint Talbert)

An inside look at how Mozilla tests the variety of products in the Mozilla portfolio, and how they create tests and their reference points. Their goal is to encourage people to get involved and test in the way that is the most simple, direct and easy to understand way possible.

Chapter 20 : Clam Anti-Virus: Testing Open Source with Open Tools (Tomasz Kojm)

A look under the hood at an open source product (Clam Anti-Virus, a tool I actively use and wholeheartedly endorse, by the way) , and all of the open source tools used to test it, along with the testing strategies used.

Chapter 21 : Web Application Testing with Windmill (Adam Christian)

Adam provides a quick tutorial in how to set up and use the Windmill web testing tool and a quick way to implement automated testing for web applications.

Chapter 22 : Testing One Million Web Pages (Tim Riley)

Tim describes the Spider and Sisyphus projects at Mozilla and how they use the framework to test huge numbers of pages and web sites.

Chapter 23 : Testing Network Services in Multimachine Scenarios (Isaac Clerencia)

Isaac describes the ANSTE test tool and how it is used at his company, eBox, to test environments with multiple and varying machines.

Bottom Line:

Not every section will be relevant to every tester, and I found a few of the sections not immediately applicable, but each section gives the reader a greater appreciation of the testing process in their respective sections. The multi-writer style for each chapter makes the book very engaging, and allows the reader to skip to the sections that matter the most to them. There is something for everyone in the testing process here, from technical testers with deep programming knowledge to relatively new testers without specific development backgrounds. Agile and traditional development methodologies will find value in these chapters, and overall it’s a fun read. If you are looking to put a little more elegance and art into your testing life, Beautiful Testing has a lot to offer.

Senses *Not* Working Overtime

Over the last five days, I and my family have logged some 2000 drive miles, seen a lot of cool things, had a lot of fun, and now it’s back to reality and all that goes with it. My family and I loaded up the car and trekked to Salt Lake City and various points surrounding it to show our kids many of the things I used to do and look forward to as a kid. My grandparents lived in Provo during the 70s, and due to that, we would head out to visit them twice a year for a week at a time. Subsequently, I have a lot of cool memories of the area, and I wanted to share that with my kids.

I’m also a realist. The idea of spending 14 hours in a car traveling is a long day no matter how you look at it. When we were kids, we had a station wagon with fold-down seats, so we would frequently put all the luggage on the rack on top of the car, put mattress pads and sleeping bags down , and we’d lay out, read, listen to music, sleep… you know, those things that people commonly did in the 70s before mandatory seat belt rules went into effect. In today’s world, DVD players are the norm with cars that are fitted with them. Ours is a decade old now and just shy of the in-car DVD boom, so we had to experiment and improvise. We determined that a cassette adaptor and a couple of 1/8” stereo adapter plugs would allow us to connect my son’s laptop up to the car stereo system, and they could watch their DVD’s without having to hover over the laptop to hear it. That and a car adapter to handle 120V AC, and we were good to go. I had a chance to hear a lot of movies on this adventure (of course, I couldn't see any of them as I was driving ;).

It’s an interesting thing when you don’t have the visual queues as to what’s happening on the screen, and all you have is the sound and the dialogue; your brain fills in the gaps. I’ve done this a number of times when traveling with friends that have DVD players, but I’ve been in the front seat. Many times what I come up with in my mind is totally different than what is on the screen. That’s because we can only “see” what we can hear. This was most amusingly pointed out to me as my kids were watching the movie “Click” with Adam Sandler. For some reason, I had it in my mind that Tea Leoni was in this movie as Sandler’s wife (she wasn’t, that was the movie Spanglish). So the entire time I was listening to the movie dialog, I had the mental image of Tea Leoni on screen. It was after the trip ended and I was picking up the DVD’s to be returned, that I realized that Kate Beckinsale was the actress planning Sandler’s wife. I recognized Christopher Walken’s voice off the bat, so I was able to fill in the gaps of his mannerisms and everything else I knew about him easily. Sandler is a character I know well, and he seems to play the same part over and over, so that wasn’t difficult either, but the mistake of the actress playing Sandler’s wife gave me a totally different image of what the movie would be in my mind, and the character's interactions.

In my testing efforts, much of the time, I am given a product or a feature where I know even less about all its inner workings than I do about this film. If with just my ears I could create a total flow of a movie with a totally different actress, what might I be doing when I am testing a product and I don’t have all of the potential information? Some testers may not be able to or have the ability to look at the underlying code. This can color the way that we test and what approach we take. This is not inattentional blindness (or at least not totally), this is really missing out on details that inform the user experience (the same could be said if we were to be able to view the film but turn off the audio and only have subtitles; yeah, we would see the images, and we would see the dialogue, but we might miss all of the inflection and the background sounds that inform the scene). Likewise, when we test, we should also be ready and able to ask “what am I missing, and is what I am missing something that has the potential to change entirely what I perceive to be happening?”

Wednesday Book Review: Software Test Automation

Through the years, I have come across a number of books that I have used and valued. These may be new books, or they may be older ones. Each Wednesday, I will review a book that I personally feel would be worthwhile to testers.


In a previous review I said that I had two books that were my only test related titles through my entire career (at least my career up through 2007). Testing Computer Software by Falk, Kaner and Nguyen was one of them, and this book, Software Test Automation, by Mark Fewster and Dorothy Graham, was my second. Though this book was published a little more than a decade ago, I still refer to it. Is this a title that others should read, too, in light of the fact that ten years of progress on the automation front has taken place? Why would I suggest this book?


In the days when I was working in a predominantly UNIX shop, the ability of writing code and writing test scripts for that code was almost the same thing. The ability to use tools like bash, awk, and expect meant that most automation needs could easily be put together for many applications. However, with the coming of graphical interfaces, the simpler tests were more difficult to conduct (or in some ways impossible). In the mid to late 90’s a number of automation tools were developed with the promise of recording your actions, and then playing them back over and over. Well, most of us who have had any run-ins with automation know that that was mostly an empty promise, and even in the best of circumstances produced tests that were too brittle to be of any long term use, and even those that were required a lot of maintenance. Fewster and Graham point this out very early in their book, and show that automation requires more than record and playback. It requires forethought, good planning, and understanding the limitations of test tools. With that understanding, the authors go through many details and examples to show a "tool agnostic" model for developing tests and applying them at different stages of the software development life cycle.


Many test automation books require the reader to have a background or at least a good understanding of programming. Fewster and Graham make no such assumptions, and this book is a great first step for those who want to get started with automation, or have the task of starting from scratch with their automation efforts. I’m somewhere on that early continuum myself; though I understand many aspects of the automation process, the methods that stood me well in a UNIX shop aren’t as readily usable in a Windows development environment.Still, the methodology suggested is still relevant and can help the budding automation tester ask the right questions, even if they don’t know many of the environment specific answers as of yet.


The book is split into two parts. The first section is the introduction and practice of test automation. Eleven chapters bring the budding test automation engineer from initial automation contexts, using the V model for constructing different tests for different stages in the product lifecycle, and coming to grips with the limitations that automated testing has (interestingly, the limitations in 1999 are very similar to the ones experienced in 2010). Subsequent chapters discuss techniques of automation, including various methods of comparison and approaches to determining if tests have passed or failed, and how to really know if they have. A focus is placed early on making sure that tests can be maintained, and a methodology for constructing tests so that they are not overly complex is a highlight of the book. Further chapters deal with metrics and measurements, monitoring and reporting results.


The second part of the book goes through a dozen short chapters that show case studies of companies that have implemented automation, some successfully, others not so successfully. Microsoft is also included, describing how they implemented test automation in the 90s, specifically the initiative that came to be known as WebTV for Windows), and relate their successes (and failures) with real-world test automation. Modern readers may look at a number of these chapters with a sense of amusement; the examples are mostly derived from the early to mid 1990’s, and do not have many of the common buzzwords that we are familiar with today. This book also predates the Extreme Programming and Agile movements, so there’s no mention of those approaches. Still, even without those newer flourishes, there are many great take-away’s from Fewster and Graham’s book.

Bottom Line:

Software Test Automation is two books in one. The first book is a how-to guide to get into test automation and develop a method of constructing automated tests and thinking about automation that will help place the tester on a solid footing to grow and experiment with. The second book is a glimpse into a number of tester’s real world issues and answers to testing challenges, and hoe they met them (or didn’t meet them). The details in Software Test Automation, were they to be laid out end to end, would be able to keep a tester busy for several months, if not longer. Don’t let this discourage you, as the book is very readable, and it’s a title that allows and encourages jumping around. For the novice automation tester, it’s a great foundation to build on.

(12/12) All I Ever Needed to Know About Testing I Learned in Scouts

This is the twelfth of a 12 part series.

As many of you know, outside of testing and raising a family, my single biggest time commitment is being a Boy Scout Leader. Over the past couple of years, I’ve seen and heard various presentations regarding a code of ethics around (teaching, development, testing, governance, fill in the blank). Each time I’ve heard or read these statements I’ve caught myself saying the same thing… “If everyone just lived by the Scout Law, we wouldn’t need this patchwork blanket of ethics rules and codes of conduct”.

My “challenge” now is to see if I really could map Testing to the Twelve Points of the Scout Law.

Note: these twelve points are those as defined by the Boy Scouts of America; while the Scout Law is similar in all countries that have Scouting movements, the wording is often a little different depending on the country.

“A Scout is Trustworthy, Loyal, Helpful, Friendly, Courteous, Kind, Obedient, Cheerful, Thrifty, Brave, Clean and Reverent”



A Tester is… Reverent

When it comes to Scouting, one of the core principles that we teach is that there is a power greater than ourselves. Mankind has called it many different things over the eons of our existence, and has expressed it in many different ways, but there is a common thread for all humanity to have a respect for a “higher power” and to encourage those who have such faith to explore it, understand it and to practice it to the best of their ability. In my Troop, there is a  number of different religions represented, and I make it a point to encourage all of the Scouts to do what they can to understand their religion or their faith, and make a commitment to learn it, understand it, and practice it, whatever it may be. Additionally, I teach them that it is more important to live and walk uprightly and be true to their own faith and to themselves than it is to try to convince others that they are "right' or "wrong" in what they profess or practice.


So is there a place for reverence in such a calculating and analytical practice as testing? Is there a “spiritual” element to testing? I will argue that, yes, there is, and that a tester’s spiritual walk can inform their testing. This is the area that is the least likely to hold up under cold hard facts, but it is an area that I feel has been informed in ways I’ve never been able to explain any other way. I consider one who walks in faith to be one who seeks a deeper meaning, who tries to look beyond themselves to find answers. Note that I am not saying that a particular religion is required, or that one even needs to be particularly religious to do this.


For me, reverence ultimately comes down to the word “respect”, though it also incorporates elements of “sacred” as well. Is there such a thing as “sacred” things in the eyes of a true hard nosed tester? I believe there is, and I will state that my own faith has helped inform many of my testing decisions over the years. I believe that following a “true way” helps me to organize my thoughts, reach for inspiration in moments when I otherwise could not seem to pull it together in any other way, and ultimately provide a mooring that helps me to make better decisions in all aspects of what I do, not just when I test.

Epilogue:

This brings me to the end of my comparisons of the Scout Law and what I think would be a good application to the roles that we as testers are expected to fulfill. I stated in my first post, I used the title as a bit of a gimmick, and also as a challenge to see if, indeed, there was anything that a tester would or could do that didn’t fall under some category of the Scout Law, and this experience writing about it has added to my feeling that, truly, the Scout Law really is one of the most inspired and inspiring codes of conduct that any organization could choose to follow. I don’t know if my thoughts on this (or the focus for the past two weeks) will sway anyone, but it helped solidify in my heart and mind that this is the code of conduct that I want to bring to my craft of testing.

So how about you? Are there any other aspects you would consider including? Any you would consider removing? This is a question I often ask Scouts who sit for their Eagle Scout Boards of Review. If they could take out one element of the Scout Law, what would it be, and why? Also, if they could add one element of the Scout Law, what would it be, and why? I invite anyone who would like to comment or make suggestions to do so.

(11/12) All I Ever Needed to Know About Testing I Learned in Scouts

This is the eleventh of a 12 part series.

As many of you know, outside of testing and raising a family, my single biggest time commitment is being a Boy Scout Leader. Over the past couple of years, I’ve seen and heard various presentations regarding a code of ethics around (teaching, development, testing, governance, fill in the blank). Each time I’ve heard or read these statements I’ve caught myself saying the same thing… “If everyone just lived by the Scout Law, we wouldn’t need this patchwork blanket of ethics rules and codes of conduct”.

My “challenge” now is to see if I really could map Testing to the Twelve Points of the Scout Law.

Note: these twelve points are those as defined by the Boy Scouts of America; while the Scout Law is similar in all countries that have Scouting movements, the wording is often a little different depending on the country.

“A Scout is Trustworthy, Loyal, Helpful, Friendly, Courteous, Kind, Obedient, Cheerful, Thrifty, Brave, Clean and Reverent”


A Tester is… Clean


Note that this is not specifically physical cleanliness , though when dealing with Scouts of a certain age, this is definitely the primary focus. It actually goes deeper than that. Clean has to do with a state of mind, a state of organization, a state of being willing to keep our conversations, our interactions and our way of speaking also clean (meaning uncluttered, tidy, polished, focused and respectful). I mention to many Scouts that it is possible to be physically dirty but have a clean heart, and the opposite is true as well, to be physically clean but become "filthy" on the inside. When faced with those options, I'll always encourage the former over the latter.


So does this have a place in the Tester’s law? Absolutely. Do we consider it important to have known states for our systems when we test (or at the very least, as close to known states as is possible, since we know that there really isn’t any way to guarantee an absolutely exact test environment for every test iteration). Keeping tests organized, keeping documentation uncluttered, and reporting in a simple, direct way enhances our craft and helps make us more credible. Additionally, it’s up to us to help each other maintain good and productive habits in our craft, which definitely comes into play whenever I think of the term “clean”. By doing things that allow us to be straightforward, showing integrity in our actions, we strengthen our credibility. Taking shortcuts and cheating so that we can get approval or meet a deadline should rightfully be looked down upon. Shortcuts rarely lead to better quality or better testing in the long run, though they might provide a brief respite here and now. We should avoid that temptation, as it “dirties” us and our craft any time we do it. Test hard, test well, and yes, test clean. I believe it’ll be worth it :).

(10/12) All I Ever Needed to Know About Testing I Learned in Scouts

This is the tenth of a 12 part series.


As many of you know, outside of testing and raising a family, my single biggest time commitment is being a Boy Scout Leader. Over the past couple of years, I’ve seen and heard various presentations regarding a code of ethics around (teaching, development, testing, governance, fill in the blank). Each time I’ve heard or read these statements I’ve caught myself saying the same thing… “If everyone just lived by the Scout Law, we wouldn’t need this patchwork blanket of ethics rules and codes of conduct”.

My “challenge” now is to see if I really could map Testing to the Twelve Points of the Scout Law.

Note: these twelve points are those as defined by the Boy Scouts of America; while the Scout Law is similar in all countries that have Scouting movements, the wording is often a little different depending on the country.

“A Scout is Trustworthy, Loyal, Helpful, Friendly, Courteous, Kind, Obedient, Cheerful, Thrifty, Brave, Clean and Reverent”



A Tester is… Brave

Bravery is one of the most misunderstood virtues, in my opinion. Oftentimes, Scouts get bravery confused with foolhardiness or recklessness. they feel that charging into situations is the best way to show bravery and courage. I however have tried to show them that being brash is just that, it's not bravery. It's also not just the physical challenges that are placed before them. Does it take bravery to get into a kayak and paddle down a swift river? Sure it does, but another example of bravery is standing up to others who belittle you for your practices and beliefs. I know plenty of scouts who do very well in the former category, but do poorly in the latter. While I dislike the word "cowardice", the fact is that we all have a bit of it in us. where that cowardice lies and in what capacity is something every one of us gets to discover at various  times in our lives. the things that we fear are oftentimes not associated with physical challenge or threat so much as they are with emotional areas. We can see many different areas where fear comes into play. The brave person is not the one that can stop being afraid and do what they need to do, but the one who does what they need to do in spite of the fear.



In testing, we often have the thankless task of having to tell people they are wrong, or that they have done something wrong, or to show someone, perhaps an entire organization, that they are heading down the wrong path. make no mistake, this can be difficult, and very trying on the person who must bear this news. While attitude and approach have a lot to do with how well these things are handled, bravery and courage is required. It is important to stand for what we believe in, to commit to do what we say we need to do, even when it is convenient for us to cut corners. It may not be popular to take a certain position, or we may get a lot of push back for the information we deliver. It in these times that courage of conviction must be there, where we stand by our team, our mission and our values. Just as vital in this mix is having the courage to admit when we have been mistaken or have erred in our judgment or our methods. If we have discovered we are in error, or something did not happen in a manner in which we originally said it should or would, we much have the strength and courage necessary to step up, own up and determine what we will do going forward. For many, that is far more difficult than dealing with a physically dangerous situation.


Courage is far less about feeling than it is about action. we do not show or display courage by how we feel, we display courage in what we do. It is entirely possible to go into a presentation or an important make or break meeting and be terrified of what you are going to say. You could be terrified of the repercussions of what will transpire. The question is, do you go ahead and deliver your presentation? If so, then you have shown that you are brave and that you have courage. You may sit down and feel like you are about to faint, and don't be surprised to find out you're not the only one feeling that way about that particular issue. When it comes to dealing with people that feel fear and act, versus those who don't feel any fear, I'm less trusting of the latter than of the former. Not always, mind you, different people have different fears. Still, if someone always seems to be totally fearless and rushes in as though it is nothing, I tend to be leery of that person. Someone who has doubts and fears, but perseveres through them and accomplishes their goals anyway, that's someone I'm much more willing to put my trust in.

(9/12) All I Ever Needed to Know About Testing I Learned in Scouts

This is the ninth of a 12 part series.


As many of you know, outside of testing and raising a family, my single biggest time commitment is being a Boy Scout Leader. Over the past couple of years, I’ve seen and heard various presentations regarding a code of ethics around (teaching, development, testing, governance, fill in the blank). Each time I’ve heard or read these statements I’ve caught myself saying the same thing… “If everyone just lived by the Scout Law, we wouldn’t need this patchwork blanket of ethics rules and codes of conduct”.

My “challenge” now is to see if I really could map Testing to the Twelve Points of the Scout Law.

Note: these twelve points are those as defined by the Boy Scouts of America; while the Scout Law is similar in all countries that have Scouting movements, the wording is often a little different depending on the country.

“A Scout is Trustworthy, Loyal, Helpful, Friendly, Courteous, Kind, Obedient, Cheerful, Thrifty, Brave, Clean and Reverent”

A Tester is… Thrifty

Thrifty is a topic that is popular today due to economic uncertainty. It's certainly much easier and much more palatable to discuss the idea of thriftiness when there are challenges as compared to when things are going swimmingly. when I talk about the idea of being thrifty with a scout, it is not only about the use of money, but also resources, time and talents. It's knowing when to get the most out of a situation without having to break the bank to do it. It's about earning ones own way and practicing good management skills to meet a goal. It's about building up a diverse series of talents and skills to draw upon so that there is always something one can do in any number of situations.

Testers, likewise, learn to be thrifty as well. For most of my career, I have not had the benefit of a large budget for purchasing tool or for getting training, or for building infrastructure to test with. Some situations have been better than others, but generally my test jobs have required me to be creative and stretch my resources and look often to places where expertise and knowledge could be received inexpensively if not outright free. Having this mindset has helped me embrace and learn to appreciate and work within the areas of open source tools, and to learn how to set them up, configure them and take advantage of what they have to offer. Virtualization has proven to be a blessing for testing, in the sense that many aspects of multiple machines can be set up on a few servers (or in my current environment and reality, one server).

While open source tools can provide a lot of benefit for low price, there is also a cost in tool-up time and learning, and sometimes that can be very expensive in the long run. To this end, understanding the value of commercial tools and what they can potentially save in the long run is also important. The "thrifty" tester wants to avoid, or at the very least minimize wherever possible, the triple specters of monetary debt, time debt and what has been described by many other testing bloggers as "technical debt". these are challenges that require discipline, and require focus and continual learning. A thrifty tester respects both money and time, and realizes that tools and scripts will not solve all problems. there is no magic bullet or special sauce that will solve all problems. testers must make choices all the time in where they will apply their efforts and how they will be most effective. Thrifty testers do what they can to maximize those efforts as efficiently and inexpensively as possible

(8/12) All I Ever Needed to Know About Testing I Learned in Scouts

This is the eighth of a 12 part series.


As many of you know, outside of testing and raising a family, my single biggest time commitment is being a Boy Scout Leader. Over the past couple of years, I’ve seen and heard various presentations regarding a code of ethics around (teaching, development, testing, governance, fill in the blank). Each time I’ve heard or read these statements I’ve caught myself saying the same thing… “If everyone just lived by the Scout Law, we wouldn’t need this patchwork blanket of ethics rules and codes of conduct”.

My “challenge” now is to see if I really could map Testing to the Twelve Points of the Scout Law.

Note: these twelve points are those as defined by the Boy Scouts of America; while the Scout Law is similar in all countries that have Scouting movements, the wording is often a little different depending on the country.

“A Scout is Trustworthy, Loyal, Helpful, Friendly, Courteous, Kind, Obedient, Cheerful, Thrifty, Brave, Clean and Reverent”

A Tester is… Cheerful

When I talk to Scouts about Cheerful, it doesn’t mean that I say “be happy all the time”, because that isn’t realistic. The cool thing is, though, that when I look at most Scouts, they are naturally cheerful. It’s hard to keep them down. There’s a natural optimism that exists with them and in most cases, life tends to just roll off of them. Scouts tend to want to have opportunities, and to explore those opportunities. Given that state, it’s fairly easy to remain cheerful and upbeat. Even when life gets in the way, so long as the opportunities exist, and there’s a chance they can go out and pursue them, Scouts tend to keep their focus, enjoy what comes their way and make the most of the situations at hand.


As testers, don’t we tend to want the same things? I don’t expect the world to go my way every day every time, but I want to at least have the opportunity to see what works and what doesn’t. Given opportunity to advance and learn and grow and get involved with projects that challenge me, I tend to stay cheerful and optimistic. Are there times that that cheerfulness and optimism gets tried? Absolutely, but I also feel that pessimism has no place in the tester’s attitude. I realize that may sound strange… how can there be no pessimism when a tester’s very existence is to find out what’s wrong with a system? What I mean is that, while we are trying to determine if there are issues, that’s not our sole focus, and really shouldn’t be. If we get into the trap of only focusing on the negative aspects of a product, we tend to start viewing ourselves and our jobs negatively. We are the troublemakers; we are the ones that always find the problems. We are the ones that are seen as the hindrance to products not being released on time. It’s easy to get a sense of pessimism if we are not careful. In my view embracing the “Law” of Cheerfulness goes a long way towards preventing or at least deflecting those feelings and attitudes. Even if others want to view us by those stereotypes, there’s no rule that says we have to view ourselves the same way.

(7/12) All I Ever Needed to Know About Testing I Learned in Scouts

This is the seventh of a 12 part series.

As many of you know, outside of testing and raising a family, my single biggest time commitment is being a Boy Scout Leader. Over the past couple of years, I’ve seen and heard various presentations regarding a code of ethics around (teaching, development, testing, governance, fill in the blank). Each time I’ve heard or read these statements I’ve caught myself saying the same thing…  “If everyone just lived by the Scout Law, we wouldn’t need this patchwork blanket of ethics rules and codes of conduct”.

My “challenge” now is to see if I really could map Testing to the Twelve Points of the Scout Law.

Note: these twelve points are those as defined by the Boy Scouts of America; while the Scout Law is similar in all countries that have Scouting movements, the wording is often a little different depending on the country.

“A Scout is Trustworthy, Loyal, Helpful, Friendly, Courteous, Kind, Obedient, Cheerful, Thrifty, Brave, Clean and Reverent”

A Tester is… Obedient


I am willing to bet there are a few eye-rolls on this one. This is a word that as adults, we tend to chafe at. We want to say that we “question authority” and that we can think for ourselves. Obedience is often lumped in with puppies and small children, and an attitude of “do what you’re told!”. I’m going to argue that that is not real obedience, and I certainly do not advocate blind obedience.

When I refer to the Scout Law and say “a Scout is obedient”, I am referring to such things as the rules of being part of their families, schools, sports teams and yes, troops. In addition, Scouts also obey laws set by their communities and countries. If they feel that the rules and laws are unfair or unjust, they work within the system to have them changed, in a civil and orderly manner, rather than just choosing to not obey the rules. Blind obedience, doing what you are told and never questioning why, is every bit as bad as blindly rebelling (thinking of Marlon Brando’s character in “The Wild One” where the woman in the bar asks “what are you rebelling against” and he says “what have you got?”). Scouts who are allowed to question authority and assert a bit of independent thought and action are more likely to form a solid ethical foundation for their future, more so than those who just follow the rules, without question.

Likewise, testers who are allowed to question premises and test against the boundaries of situations are likely to find more problems than those who just “follow the script” they have been given. Testers need to see the big picture; without that big picture, they will find themselves stuck in a trap, testing without understanding what or why. Once a tester knows what they need to test for, however, they need to be able to determine an authoritative answer for their findings. Test oracles are set up so that we can make legitimate comparisons, and based on those oracles, we can say whether a system works or a system doesn’t work. For that determination, we have to be willing to set up the rules that we need to define the test, and then we have to follow those rules to ensure an accurate result. I would hazard that few testers would argue that “being obedient” in those situations is a bad thing :).

Wednesday Book Review: The Structure of Scientific Revolutions

 Through the years, I have come across a number of books that I have used and valued. These may be new books, or they may be older ones. Each Wednesday, I will review a book that I personally feel would be worthwhile to testers.

Wow, I’m really going back in time for this one (LOL!).

The Structures of Scientific Revolutions by Thomas S. Kuhn is recommended reading by both James Bach and Michael Bolton and mentioned in their Rapid Software Testing syllabus notes. It was here that I first heard of this book, and decided it would be an interesting read. Interesting? Yes. Easy? No!

This book was written almost 50 years ago, and there have been many “Scientific Revolutions” since, from plate tectonics to human genome sequences, and other advances that have added to the premise of Kuhn’s 1961 original edition. Kuhn’s work was to show that science and scientific discovery is often shown to neophytes and lay-persons as though it were an orderly march from one theory to another. In fact, scientific discovery and the “shifting of paradigms” (a term that Kuhn himself made famous in the succeeding decades) often goes through fits and starts, where one model of scientific inquiry works for awhile, and progress is made, but at some point, a crisis point is reached where the problems being faced can’t be solved the same ways with the same tools. To progress, a new way of thinking is required. The world didn’t change, just our perception of it, and that change in perception makes a huge difference. It’s also frequently fought tooth and nail by the very established practitioners of old ways, or at least until enough consistent proof of the concepts comes through that they themselves join with the new paradigm (or in some cases stubbornly don’t).

Why would I recommend this book to testers? Having had a chance to see James and Michael’s work and get to become more familiar with the approach towards “context based” testing, this is a book that really helps a person delve into the ideas of context and how context applies to all endeavors (science, philosophy, arts, business, software development, and yes, testing). To borrow from Steven Covey “We don’t see the world for what it is, we see the world for who we are”. In earlier times, humans could model their world where the Earth was the center of the universe and all things revolved around it. It’s not an accurate view, but much was able to be done with that model (sailors learned to navigate by the stars, super structures like the pyramids of Egypt and the Ziggurats of Mesopotamia were built, mathematical proofs still in use today were developed). In time, with the development of more sensitive tools, of finer measurements and a better understanding of principles, this view was called into question, and Copernicus finally had enough traction to make waves enough to cause the tide to turn in favor of a helio-centric solar system, of which the Earth is a part.

This is one of many “Scientific Revolutions” that Kuhn describes. Other examples include Galileo and the development of optics sophisticated enough to see details of distant planets and to discover asteroids, comets, and stars that were never observed before, making the universe a much larger place. The developments of Isaac Newton and the shaping of the modern science of physics is given a good shaking, and the developments are seen in their historical contexts (and not so unanimous at their time). Newton’s laws worked well, until they didn’t, and then another model was put forward to help fill in the gaps. That model was Einstein’s theory of relativity, which today is both lauded and criticized. Note that Newton’s laws did not suddenly become extinct; we managed to get to the moon and back using Newton’s theories.

Interestingly enough, up until 200 years ago, it was possible to be an active chemist and not believe in the existence of the atom. Kuhn goes to great lengths to describe the change in practice from a world where Phlogiston exists to a world where Oxygen exists. Note that the world didn’t change, but our perception of it did. The key element in Kuhn’s philosophy, as I see it, is that we tend to look at science as the discovery of “the truth” about our world, and that each generation shows the false traditions of the previous generations, and that they have discovered “the truth” this time around. Kuhn makes the case that “The Truth” changes as the paradigm for seeing the world changes. It’s also important to realize that a world view greatly colors what “truth” we see, and that often we will discard “truth” that doesn’t fit that world view. Thus it is important to try to see things in different ways whenever possible, and to take the opportunity to change the context that we view the problems we face. By changing the context, it is possible to see different solutions. Getting others to go along with those changed perspectives then becomes the challenge. Get enough to do it, and the world (or universe) can change.

One thing I must warn anyone who wants to read this book… if overly academically worded presentations bore you, this book will be a slog. It’s written in a very academic tone, and so often words used come across in a clumsy manner (hey, I’ll confess that I like things I read to be more conversational, and this definitely isn’t. For a 200 page book, it reads like a 600 page book for pace). The first few chapters may be challenging, but if you can get through them, the pace picks up considerably and the scientific issues and their times take center stage. Kuhn at times explains the background so that novices can appreciate what’s going on, but some areas take awhile to understand, and I found myself going to Wikipedia a few times so I could find out who Kuhn was talking about in certain sections (he is presenting this work to an academic body that is already intimately familiar with the material, so it’s not a surprise that certain areas do not get covered). Once you get past these areas, however, then the book becomes very interesting and many crisis points in the history of science are seen and how those crises are resolved is documented. There is a postscript hat was written in 1969 that clarifies a number of the thoughts and areas in the original version, but the premise is still the same; science, and scientists, do not see the world as it is, but as they are, and succeeding generations find more sophisticated ways and means to speak to the challenges they face, and they construct models that better help to explain and understand them.

The Structure of Scientific Revolutions is an opportunity for the reader to take a close look at what knowledge actually is, inside of the world of science, and ask themselves the fundamental questions of epistemology: What is knowledge, how is it acquired, what do people really know, and how do we know that we really know it? Is Structure of Scientific Revolutions a perfect example of this? No, but it definitely gives some great food for thought, and shows us that the neat and tidy progression that science is often portrayed as has often through history been anything but. For those looking for a good “shake up of the system” and a good primer in how to look at things from different perspectives, Structures is a pretty good starting point.

(6/12) All I Ever Needed to Know About Testing I Learned in Scouts

This is the sixth of a 12 part series.



As many of you know, outside of testing and raising a family, my single biggest time commitment is being a Boy Scout Leader. Over the past couple of years, I’ve seen and heard various presentations regarding a code of ethics around (teaching, development, testing, governance, fill in the blank). Each time I’ve heard or read these statements I’ve caught myself saying the same thing…  “If everyone just lived by the Scout Law, we wouldn’t need this patchwork blanket of ethics rules and codes of conduct”.


My “challenge” now is to see if I really could map Testing to the Twelve Points of the Scout Law.


Note: these twelve points are those as defined by the Boy Scouts of America; while the Scout Law is similar in all countries that have Scouting movements, the wording is often a little different depending on the country.


“A Scout is Trustworthy, Loyal, Helpful, Friendly, Courteous, Kind, Obedient, Cheerful, Thrifty, Brave, Clean and Reverent”



A Tester is... Kind

When I speak to Scouts about the meaning of the word "Kind", it is of the idea that they understand that there is "strength in being gentle". They treats others as he wants to be treated. They do not hurt or kill without reason. These phrases are often used to discuss a scout's endeavors in the wild. When out on a campout, it's common to go fishing and to catch fish to eat at the campout. That's not being unkind, that's doing what one does to get food. Willfully going out and bashing a bird or an animal with no reason (i.e just for the fun of it) would be seen as unkind. Likewise picking on someone else would also be seen as being unkind. 

Why do I liken this to the Tester?  It's great fun to poke holes at a product, and it can also be fun to give developers a hard time for their mistakes. However, karma can be really hard on people, and many times, unkindnesses have a way of being remembered and often redressed. When we find something out of place or not working correctly, it's rarely approppriate to crow from the rooftops that we have found something truly awful. Do development teams need to know that information? Absolutely they do, but they do not need to be subjected to ridicule and/or derision while bad news is being delivered. I've seen some crass attitudes from some testers over the years, and sadly, the most crass of them have come from environments where testers have been treated like second-class citizens in their respective companies.

Notice, one unkindness often begets another, and so on. Given the choice, I would certainly not like to work in that kind of environment, so I want to strongly encourage any testers out there, whether you have been treated unkindly by others, resist the urge to follow suit. A little kindness goes a long way, and for those environments that don't reciprocate, do yourself a favor and get out of those organizations and find one that will. Life's too short to foster bad blood.

Note: I will be taking a break from this series tomorrow so I can stay on track with my book reviews. Part 7 will appear on Thursday :) ).

(5/12) All I Ever Needed to Know About Testing I Learned in Scouts

This is the fifth of a 12 part series.


As many of you know, outside of testing and raising a family, my single biggest time commitment is being a Boy Scout Leader. Over the past couple of years, I’ve seen and heard various presentations regarding a code of ethics around (teaching, development, testing, governance, fill in the blank). Each time I’ve heard or read these statements I’ve caught myself saying the same thing…  “If everyone just lived by the Scout Law, we wouldn’t need this patchwork blanket of ethics rules and codes of conduct”.


My “challenge” now is to see if I really could map Testing to the Twelve Points of the Scout Law.


Note: these twelve points are those as defined by the Boy Scouts of America; while the Scout Law is similar in all countries that have Scouting movements, the wording is often a little different depending on the country.


“A Scout is Trustworthy, Loyal, Helpful, Friendly, Courteous, Kind, Obedient, Cheerful, Thrifty, Brave, Clean and Reverent”


A Tester is... Courteous

Courteous comes down to a simple phrase... be polite. That doesn't mean that you have to be a wet rag and not state an opinion, or tell it like it is, but you can and should do it in a way that shows respect and courtesy for the person or organization you deal with. The opposite of courtesy is disrespect and arrogance, and having had my share over the years of dealing with developers and testers that have exhibited plenty of disrespect and arrogance (and hey, I am certain I've exhibited my fair share a time or two as well) I'll gladly and much more willingly work on the "Courteous" side of the coin.
 
There are times where our best intentions come off as being rude and obnoxious. I had an experience like this regarding one of the developers on a team I was working with. I had gotten into the habit of stopping by his cube when I'd found something interesting, as this was the dynamic we had fallen into. I thought I was being helpful by telling him about the various things I was finding, and since we sat near each other, it just seemed like the easiest way to communicate the issues. Well, with time and familiarity, I continued to do this, until one day I received an IM message where the developer basically said "dude, could you lay off the snarky comments about the code? It's really starting to get annoying!"
 
This was an example of where I realized I'd crossed the courtesy threshold. It was unintentional, and it was all a part of "improving communication", but I realized as we worked through this his perception of my "being helpful" was turning out to be anything but. Because of that, I decided that I could do us both a favor by just using the issue tracking database (which I was doing anyway) and just leave the casual commentary about my findings out of it. Fortunately, the developer in question and I had a good relationship, and he was able and willing to come out and say I was being a jerk. I also was willing to step back and say "yeah, I am being a jerk".
 
Being courteous is more than just the obvious "be polite" or "be professional" stance. It's really doing our best to understand where the other person is coming from and making our best efforts to show respect and to be a help to the people we work with rather than a hindrance  It's knowing when to step in and give a hand, and knowing when it's OK to let someone work through something so that they can learn and develop the skills they need to. It works upwards and downwards, with senior staff and with junior level interns. It's having a conversation where you can disagree without being disagreeable. Mostly, it comes down to showing those you work with that you respect them, and that you deserve respect in kind.

(4/12) All I Ever Needed to Know About Testing I Learned in Scouts

This is the fourth of a 12 part series.


As many of you know, outside of testing and raising a family, my single biggest time commitment is being a Boy Scout Leader. Over the past couple of years, I’ve seen and heard various presentations regarding a code of ethics around (teaching, development, testing, governance, fill in the blank). Each time I’ve heard or read these statements I’ve caught myself saying the same thing…  “If everyone just lived by the Scout Law, we wouldn’t need this patchwork blanket of ethics rules and codes of conduct”.


My “challenge” now is to see if I really could map Testing to the Twelve Points of the Scout Law.

Note: these twelve points are those as defined by the Boy Scouts of America; while the Scout Law is similar in all countries that have Scouting movements, the wording is often a little different depending on the country.


“A Scout is Trustworthy, Loyal, Helpful, Friendly, Courteous, Kind, Obedient, Cheerful, Thrifty, Brave, Clean and Reverent”


A Tester is... Friendly


From the Scout Handbook - "A Scout is friendly. A Scout is a friend to all. He is a brother to other Scouts. He offers his friendship to people of all races and nations, and respects them even if their beliefs and customs are different from his own."


Testing likewise builds on the same philosophy. there are those who do not understand what we do and all too often belittle or demean our craft. Is animosity going to win anyone over to our side or our way of looking at things? Generally, no. We are much more apt to encourage directions of development and policy where applicable when we try to do it in a spirit of friendship and friendliness. If we have a differing view, we should be willing to discuss it rationally and give others that same opportunity to do the same. Forcing others to see our view or belittling their efforts in kind, perhaps because they belittled ours first, does not give us many opportunities to change things.


Testers should be focused on working with others, and be willing to give them the benefit of the doubt unless or until they prove not worthy of it. This is not to say that testers should be passive and not stand up for what we believe in or feel is appropriate, but there are ways in which we can do it that are nost specifically antagonistic. If testers pre-judge based on previous background, prejudices or other means that don't have any bearing on the tasks or projects at hand, they are setting themselves up for failure, or at the very least, working at less than optimum effectiveness. Yes, I'm saying go out on a limb and expect that others will treat you in a friendly manner if you do so as well. Seem like total common sense? Yeah,. I think so, too, yet I am astounded at times to see the rancor and bile that occasionally has built up between development and test organizations. It doesn't have to be this way. It is possible to express deeply held opinions and do so in a manner that preserves a relationship. It is possible to disagree without being disagreeable. While it's possibly too much to ask that we become friends with everyone we work with, I feel it certainly helps to start from that premise.

(3/12) All I Ever Needed to Know About Testing I Learned in Scouts

This is the third of a 12 part series.

As many of you know, outside of testing and raising a family, my single biggest time commitment is being a Boy Scout Leader. Over the past couple of years, I’ve seen and heard various presentations regarding a code of ethics around (teaching, development, testing, governance, fill in the blank). Each time I’ve heard or read these statements I’ve caught myself saying the same thing…  “If everyone just lived by the Scout Law, we wouldn’t need this patchwork blanket of ethics rules and codes of conduct”.


My “challenge” now is to see if I really could map testing to the Twelve Points of the Scout Law.



Note: these twelve points are those as defined by the Boy Scouts of America; while the Scout Law is similar in all countries that have Scouting movements, the wording is often a little different depending on the country.


“A Scout is Trustworthy, Loyal, Helpful, Friendly, Courteous, Kind, Obedient, Cheerful, Thrifty, Brave, Clean and Reverent”

 
A Tester is... Helpful
From the Scout's Perspective we encourage the interpretation of  "A Scout is helpful" to refer to the fact that a Scout cares about other people. They will willingly volunteers to help others without expecting payment or reward for what they do. the phrase "Do a good turn daily" fits right into this notion.


Testers by their very definition are there to be helpful. While it's possible that some testers are deliberately malicious because of pure malicious intent, that's been a very small subsection of the testers I've known and worked with. While we do not entirely ply our trade without expecting payment or reward (hey, I have to eat, too, ya know :) ), I certainly try and encourage others to give a hand to those who need it. Most of the other testers that I have known and learned from felt the same way. Typically, if you ask a tester for help with something, we will expect you to do some of your own homework first, enough to be able to ask and answer a few searching questions. Once we know that you have done that, we as a group are very giving of our time, our talents and  our resources to others in the testing community.


Do a search for the number of testing podcasts that exist and see how many of them you have to pay for. There's hundreds of hours of instruction, encouragement and new ideas to listen to and find out there, and much to learn without spending a dime. Many testers know that if you give away what you know, others will seek you out and pay for what you know. Showing that your ideas can be had for free broadcasts that you have ideas to spare, and companies tend to respond in kind. Being tight-fisted with your time and your advice and not contributing to the community as a whole tends to isolate you and that ability and brilliance that particular tester may have doesn't get a chance to be seen by many people. Given the choice, I'd rather be one to help others. One never knows how and when those you helped may return the favor (and no, I'm not keeping score, that's not the point :) ).