While I’m on the Topic of Teaching…

This week, the class that is taking the Black Box Software Testing: Foundations course through the Association for Software Testing is completing their run. That means I'm completing my first run as an assistant teacher. As many of you know, I was a participant in this course just two months ago, and was excited to have the chance to work on the other side of the process.


My reasons for volunteering to help teach Foundations are numerous, but the most specific reason is that I feel I learn much more than I do as a participant when I have the opportunity to teach something. For starters, I find out where my vocabulary is lacking. I also get to see discussions take place with a different group of participants, and this group, true to form, asked a number of questions that my group of participants did not. Because of this, I'm not just acting as an assistant instructor, I'm getting the chance to sit as a participant again as well and reinforce what I learned the last time (and in some cases, dispel and unlearn what I thought I learned, but didn't really understand as well as I could).


Foundations' is delivered entirely online, through an open source education platform called Moodle. There are many interesting aspects about Moodle that I was able to work with and participate in; the setting up of safeguarded areas so that students couldn't work ahead (or at least keep certain things hidden until the right time), the ability to have students take tests and see their results recorded (as well as a few choice words after the fact; believe me, I used a few myself when I was a participant in the class (LOL!) ). Seeing it from the other side gave me a better appreciation for how the students were doing, and what challenges they faced. I thought for sure I was messing up in the class early on, but looking from the other side and comparing the scores achieved by all of the participants, I saw similar trends emerge. Some did well across the board, some struggled early on, and others were in the middle ground with strengths and weaknesses in certain areas. It wasn't as though long time veterans all did well and new participants did poorly. It was striking to see that even long time testers (15 years plus in some cases) were finding the course material challenging.


To be fair, Moodle is not a perfect platform. We had some hiccups along the way, and the help forum in the class had a number of questions raised, most of which we were able to answer and resolve. Some items were just the nature of the tool (imagine, there are bugs in a program to teach testers regarding testing and bugs :)? ). Still, I do not mean to besmirch Moodle as a learning delivery platform, it's actually a very good piece of software. As a veteran earlier in the last decade of distance learning and having most of our work being done via email or newsgroups, the structure of the Moodle application to allow access to discussions, reviews, documents, videos, presentation slides, projects and a grading mechanism for the instructors allows those who use the system to get very good feedback on what they are doing. Far from just being a sit there and listen/read/mark time environment, Moodle allows the instructors and the students to interact in a legitimate manner, for all to see, so that all have the opportunity to participate, try things out, make mistakes, receive review and discuss where they went wrong/right, and generally have a good learning experience in the process.


Through the class, the instructors also had a chance to see what worked and what needed to be improved with regards to delivery, approach and methodology of the course material. Having a chance to work through certain issues and challenges with the other instructors gave me a good idea as to how the teaching process works through AST, and it also reinforces what I have read about Cem Kaner and his approach to tester education, as well as his dedication to it and the goal to improve it. I was expecting this class to be much like the one I participated in, and in many ways, it was. But it also had a number of ways in which it was completely different. That has to do with the fact that real people help to guide the course. Real people with strengths and challenges of their own, and this makes for a dynamic and interesting learning environment, one that has the participants mulling over, presenting and defending their answers, often with new and different understanding being offered, considered and incorporated, for students and teachers alike.


There's just a couple more days left, and this course will be history for those who participate in it. Thank you to all who took the time to get involved, as a participant and as a student. I enjoyed teaching you all, but in reality, I think I may have learned a lot more than I actually taught. I can't wait for the opportunity to teach it again (and it looks like an opportunity for another tour of duty may be coming soon, but more on that later :) ).

Wednesday Book Review: The Social Life of Information

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.

This book came recommended by both James Bach and Michael Bolton after I told them about my interest and reflections on 'Structure of Scientific Revolutions". I noticed that the book was written in 2000, and therefore this falls into my "retro" review category (which I guess is a silly differentiation, because if this blog hangs around long enough, most of my reviews will eventually be retro :) ).

The Social Life of Information by John Seely Brown and Paul Duguid goes beyond the idea of bits and bytes and the promise of the "Information Age" and looks at the reality of what actually happens. We like to look at the Internet as being some great arbiter and game changer in the way that people interact with each other, but in reality, much of what we see and how we interact with the internet and others on it match the way we try to interact with people in everyday life, and then we see what happens when many of the "social cues" that we are used to have been removed from the process. Creating new ways of accessing information doesn't bring us closer to a "more perfect world" unless the human element of that interaction is somehow enhanced or involved. This book predates the social media boom, so many of the case study examples, while interesting, just beg the question as to how they would be handled if the key "social" idea wass around in today's form when this book was written  (I wonder what a second book of its type would look like with MySpace and Facebook as case studies :) ).

The central point of the book is that information in and of itself has limited application. It's the context of that information and the context of how it is used that provides value (or worthlessness, or praise, or notoriety, etc.). The information itself does little, but the people that interact with it greatly determine its ultimate value. What's more, in the real world, information itself is of limited use without the expertise, craftsmanship and, yes, the social aspects of human beings interacting with that information. Tools are good, but the tools themselves do little in the way of actual thinking and analysis.

Personally, I found the middle chapters to be the most valuable sections. These are the ones that provide insights and contexts for testers, examples of learning and epistomology and some descriptions of real world case studies that, for best intentions, caused more problems than they solved. The case is made early in the book that the value of information is not as limitless as it's been portrayed. In short, this book gives the best value in the sections where it pleads with those who would cry with joy at the saving grace of technology and say "the technology itself is of limited value without the direct, focused and "sapient" use of the information by a person or team of people guiding that information along to useful means".

Much of the book describes situations that occur in various companies, Xerox PARC being a recurring location and focus of interest. Issues ranging from bots to operating systems, to overwrought complexity to telework are addressed, and in each case, the ramifications of decisions are demonstrated and compared. Telling is the example of an office who tried to remove all aspects of a determined corporate culture and office processes and replace it with the freedom of a college lounge. What they got instead was a classic high school style experience, complete with bullies, loners and outcasts. The goal was to make work less dependent on processes and equipment, but never took into account the human elements that makes the flow of information and the flow of work happen in the first place. Automation and distribution of effort provides a small level of breakthrough in understanding, but less than the information and tools would indicate. Instead, it's the interactions between people and the context in which they work together that provides the value in the interaction.

Bottom Line:

While much of the book is dated now, it was interesting to relive some stories I remembered hearing about and contemplating a decade ago. Some of the promise of the technology of our era has come to pass, while many other areas have been less fruitful and still have much room for improvement. The key idea is that technology and information alone are limited and limiting in what they can do by themselves. To be useful, and to grow and thrive, they need communities of actively engaged people to use that information and the technology to its fullest advantage. It would be interesting to see an updated version of this book to take into account the changes the past decade has given us (wonder what the authors would have thought of the iPhone and iPad, social media in all its glory, and the bursting of the dot-com bubble, which this book *just* misses).

What Can A "Woggle" Teach About Testing?

Since my Troop is gearing up for Scout Camp in just a couple of weeks, I've been spending a lot of time with my Scouts getting them ready for camp, including all of the various activities that go with that. Usually, this includes such things as making sure everyone has the necessary gear, that they have the books, the equipment, and the items that will make for a good week for everyone. In addition, one of my standard "traditions" is the making of "woggles" for each of the camp attendees.

For those who have been Scouts, or have ever seen a Scout in uniform, you may notice that many of them wear a kerchief around their necks. The kerchief is usually held on by a slide of some sort. There are various items to be used as a slide, and my guys have make a number of them over the years, but I still say that the Woggle is the most useful slide because, in a pinch, it can be used for something else. Unlike a dedicated slide which is just a piece of ornamentation, a Woggle allows the user, if they need to, have a piece of 3 foot long rope that they can use for whatever purpose, emergency or otherwise, might call for it. It's with this in mind that I have made these various Woggles (also commonly referred to as a "Turk's Head Knot") for my Scouts over the years.

This year, I decided to teach them how to make one themselves. Over several years, I have gotten to the point where I can make these with my eyes closed, but that doesn't help my Scouts to make theirs if they need to, especially if they end up having to undo theirs in an actual emergency and then recreate it later. Thus I decided to sit down and show the boys how to make them. Easy enough, right? Well, not exactly!

One of the reasons that I had grown to be able to make these Woggles easily is that I've literally made hundreds of them over the years. Repeated practice makes something automatic. The problem is communicating that "practiced automatic" technique to someone else. My experience showed that what was second nature to me, and thus very simple, was foreign and difficult to almost everyone else (adult and youth alike). Even when I broke it down to its simplest components, and walked them through the steps very slowly, it was not something I could easily explain or demonstrate. It took a considerable amount of time and many false starts before the people involved in my demonstration of tying a Woggle/Turk's Head were able to create their own. What was I doing wrong?

I realized that I was trying to make everyone work with my view, that if everyone did it just the way I did it, it would be simple and everyone would be able to make a Woggle. Instead, I dealt with several frustrated boys and adults who had difficulty following my instructions and about half gave up in frustration and asked me to help them make them.

Left to my own devices, I would do exactly that, but this time, i wasn't feeling so generous (not to mention that in this particular case, that is totally my M.O., to generally teach a skill, and then when the person in questions doesn't do it right, just take it out of  their hands and do it for them). This time, however, I vowed I wouldn't do that, and I would talk through whatever it took to communicate how to create the Woggle.

Through this effort, I realized that I have limits to my knot-tying vocabulary. There are many phrases used to describe the end of a piece of rope (the lead), a curve in rope (the bight) and the interaction between them to describe the knot in question. To those familiar with tying knots, saying a "three lead by four bight" Turks Head conjures up a specific image and method for making a woggle, but even with that terminology, it still doesn't get the neophyte closer to making a completed knot.  The only way to get proficient at making a knot is to practice it, make mistakes, get frustrated, try again, perhaps repeat the scenario 3 or 4 or more times until the person making the knot has that "a-ha" moment and they can easily create the knot. After creating it, it takes practice to get smooth at the process, but keep at it, and the process does indeed become smooth (or at least smoother :) ).

When we test, we often see a task as either easy or difficult, depending on our immediate viewpoint and history. For me, making a Woggle is easy, because I've done it more than a hundred times. For the neophyte, even with specific directions, it can be a challenge to make a good Woggle. Techniques likewise are very individual; not every person is going to follow the exact same steps the exact same way. Using my Turk's Head/Woggle example, there are several ways to make this item, and each one is as correct as the previous method. Likewise, there are many testers who will come to a problem with multiple solutions, each one potentially accurate, each one offering a solution. In making a Turk's Head knot, there are many ways to make it that yield the same results (and there are many ways to make it so that the net result is an entirely unusable item or a failure to finish creating it). Each of us had a need to create a framework for a problem, try out steps to see if we can determine if an approach works, and then use that knowledge to do the same steps again. Do it multiple times, and we can determine if an issue can be tested, just as we can determine if a particular approach will create our Woggle/Turk's Head. It's in the doing that we find out what works and what doesn't, so get out there and do :).

For those who are interested in trying your hand at making your own Turk's Head knot, this is the method I most frequently use and describe.

Stages of Team Development and “The Teaching EDGE”

Yesterday I shared a story about how my scouts went about trying to solve a problem, and the way that they reached their decision and ultimately solved the problem. While I was working with them, I reflected a bit on something I learned in Wood Badge some time back, and sure enough, as I looked at the situation, I chuckled inwardly that the information we learned (and that I now teach) regarding how teams and individuals work, really is how it is explained at Wood Badge.



In Wood Badge, we talk about the Stages of Team Development. The key words that we use for these stages are "Forming – Storming – Norming – Performing". The idea is that, when presented with a challenge and a group to overcome that challenge, they go through these steps, each and every time. When a group forms, they are usually excited about the task, or at least willing to do it, but they may not know what to do (and even if they do know what to do, they don't yet know how to do it as a group). As they get into the situation, the "storming" part comes in. Different ideas as to how to do what they need to, potentially a drop in enthusiasm, perhaps even some griping. After working a bit, the group starts to come together and agree on some things, and with this agreement, they start accomplishing the tasks that they need to, and ultimately, given enough time and practice, the group is able to work together and quickly perform the task they were assembled to do.

This is not a new discovery, and the Boy Scouts and Wood Badge do not own this model of understanding (it was first proposed by Bruce Tuckman back in 1965). This just happens to be the way that I have grown to understand it, and hey, it makes sense. We can look at each section and the results of each stage:



Forming: enthusiasm high, skill level low

Storming: enthusiasm low, skill level low

Norming: enthusiasm rising, skill level rising

Performing: enthusiasm high, skill level high



Every team goes through this, and also just about every individual goes through this as well. Wouldn't it be great if we could plan the way that we instruct to use this information optimally, seeing as we know that everyone will have to go through these stages? I'm glad you asked, because there is such a way to teach that takes these stages into account. Again, I'm going to use the Wood Badge/Scouting terminology. In Scouting, we call this technique E.D.G.E. It's a simple acronym, and it stands for Explain, Demonstrate, Guide and Enable. Each stage of the acronym is used alongside the Stages of Team Development.



Explain goes with the Forming stage: This is where the group first comes together and the issue/ challenge/ area of interest is first introduced. The person instructing needs to be clear and direct about how the process should work. Emphasis needs to be on the big picture here, and letting people know the key items they need to know/learn/do.



Demonstrate goes with the Storming stage: There will be confusion, different interpretations, different levels of motivation, but invariably, there will be some frustration. This is where having someone show what needs to be done is important. It's also where some encouragement may need to be used, to show others "hey, this can be done, I'm proving it right now".



Guide goes with the Norming stage: At this point, you have shown what needs to be done, now it's time for the group to get their hands dirty and get involved themselves. It's likely that you as an instructor will need to step back and demonstrate again once or twice, but the goal is to get the principals involved and doing it themselves.



Enable goes with the Performing Stage: By this point, the group knows what they have to do, now you just have to step back and encourage them to keep going and keep getting better.



At times there will be set-backs. You may add another person to the team, or you may lose a person. You as a principal may move into another group and have to learn the ropes all over again. Perhaps your team has gotten proficient, or even expert at a particular sequence, but now it's time to go and do something else. At each of these points, the progress on the Stages continuum changes, and in some cases, could be knocked all the way back to square one. It's important to recognize where they stand, and adjust your teaching style to the appropriate level.



On Tuesday night, my scouts were given a task; put up a tent as a team. They were willing to do it, and were ready to participate. Some of the boys had never set up a tent before, while others were old pros. When they discovered that the tents in question were missing pieces and the situation changed from just setting up a tent to having to salvage and repair the tent, I saw the frustration and heard the griping. The situation had become a lot less fun at that point. By demonstrating to them some troubleshooting ideas, they were able to start thinking of solutions, at which point I encouraged them to try the solutions they considered. Finally, I stepped back and let them try the solution and continue on as it became clear that their solution would work.



In testing, either as test teams or individually, we are bound to find ourselves in this same situation. By recognizing these levels of team and skill development, and where they happen (and understanding what stage we are at, whatever you may want to call them) we then as testers have the ability to know what we need and when we need it. Additionally we know when we are the teacher/coach/manager/mentor what level of involvement we need to be at for each respective stage. I believe that, by understanding these stages and the appropriate response, we can minimize frustration and down time and maximize the potential to perform well, both as individuals and team members, both individually and collectively. It's a simple process, but don't mistake simple for easy. Getting good at this takes time and practice, just like any other skill set, but with time (and practice) even this approach becomes ingrained and just part of everyday thinking and action. Try it out with your team, and see what you think.

Using Your Resources

For those new to this blog, in addition to being a software tester, I'm also a Scoutmaster in the Boy Scouts of America. Last night I had the opportunity of exploring a challenge with some of my younger scouts. We had two tents that had been used by some boys in the past, but put away badly. The result was that some of the gear was lost or damaged, poles mismatched or missing, and otherwise impossible to construct both tents. What started out as an exercise to see who could put up a tent using teamwork became something else entirely, a chance to discuss a problem and see how they could solve the problem.


What we had were two tents, both different sizes, both using similar poles and rain fly's but not the same size. Looking at the smaller tent, it was missing one of its poles, and looking at the larger tent, it was missing two of its poles. The larger tent allowed for more room and better storage, but its rain fly was torn in a spot and there were cut marks on the floor (small ones). Both tents were missing pieces; neither tent could be raised by itself. Faced with this, what could they do?


Their answer was interesting. They looked at the way that the larger tent was constructed, and determined that, if they were to somehow lengthen two of the poles that were originally part of the smaller tent by one section (approximately 18 inches), they could fill out and provide the structure needed to make the full tent stand. With this, they took one of the poles from the smaller tent and cut the bungee cord holding them together, removed two 18" sections, and pulled the rubber ball type end off the original poles to add in the new 18" sections at the very end of the poles, so as to keep the poles intact, but provide the extra length needed for the tent to remain tight. It worked! From this, they were able to then look at the tent interior and determine where they could make some simple repairs (such as stitching and gluing areas where the nylon had ripped) as well as removing parts from the smaller tent that could be used on the larger tent. I found it interesting to see that they chose the option of augmenting the larger tent rather than try to salvage the smaller one, even though the smaller one for the most part had more usable parts. Their reasoning was that the larger tent would hold more people and gear, and therefore was worth more to the organization (i.e. the Troop) to be in serviceable shape than the smaller one was. They also recognized that it was easier to add a section to two of the poles than it would be to cut down longer poles for use in the smaller tent.


The boys may not know this now, but they worked together in a team to solve a problem the same way many engineering teams do. They gathered together with the goal of doing one thing (quickly raising a tent) and discovered a problem (mismatched and missing parts). They talked together and brainstormed ideas as to how they could set up the tents. They experimented and tested out ideas to see which parts went where. They realized that they would be unable to set up both tents with the parts that they had, but that they could create a solution to make sure one of the tents was usable. They applied their ideas and made a prototype to test a fix. They applied the prototype and saw that it would work, and quickly applied the same idea to the other pole to finish the job.


Sometimes we find that we have to be creative to solve problems. That creativity allows us to look at solutions we might not consider. I explained to the scouts that this might be an example of something that might actually happen in the wild, where two tents may get damaged, or parts lost along the way. As Plato pointed out over 2,000 years ago, necessity is the mother of invention :).

Wednesday Book Review: On Hiatus This Week

I knew it had to happen sooner or later, but due to my being out of town for five days with family and having very limited quiet time, I'm sad to say that the Wednesday Book review will not appear this week. This is the first time since I started Wednesday Book Review that I have had to miss a week, and yeah, I feel a little bummed. I will, however have it next week, so stay tuned (the next title will be "The Social Life of Information", a book recommended to me by James Bach and Michael Bolton).

Software Test Professional and TWiST

For many people in the testing community, this may be redundant, but on the off chance you are not dialed in to most of the mainstream testing sites, blogs, and peeps, I’d like to draw attention to an initiative of Software Test Professional and Matt Heusser called “This Week in Software Testing”, or TWiST.

Matt is the host of this little adventure, and last week Matt marked the third installment. The primary delivery method is via podcast, and for your time you get to hear a 30 minute or so interview between Matt and others of the testing world who share their experiences, accomplishments and frustrations.

For those who missed the first two installments:

• In TWiST #1, Matt interviewed Lanette Creamer (aka Testy Redhead) about costs involved with testing.

• In TWiST #2, Matt interviewed James Bach, and provided links to two interview segments, one the primary interview and the second is a “bits and bytes” conversation about self education and what James means by being a Buccaneer Scholar, as well as a link to a talk given regarding software schedules and risk management at the 2006 Indianapolis QA Conference.

In the most recent installment, TWiST #3, Matt brings us more shiny testing goodness in his interview with Jason Huggins about Selenium, as well as providing links to a tutorial on using the Selenium IDE (registration required, but its free), plus video links to two of Jason’s talks about Selenium.

Go to the page to see more, and while you’re at it, add TWiST to your regularly scheduled reading (err, listening). I think you’ll find it worth your time :).

Wednesday Book Review: Agile 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.

In many ways, this book requires two reviews. One would need to be for the reading and the information imparted, the other would be for the applicability of the principles. As the organization I am working with is just now embarking on its first full scale Agile project, I will have to save the applicable review for later, as to be frank, I just do not have the experience level to speak to them as of yet. So today’s review will have to be to the readability and ability to comprehend the ideas that are in Lisa Crispin’s and Janet Gregory’s Agile Testing: A Practical Guide for Testers and Agile Teams, and to that end, this is an excellent title to dig into and learn about Agile practices.


At 576 pages, there is a lot of material to digest, but the pace of the book and the breakup of topics allows the reader to cover a lot of ground quickly. The book begins with an explanation of Agile goals and responsibilities, and also includes the “minor heresy” of removing the context of the testers as a stand-alone unit. Make no mistake, for those who have worked in traditional development environments, this book may well come as a shock to the system. Lisa and Janet make the point that the testers do not stand apart from the development team. In fact, they are directly integrated into the development team and stand right next to the developers in scope and impact.


Each chapter beings with a “mind map”, which helps to organize the sections to be presented, and in many ways, readers can look at the mind map graphics and get a very quick understanding of what the next chapter will cover. This is by design, and it is meant to instill the idea of breaking away from strict, structured documentation that, while complete, is often ponderous and time consuming. By contrast, the mind maps allow a quick scan to see what the main points of the section will be, and then with that information, the reader can dive in and follow along.


Agile Testing is broken up into six areas.


Part I introduces the reader to the roles and activities of an Agile team, and defines the roles and responsibilities of a Customer Team (everyone who helps define the business aspects of the product and how they will be implemented) and a Developer Team (how to determine the method in which the customer’s objectives are actually met), As tester’s, we are firmly planted in both teams, and are expected to contribute to both. Lisa and Janet make it clear that the role of an Agile Tester is to not act as the “gatekeeper of quality”; that role belongs to the entire developer team, and we are part of that process. The ones who decide on the quality criteria are the customers. The key to Agile for testers is that we get engaged early, and our testing efforts drive the project forward with steps made in a much more rapid fashion than traditional development environments. In an Agile environment, everyone is a tester, whether they write code or not. The defining attribute of a successful Agile tester has less to do with skills than with attitude, one that embraces change, experimentation, and collaboration.


Part II describes the organizational challenges of a team making a shift from traditional development methods to Agile. There are often large scale changes that take place, and for many people, long established roles and scopes are often moderately tweaked or completely thrown out the window. Giving up the idea of an autonomous and totally independent testing team can be a jarring experience, but it doesn’t have to be. It’s also not just the testers who go through a period of adjustment and re-calibration. Developers, project managers and executives often have to get past comfortable niches to embrace an Agile environment, and adapt to a faster and more focused work schedule. The change can be chaotic and scary. Being willing to work with that fear and try new things is one of the primary keys to success. Most important is coming to grips with the fact testing is not treated as a separate activity that occurs after development, but that testing and coding are integrated activities and happen side by side. Processes are treated differently in Agile projects. Unlike traditional gated development methodologies which have heavyweight process documentation, Agile takes a different approach. It doesn’t do away with the need for test plans, requirements documents, bug tracking or auditing requirements, but it approaches them from a different angle, maximizing effective time and effort on the tasks of developing quality software, and providing enough documentation and process to get the job done (with a hearty emphasis on the "enough", as in no more than :) ).

Part III introduces the Agile Testing Quadrants, and these areas of testing appear in the subsequent chapters. This area focuses on The Story and how that story helps to drive both Technology-Facing Tests and Business-Facing Tests, and how The Story helps to develop both the underlying code requirements and the necessary tests. The Four Quadrants becomes a consistent theme for this section, and using each of them (Q1: Unit Tests and Component Tests; Q2: Functional Tests, Examples, Story Tests, Prototypes, Simulations; Q3: Exploratory Testing, Scenarios, Usability Testing, User Acceptance Testing, Alpha/Beta Testing; Q4: Performance & Load Testing, Security Testing, other “ility” testing) and the context of each set of tests. The tools required to perform these tests are also described, and some examples as to when they are used (Test Driven Development, Continuous Integration, source code control, etc.).

Examples and business-facing tests are emphasized, with the idea of working on small areas in short iterations, to give the customers a chance to see how the product is developing and get real time use of the application and offer feedback for the next iteration. In this stage, working with the team to break up feature into smaller and more manageable stories is presented, with an emphasis on what Crispin & Gregory refer to as “write test-write code-run test-learn”. Some example tools are shown to help organize the Agile tester to prepare to develop stories and convert then to requirements and tests, ranging from simple index cards and paper models to using spreadsheets and full feature test applications such as Fit and FitNesse. An emphasis and an excellent description of Exploratory Testing and practices associated with it are explained. This may be a surprise to some who felt that Agile was all about automated testing. Crispin and Gregory make very clear that a live person paying attention to the details is critical to the success of an Agile project.


Part IV goes through the process of automating tests associated with an Agile project. The fact that it is necessary is a given, but getting started is often the biggest challenge for some organizations. Barriers to successfully implementing automation are discussed and strategies for implementing automation in an Agile environment are covered. Crispin and Gregory make the case that using the four Agile testing quadrants will help identify where test automation will be most needed, and when. Focus on repetitive actions wherever possible, specifically when you perform builds (continuous integration, anyone?), unit tests, functional tests, performance test, etc. It’s also important to realizes that automation is good in key areas, but it’s not a silver bullet. There are areas where real human interaction provides more value than the promise of automation will.


Part V covers the testers role in the life of an Agile test iteration and provides lessons learned to show where testers add value and when. Testers definitely have an early hand in the development of user stories and using the time to clarify and focus on these stories and developing test cases around them is critical early on. Planning for the upcoming tests is also important, whether that be prepping environments, implementing test scripts (manual or automated), or gaining better clarity of the scope of testing can be time well spent. During the iteration planning session, testers can get ready by making sure that task and test cards are written along with development task cards, and given an realistic assessment as to how long those tasks will take. Once coding begins, the tester gets involved with quick iterations of test-code-review-test increments.

When problems arise, use the "Power of Three" to help resolve the issue (Power of Three being get three different viewpoints from three different people before making a change or committing to a course of action). Add automated tasks where feasible, and allow time for manual exploratory testing to help fill in any gaps in both test and coding coverage. At the end of the iteration, participate in the review to see what went well and what could be improved upon. Focus on one or two issues at a time. Celebrate successes large and small, and look for ways to resolve issues with testing for the next go around. When the product is ready for release, make sure to cover the bases regarding release, documentation, installers, upgrade scripts, and any other elements that will be part of the final release. Be sure to test database update scripts, data conversions, and other parts of the installation.


Part VI wraps it all up, and gives the factors that Crispin and Gregory feel are key to success with Agile practices. They emphasize that Agile testing is not separate from, but a core part of, the development process, and that the tasks and responsibilities of the Agile testier are integrated directly with the efforts of the development team as a whole. The goal of the tester in this new realm is to be a proponent for continuous improvement, to champion doing better each go around, to work to create a successful collaboration between the developers and the customers, and to always look at the big picture, which is to make sure that the best quality product is delivered to the customer and that the development effort improves with each test iteration.


There's so much to this book, and the space of this review can hardly do it justice, but Agile Testing does a good job explaining the differences in an Agile environment, and the way that a tester will interact with an Agile team. For testers who do not come from an Agile background (raises hand), there was much in this book that I found to be both helpful and encouraging. One of the biggest positives to this book is the personal experiences provided throughout from Lisa, Janet and other contributors; this adds a much needed perspective to the theoretical ideas being provided, and helps to give a better overall picture of exactly what I could do in similar situations (or not do in certain cases).

Bottom Line:

If you are new to the world of Agile, this will make for an excellent primer and blueprint for determining how to integrate yourself into an Agile organization. With the fact that I am just now getting my feet wet with an Agile project, it’s been very helpful in giving me ideas and methods to approach testing and how to make myself useful at all stages of the development iterations. While it’s too soon to tell if all of the suggestions will work for my specific environment, I’ve already been able to make some clear advances in my way of thinking about working on my latest project. I’ve also replaced quite a bit of apprehension with a sense of excitement and anticipation. I’m impressed by what I’ve read; now I’m looking forward to putting its lessons into practice.

Tweet Your Way to Better Test Understanding

This post was originally prompted by an off-hand comment made by Jonathan Bach on Twitter, where he said (I’m paraphrasing) “Twitter is like having a 24/7 Software Testing conference”. He’s right!


I use Twitter for one thing and one thing only and that is to learn about software testing. I have one account, and I have made sure that the people I “follow” are directly related to and focused on software testing or software development (or at least their specific profile is). Instead of trying to get a huge number of followers, I have focused on following those individuals who provide good information, timely updates and challenge the way I think about things.


Twitter is excellent for this type of knowledge exchange because of its specific design. The 140 characters limit means that anyone who wants to put up a comment has to do it in a tight and “to the point” fashion. Replies likewise have to be done the same way. Entire conversations and debates between contributors take place in this fashion, and the beautiful thing is that you can see what is being said from both sides if you follow both sides of the conversation. I’ve seen some terrific debates and even participated in a couple here and there. Many testers use twitter to announce blog updates, to re-tweet comments from others, or make recommendations for tools, books, seminars and meet-ups in various areas. Getting used to certain hash tags can help users find new insights (the daily testing tip, actually several of them each day, can be seen at #dttip).


Is this some kind of elaborate scheme to get more followers? Nope, though if you’d like to follow me on Twitter, you’re certainly welcome to. I just wanted to draw attention to the fact that, if you want quick, easy to read, and very focused testing ideas, Twitter’s a good place to find them :).

Permission to Suck

One of the situations that every tester will find themselves in, at one point in time or another, is where they will come face to face with their own incompetence. I don't say that to be a downer, but to let those who might get discouraged know that it's going to happen eventually. Each of us will face that moment in a different place and at a different time. It may be a situation that is of comical or even trivial import at the given time, and as such, may have limited impact. On the other hand, it could come at a time and at a place where career changing or even career threatening implications can take place.


I had this happen to me almost a decade ago. I found myself in a situation where I was very much in over my head, in a company and an area of industry that I had not prepared to be in. I owe a tremendous amount of gratitude to those who helped me and stuck by me at that time, but it became increasingly clear that what was desired by management was something I could not easily deliver. The net result was that I was ultimately encouraged to seek another area of employment.


I often think about that period of time, and I ask myself "what could I have done better, or at least done differently?" I came to the conclusion that, had I had a different mindset and a different attitude, I might have been able to salvage the situation, but ultimately my fear of looking incompetent caused me to keep my mouth shut, and keep my head down. My hope was that I would ultimately figure it out, and no one would have to be the wiser. Unfortunately, the gap was too great for that to happen on my own, and ultimately, my fear of being seen as incompetent became a reality. 

Today, I am much more vocal about my deficiencies (those who have read this blog for any period of time should know that well by now (LOL!)). Seriously, though, this is something that I have found to be very helpful and very liberating. As the title says, I've given myself permission to suck. Not forever, not indefinitely, but for the time being, on whatever particular area I may be having trouble with. It's not a crime to be deficient in a given area; it's not possible to know everything about everything. What is a crime (or at least should be) is not honestly and objectively deciding what to do about that deficiency. 


We have a limited number of hours in a day, and therefore we cannot pull off miracles overnight. I know well the search for "silver bullets"; that hope that I'll find the one article, the one tool, the one book that, after I get through that, then I'll have the magic that I need to do what I need to do. It's a quixotic quest, and one I would advise my fellow testers to not follow. There is no one magic formula for anything. The only "silver bullets" to be found are those that require a lot of work, a lot of repetition, and a lot of trial and error. What's even more frustrating is the fact that, early on in any of these attempts, we may find that we're just not particularly good at whatever it is we are doing at that moment. Fear sets in, and we decide that maybe it's better to just keep quiet and keep doing what we were doing before. This manner of thinking has been described by Seth Godin in his book Linchpin as "the Lizard Brain in control". The Lizard Brain doesn't want to be challenged under the best of circumstances, and it really doesn't want to be challenged when the results might not be satisfactory. The Lizard Brain hates sucking at something, and will give a person no end of intrusion to get them to abandon their endeavor and go back to what feels comfortable and safe (and when I say that, I mean what feels comfortable and safe for the Lizard Brain, not necessarily for the person). 


Getting out of this mode of thinking is difficult, but it's not impossible. First, it's important to know that whatever you attempt to do to fill a deficiency will, early on, yield mediocre results. Perhaps your efforts will even be bad results and a lot of dead ends and bad ideas. It's easy to give up at this point, or just not deal with it. This is the time when all good intentions go by the wayside unless the person takes control of the situation. The best way to do this is to give yourself permission to fail early and fail often. I remind myself of my first day snowboarding, when I was pummeling myself black and blue. It would have been easy to give up that first day if my goal was to escape ridicule or not be seen as incompetent (because, at that time, I was. I was *terrible* to the point of absurdity). Instead, I kept the goal in mind, that of riding down a hill without falling, with speed and dexterity, having the time of my life. By doing that, I shouted down the Lizard Brain and got on with it.


Second, it's important to develop a game plan to improve, and if it can be done with others who can cheer you on and encourage you, so much the better. Back to my snowboarding example, I let all of my friends know I started riding, and that I was terrible at it, but wanted to get better. Several friends made the pilgrimage up to the mountains with me to watch me get my bearings and lose my fears. Within five days, I was able to make a competent show of it on the hill. I wasn't winning any elegance awards, but I was riding most terrain with confidence and from there, developed an even greater desire to improve. As I improved, my friends offered other challenges, some of which were definitely humiliating at times when I didn't do so well. They knew I was trying though, and they encouraged me to give it another go. In testing, or any other pursuit, never underestimate the power of numbers to help you learn and grow.


Next, set realistic goals as to how you might progress and show the skill you are developing. After snowboarding for a few years, I had the opportunity to compete against riders that were my age in the United States of America Snowboard Association. Understand, I had no illusions that I was going to be an Olympic level racer or freestyle rider, but that wasn't the point. My goal was to keep improving my skills and to have a chance to test myself against others to see where I needed to keep working. Today in my testing world, I get involved in professional organizations that give me the chance to learn what others are doing, and to get involved and learn from them.


At each of these levels, realize that there will be moments (or longer periods) where you will come face to face with you mediocrity or, at times, complete incompetence. Breathe deep, square your shoulders, and realize that this is normal. Yes, your first efforts are going to probably be terrible. Yes, your first attempts will lead to many dead ends. Yes, you will be less effective at these times. Yes, you may get stares, chuckles, and, dare I say it, even a little derision as you gear up whatever you hope to learn to do. All of that is true, and at the end of the day, none of that matters. What matters is that we have identified a weak area or an area we want to learn about, and we have decided that the end goal justifies any amount of pain, frustration and embarrassment we may feel early in the process. Give yourself permission to suck! It's a temporary situation if you stick with it and work through it. It might be a permanent situation if you don't. Which option sounds better to you :)?

Wednesday Book Review: Great Feuds In Science

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.

After some heavy titles, I wanted to go for something a little more light hearted. In between Structure of Scientific Revolutions and The Day the Universe Changed, I found this little gem tucked between them. While the other two are heavy on history and on science,  Great Feuds In Science by Hal Hellman is heavier on the more petty human emotions that tend to get in between science and discovery. It reminds us that, while we like to think about science being an orderly march from point A to point B over time, history has shown us that the actual path is anything but straight or orderly; more times than not, people’s ego’s tend to be as much of a hindrance as a help when it comes to science developments.


This is a series of books; Great Feuds also has titles related to mathematics, medicine and technology. In this title, we see some of the great match-ups that shaped the scientific world; from Galileo vs. Pope Urban VIII on the center of the universe, to Wallis and Hobbes regarding squaring the circle and the development of higher mathematics. Newton and Leibniz take each other on regarding Physics and Calculus, while Voltaire and Needham debate and excoriate one another on the generations of life. Cope and Marsh duke it out in the wild west of Palaeontology, while Darwin’s defenders and detractors mix it up in the debate over Evolution vs. Creation. Lord Kelvin and his time’s Geologists & Biologists go toe to toe over the age of Earth. Wegener battles everyone to show his theory of Continental Drift, while Johanson and Leakey get into it regarding the history of human evolution and who came first and where. Finally, Freeman goes up against the ghost of Margaret Mead regarding nature/nurture in Anthropology.


What’s interesting about this book is to see just how often the conflicts and the testimonies of the time, in prose both revealing and biting, shows the temperaments of the figures and how they developed ideas, defended them, refuted others, and generally squabbled amongst themselves to help develop the scientific give and take that helped create many of the theories of their times. Some of the theories have given sway to others, and some of the debates are still with us here and now. In our sphere as testers, we often find that there are dissenting views, contrasting viewpoints, and dare I say it, a few larger than life personalities that frequently dominate the conversation at various times. We may feel as though we are an anomaly, that other disciplines don’t have these conflicts. What makes Great Feuds both entertaining and cathartic is the fact that, it shows that, in all scientific discipline, it has been ever thus. Knowledge rarely travels in a straight line with development naturally following on from earlier developments, but rather it takes side trips through people’s angst, prejudices, ego and attitudes, as well as the desire to be right.


Sometimes theories that are ridiculed and fought by the orthodox view of the time slowly gains momentum and takes over as the prevalent view, but it rarely happens without a lot of give and take, not to mention a fair amount of bluster and brow-beating. Hellman has given us a view into the world of the benighted greats of science, and peels back the genteel veneer to show that science is a living and breathing organism, one that has its awkward stages, mis-steps, and lurches forward rather than the stately and dignified progression that is portrayed in schools. For those who are fans of science, and enjoy the opportunities to see the way that science develops, warts and all, and want to have an enjoyable and somewhat quick read, Hellman’s Great Feuds in Science makes for great fun.

“The Laws of Jam” and the “Army of One”

I owe the term “Army of One” to Randy Rice, as he was the first to use it with me and share some of his challenges when he was in this situation (not sure where he got it, but since I first heard it from Randy, seems only fair I attribute it to him). Make no mistake about it, being an Army of One is fraught with challenges. Much of the time is spent making sure things get covered in a way that is satisfactory. I have no illusions of complete testing or total coverage. “Good enough” testing is an everyday reality and necessity to me. For those new to my blog, I refer to myself often as a "Lone Tester", but I've come to appreciate Randy's "Army of One" phrase a little more, since i think it conveys better the reality of being a one person test shop inside of a company.


However, just because that is my reality, does not mean that I have to like it or just deal with it. Make no mistake, I enjoy testing and I have given a substantial amount of my career to its practice. What I don’t like is what Randy also referred to as the “Law of Raspberry Jam”. This maxim is attributed to Jerry Weinberg, and it goes like this; “the wider you spread it, the thinner it gets”. In a testing organization try to cover too much and you get so thin as to be virtually ineffective. Doing this as an Army of One almost guarantees this will happen. However, there’s another law that Jerry points to that I have learned to take some comfort in and give me some different perspectives. Jerry calls this The Law of Strawberry Jam, and it goes like this; when you spread raspberry jam, it gets thinner and thinner with each stroke of the knife, but with strawberry jam, no matter how hard you try to spread it, some lumps remain. In other words, as long as it has lumps, it never spreads too thin.


This message gives me hope. I, as a tester, and more specifically, as an Army of One, have to make decisions about what I offer to the organization. With multiple projects, multiple products and multiple releases, all in need of my focus and energy, it’s easy to lose focus and become the Raspberry Jam, to try to cover all things and be everywhere at once. I’ve tried this, and the answer is the same each time. It’s not possible, and what I end up doing is a lot of stuff in a less than optimal manner, and quite often, nothing to an excellent level. If I automate, it’s whatever I can do quickly. If I do a feature test, it’s what I can accomplish in the period of time that I have. If  I accept those realities, I’m subscribing to the Law of Raspberry Jam. I do what I can.


Living the Law of Strawberry Jam is different. It accepts the fact that there will be lumps. It will not spread as far, it will not go thin. The chunks will be there, but they will have taste and some depth to them. As an Army of One tester, if I want to live this law, I have to demand that those lumps be allowed to develop. This means jettisoning the habits and practices that do not add value to the team, to document what needs to be documented with an eye towards effectiveness, not trying to satisfy vague platitudes or sloganeering. It means that some projects and stakeholders need to be told “no” for a time, so that later I can tell them “yes” when I am ready to give them my focused time and attention. As an Army of One, I can’t put everyone off and focus extensively on just one thing, but I can cycle that attention on a longer and more effective basis. It may require some time on my own to just disappear with a book, a laptop, or some index cards and just gather my thoughts together, and tell everyone else they just need to wait for this. If I do that enough, those lumps start to form, and they can become effective tools in my daily battle against bad software.


Does this kind of thing happen overnight? Of course not, especially when your team has grown used to you in a Raspberry Jam mode. Taking a stand and telling the team you cannot be all things to all people at all times is hard, but it hands down beats the alternative of trying to be and never being able to live up to such an expectation. Pick your battles, pick where you will let lumps develop, because at the end of the day, those are what will differentiate you. If you do not have a talent in a particular area, vow to develop it or commit to have no part in it, but make that stand. I’m fond of saying that I can have anything I want, but I cannot have everything I want. There’s just not enough time or life in me to do that, but I can pick anything I want and make a commitment to get better at it, if I’m willing to put in the time to make it happen. You know the phrase “ready, willing and able”? I’ll bet most of us have the biggest challenge with the middle one. We may be ready to do something great, and I believe everyone to a point is able to make great strides in just about any endeavor (though a person does need to know their limitations). It’s the willing part that takes the greatest amount of effort, willingness to woodshed on an area that’s an obvious weakness, willingness to go seek help from others, a willingness to challenge yours and others beliefs in a system that isn’t working the way it should, and ultimately, a willingness to say “no”. Not “no” forever, but “no” for now, so that we can develop something solid, something with true mass… something that cannot be spread too thin.


How about you? What areas can you make yourself more solid, and how can you stop being spread too thin? I’d love to hear your thoughts.

I Used To Be a Staffer…

…and a good old Staffer, too.
But now I’m finished staffing,
I don’t know what to do,
I’ve grown old and feeble,
and I can staff no more,
so I’m going to work my ticket if I can.

Those are some of the words of an old song that are sung at a special training course offered to Adult Scout leaders all over the world. This course is called Wood Badge, and represents a significant time commitment from those who participate and those who teach. Each participant in the course gets to go through for themselves one time (WE3-55-07, Buffalo Patrol for me :) ), work on the improvement items they have chosen for themselves, and when they do, they get their “Wood Badge” beads, which they can wear for the rest of their lives as long as they stay active in the Scouting movement.


Most participants are just that; they participate in the course, complete it, and then go on with their units and their lives. At times, the core group of people that work to put on the course ask recent participants if they would like to join Staff and become a “staffer”. For those that do, they then get to participate with the course development group, prepare presentations, and model the course so that the best experience can be had by those who participate.


I’ve now served as a staffer for one Wood Badge course, and am currently serving as a staffer for a second course to take place this fall. I’ll let you in a on a little secret… in addition to being a lot of fun, it’s also one of the best learning opportunities around. While you do indeed learn a lot the first time around, you learn even more when you are the one to teach others. In my testing life, I’m now just days away from starting my first stint as a “Staffer” for the Association for Software Testing’s “Black Box Software Testing: Foundations” course, and I anticipate a similar situation. While I believe the participants will learn a lot from this course, I have a feeling I may learn even more. Class officially starts Sunday. I’m excited to see where this journey leads.


Back To Gillwell, Happy Land
I’m going to work my ticket if I can.