Developing Book Review: Explore It!

Pragmatic Publishing has been getting a lot of my book dollars the past couple of years. There's a reason for this. They seem to be the ones best situated for my particular technology and challenges list at this point in time, plus I greatly appreciate their model of how they make books available. With many publishers, you need to be part of a secret club or know the author to get your hands on a developing book. Pragmatic Publishing has baked it into their writing model. Most of their books are made available as beta titles early on, and those who wish to get involved with the reading, implementing and reviewing of titles can do so. They realize that the books are half baked, sections are still to be written, aspects of layout and graphics are not completed, and grammar may still be a bit loose.

As I've said with other developing reviews, fair enough. Again, I will say "If we extract all of that, is there a value in getting this book now and being one of the people who will be willing to work with all of those for the time vagaries to get to what will ultimately be a good product?" That's what I hope this review will represent. Also, this review will be converted to a full review after the books ship. Oh and for those who want to say at this point "tl; dr", here's my answer.

YES!!!

Exploratory testing has been getting press lately. Deservedly so, I should say. Still, outside of blog posts and direct interaction with those who have represented the movement of exploratory testing, there isn't a good one stop for explaining what exploratory testing is in a meaningful way. Practitioners have to scratch around and try out a number of different sources and models and deal with a lot of "it depends". Getting all of the details in one place, and with a smooth narrative that can help make sense of the process is a good thing. Giving you ways to practice it and actually get some hands on understanding is even better. Hearing it in a voice and a narrative that flows smoothly, is not overly technical, and allows users to connect the dots effectively would also be a huge plus. Are we there yet? With the beta 1.0 release of "Explore It!" by Elisabeth Hendrickson, I'll dare say we are are a lot closer than we have been to date.

Software development is hard. It takes a certain amount of discipline, structured thinking and a variety of language skills to put a system together. What makes it even more challenging is that it's not like building a house on rock. It's not even like building a house on sand. It's really more like building a boat on an ocean. So much of software development requires the interaction of so many moving parts that, really, nothing is stable or static. Not really. It's in this world that we as testers are often asked to do our work. If we have illusions that everything is going to be neat and orderly and tidy, like a house built upon a stone foundation, we are liable to miss a great deal of what happens. This is where having an exploratory approach and mindset is critical. We understand that we need to explore, but how do we develop that mindset? It's with this aspect that much of the initial chapters are focused.

Part One deals with establishing and developing the exploratory foundations, so this is where exploration is explained and put into terms that a variety of people, not just testers, can understand. The key attributes of exploration (execution, learning and steering) are put forward, as well as disavowing the notion that testing is only a process of the test team (it's not, everyone tests, whether they are aware of the fact or not). Creating testing charters and understanding how to make them neither too specific nor too vague is important. There is also an emphasis on time boxing and Session Based Test Management, so as to help keep things in focus and make the exploration meaningful and on target. I like the approach Elisabeth uses in this early section to make a simple and easy top understand exploration template. Much the way that Agile development makes a story ("As a [stakeholder]., I want [functionality] So that I can [achieve result]"), consider exploration to be "Explore [target] with [resources] to discover [information]". That alone is a great takeaway from this section!

Observation is a big part of exploration, and Elisabeth puts a good emphasis on learning how to see what others don't. Inattentional blindness is addressed, and yes, we get a visit from "The Moonwalking Bear" (and if you have no idea what that is, follow the youtube link in the footnotes). The key point is that we need to make an effort to make the invisible more visible, and Elisabeth explains a number of techniques and methods to do exactly that.

Part Two digs deeper, and gives us the opportune ity to work variations and different approaches to our explorations. Elisabeth recommends that we take some time to recognize our habits and how those habits may be blocking our vision to see the unseen. From there, make a conscious effort to avoid doing things the way you normally do. Personas are introduced, and fleshed out considerably. For anyone who has heard this term, Elisabeth give this a good treatment, and also puts it into perspectives you may not have considered. States and transitions are an avenue for exploration that gets a good treatment here, and how to take advantage of them to vary your testing approach. Modeling the system and the way we interact with it are also covered. Look for places where transitions occur, and see if you can influence the way those transition occur.

Part Three puts the different approaches into unique contexts and shows that the skills are applicable in a broad range of circumstances. Exploration is often considered a front end approach, but it can be used in many places; unit tests, acceptance test driven development, behavior driven development, testing of API's, and anywhere that a user might interact with an application, even if the end user isn't actually a human. Also, while exploratory testing is encouraged for systems under development, it's just as powerful a tool for legacy and currently marketed applications, too. Elisabeth describes the value of doing reconnaissance on applications. Discover the applications capabilities and its limitations. From this, you can start asking interesting questions of the application, and discover areas where it should be doing something, or should not be doing something, and when to tell the difference.

Part of what makes this book fun, at least for me, is the fact that I have worked with Elisabeth in the past. I know her, I know her sense of humor, her manner of speaking, and the way that she gets points across. Thus, it's very easy to read this book in her voice. Even if you are not familiar with Elisabeth and how she talks and describes things, you will still be able to follow along with her as she makes the examples relevant, and sometimes amusingly so. While calculating to the air velocity of a swallow (European or African), the fact that she's willing to include those whimsical details makes it easy to get into the spirit of the book and go with the flow of the narative. For technical books, that's quite an achievement.

At the present time, the ToC lists 13 chapters, with three of them still to be written (Exploring Entities and their Relationships, Exploring Requirements, and Integrating Exploring Throughout). The appendix section includes a section on ways to interview for good exploratory testers and the now famous (for many) Test Heuristics Cheat Sheet. If you want to see progress on the book, you can certainly check the book Progress page to see if the area you are interested in is ready or well along in the process. If you want to wait for the whole book to be finished, that's understandable. If, however, you'd like to get in and try these techniques for yourself, and are willing to deal with some loose ends for a few months as they get developed, not to mention help Elisabeth deliver an even more solid book by offering suggestions in the book's Errata section, then why wait? Get the book, go forth and see what you will find. Even in it's Beta 1.0 state, my guess is, quite a bit.

TESTHEAD REDUX: Anyone Can Do It, Right?

The second post ever on this blog was my commenting on a commonly heard question, at least up to that point. I decided to revisit this one and see how I felt about this question, and what has changed in the ensuing 2 1/2 years to potentially change my opinion...

Then:

First and foremost, those of us participating agreed that Quality Assurance is not “easy” to do. More precisely, it’s not easy to do if it is to be done well and consistently.

Now:

It's taken me awhile, but I have almost completely purged my active vocabulary of the term "Quality Assurance". I don't believe such a thing exists, so in that sense, not only do I say that Quality Assurance is not "easy to do", I now generally say it is "Impossible to do", at least when we are talking about software, and when we are talking about software testing.

Then:

Do we get a bad rap in Q.A.? Why do so many look down their noses at “Testers” or "Quality Assurance Engineers” or "Test Analysts” or "[fill in the blank trendy job title]"? I don’t have all the answers to this, but I do have a few ideas. One of the biggest, I think, is the fact that our contribution can vary wildly depending on what it is that we actually do. In the software industry, developers get a lot of recognition for an obvious reason; they produce a shippable product that is tangible and people can use it and say “hey, this is great” or “wow, this isn’t good”. If you are someone who works with automation and creating test scripts, there is a little bit of this “shipping” phenomenon in that you have actual tangible items to point to (test scripts, test reports, etc.). For many of the things that testers do, there really isn’t a tangible product to point to and say “see, I made this”.

Now:

I used to believe this. I don't believe it now. We create all the time. We create a story. We provide vital information. We explore the unconsidered avenues, and we do so without a lot of the fanfare and positive press. I used the idea of being a beat reporter that I borrowed from Jon Bach. His example of getting the story and providing the story is what we do, but I didn't realize at the time that there is more to that process. It's intensely creative. It allows us the latitude to tell the story in a quick TMZ sensationalistic style, or we could go for a more New Yorker style approach, and anything in between. Much of this is going to depend on our intended audience, and sometimes we will have to do both.

Then:

When we say that “anyone can be a journalist” because anyone can write a few paragraphs, we tend to laugh, because we realize that to be a good journalist requires a lot more than just writing a few paragraphs. There has to be deep knowledge on the subject, or at least enough knowledge to know what to go after to expose a story. Journalists interview, they follow leads, they get both supporting and opposing viewpoints, and at the end of the day, they make a story that moves people to consider what they have discovered and add that to their world view.


Now:

Having written this blog for 2 1/2 years, I an even see how much more silly the statement "anyone can be a journalist" actually is. Almost 600 blog posts in, and I'm more critical of what I write than I ever was before, and nothing I write would stand up to solid journalism. One of the cute and amusing things about being a fresh blogger is the hubris that comes with it. We think that what we are describing is new and inventive, that we have something vital to say (and frankly, that's OK, I'll take earnest and eager but  overbearing over smug and jaded any day). With time comes experience, and with experience comes wisdom (often because we've done dumb stuff and watched it unfold in our blog pages or in our active testing). The past 2 1/2 years has taught me a lot, but most important, getting a compelling story is every bit as hard in testing as it is in journalism. The really good testers are a few and fabled lot not because they are naturally talented. They become part of the few and fabled because they are tenacious and keep at it. They don't accept their Status Quo efforts; they keep pushing to do great work.

Great work is hard. It's tiring, it's an energy suck of the highest order. It's also highly invigorating when, in those rare moments, you really do tell a compelling story, and it's recognized as such. That keeps me going. It keeps me going through periods of time where I'm less effective, where I'm distracted, where I'm wondering why I do what I do for a living.

Looking back, I can still say it's not easy, but my reasons for feeling that way are very different than what they were in March of 2010.

A Year After: Lessons Learned From a Bad Break

I used to enjoy looking forward to this day, as it's my brother's birthday. However, there's another anniversary now to... look forward to is not the right word, but remember and reflect certainly fits. Lat year on this day, as I was making my way home from work, as I was riding my skateboard on the streets of San Francisco, I hit something on the sidewalk that sent me flying. My landing was less than graceful, and the net result was that I broke my right leg. Specifically, I broke through my right tibia about two inches above my ankle, and I broke through my right fibula about two inches below my knee.

The break made necessary the installation of a metal plate along the tibia. The fibula they left to fend for itself (common practice, I've come to discover). I had to spend a month with my leg elevated over my heart 22 hours a day. the recovery since has been, well, interesting, to say the least.

At the year mark, what has changed in my life? The good news is that I can walk around much of the time and feel little discomfort. Yes, I said little, and I said much of the time. To this day, I still feel strange twinges of pain around my muscles. My right calf muscle still looks like something took a bite out of it; it still has not yet returned to full size. My lower leg along the scar (where the plate is) still doesn't have much in the way of feeling when I touch it. Most telling is if I have to run across the street to beat a yellow light or counting down crossing timer. At that point, it's a lot plainer to see. My ability to run has been greatly curtailed. Instead of running, I do a strange little limp hop that, to passers by, is a tell take sign that, while I may look fine on the outside, I did a number on myself that will have a long road to complete recovery, if complete recovery is even a possibility.

On the bright side, I'm doing better than a number of people thought I would do. The severity of the break had many concerned that my walking would be impacted, or that I would have a permanent limp. Some days, I do indeed have a more pronounced limp compared to other days, but most of the time, when I walk at a normal pace, few people can tel I was ever injured. Of course, my days of hiking mountains or doing long walks of an hour or more have been significantly curtailed, and I may never be able to do what I used to do, but I can still put on a pack and hike two or three miles without great difficulty. For a lot of the scouting events my troop does, that's within the parameters of what we do a lot of the time.

The scarier thought now is that, at the year point, i can now have the talk about seeing if the hardware can be removed. The orthopedic surgeon told me that, at some point, the plate could actually become the weakest link in my recovery, because the plate and the pins/screws are less flexible than the bone, and pressure on both could cause shearing or other issues. Removing the plate and pins could help the bone recover more and get close to its pre-brake status, or at least as close as possible. It's time to have that next conversation. The thought of going under again and getting cut again makes me nervous, but I'll be really happy to get the hardware out if it makes sense to do so, and hopefully continue my recovery.

Many who have been through serious injuries like this remind me that it can take years before a full recovery can occur, and yes, in some cases, we don't get the option of full recovery, but we do ultimately get better and adapt to what we can do. It's helped me become a little more patient and it's also helped me become a little more aware of other's challenges. In that way, I think there have been a number of positives. rather than lament what I can not do at this point in time, I am reminded that for many others, the obstacles are much greater, and that I can do a lot more than they can, and to be grateful for that fact.

Here's to future days, and an end to what has been both a short and a long year.

Live from San Francisco, It's SFRails Meetup!

One of the things that I like a lot about San Francisco is that you cannot swing an umbrella or a computer bag within three feet of you without hitting a Meet-Up, it seems. Due to other commitments, I've been away from the fun the past few months, but it feels good to be back out and seeing what's going on again. 

That, and Sidereel's hiring Rails developers, too :). So with cards and Sidereel branded bottle openers in hand, I've made my way over to The Climate Corporation, the group giving us their space to host tonight's meet up. What's really cool is that this meet up is just a short hop from where I work. One diagonal block! I can see my building from where I'm sitting.

7:00 Pizza/Beer/Networking

We're early into the program at the moment, hanging out, eating pizza, and talking shop. I'm having a good conversation with someone who is actually already talking with my company (or has been chatting with our hiring person). I also saw that a few other friends were expected to be here tonight a well. One of the great things about these events is that it doesn't matter if you have years, weeks or just days of experience, everyone here is really cool, very chill, and like talking about what they are up to and sharing their ideas, no matter how half baked or crazy.

Stay tuned as I update this space, and I'll be happy to share what I pick up this evening. For a really quick cheat sheet of what will be covered, see below (right now, this is just a repeat of the meetup blurb. I'll be updating with my take on these topics shortly):

7:45 First Talk

GemJars: Bringing Ruby Gems to Java with Andrew Kellor (ThoughtWorks)

The first talk out the gate is from Andrew Kellor, and he's here to talk about how to bring RubyGems into Java projects. While I don't particularly use JRuby for anything, I know there are people who do (HotSpot VM as an example). the ability to have native threads, and the ability to reach into Java libraries and the JVM. the opening question to the audience... who has worked in a polyglot code base? If you have, then you can understand the frustration with trying to get the left hand and the right hand to know what each other is doing. When dealing with multiple languages, you have tooling challenges, you have interoperability issues, plus compromises that have to be made to be effective in your production code. 

So what's a GemJar? It's what it sounds like. It's Ruby Gems inside of a Java jar file. this way, all of your dependencies are in one place, and you can call them if you need them. It helped in many ways, but it also had challenges (everything in the same place means that the possibility of conflict is high). gemJars.org is doing it differently. In their world view, only the gems appropriate or a particular area (say, RSpec) in included in the jar file. I have to admit, this is outside of my everyday work, but I can see the benefit for those who do find themselves working within Java and wanting to have some of the cool tools and ease of doing some things that Ruby allows. 

8:15 Second Talk

Maintainable CSS with Sass and Bourbon with Jonathan Mumm (TokBox)

This talk covered a number of tools and techniques so that the developer could make sure that they were doing as much as they could to keep CSS from becoming cluttered, repetitive and difficult to maintain. By demonstrating practices (good one in context ;) ) using SASS and a Ruby gem called Bourbon), the programmer can make sure that they are taking advantage of the options that both SASS and Bourbon provide so that code is uncluttered and not repetitive. 

Since I lost the network for a bit, i wasn't able to jot down these details, but there's some cool resources to get to know how to tweak these options, including the SASS Rails gem and the Bourbon Gem documentation options. The ultimate goal is to make it so that you can make your code clean, orthogonal, with minimal duplication (yes, I know that's part of what orthogonal means ;) ).

All in all, a pretty good night. A little bit of enterprise level stuff mixed in with some rudimentary details, so there was truly something for everyone. Also, the pizza was great and the company, as alwayys, was terrific. Thanks for a great night everyone. Til next time!

Synergy, Intensity and the Expectational Debt Snowball?

As many of you might have noticed, I've been actively and aggressively looking at ways to streamline both my life and my commitments. Much of them are self imposed, and many of them are, to put it plainly, of my own design. The problem is, when we make promises and pledges, we involve other people in our follies, and they often have to deal with the fact that, if we make or break a commitment, they are part of the equation as well. This is not necessarily a bad thing; by making commitments to others, we add a level of accountability to the things that we do, and how we do them.Very often, that action of including others holds us to making sure we do something.

This very process is where expectations come into play, and it's also the process in which "expectational debt" (service mark Merlin Mann) can become a reality. Much of the time, expectational debt becomes overwhelming for the same reason that financial debt or technical debt becomes overwhelming; we aren't really paying attention. One of the reasons I started doing my game of "The Hours" initially grew out of my desire to simply get a better handle on what I was actually doing with my time. In it, I discovered just how many expectations I had placed on myself, how many I had promised to others, and just how many I was either ignoring or kicking further down the road. As people, I think we often want to make promises, and we have grand ideas as to what we can accomplish and believe we can do. Unfortunately, there's only so much "life energy" and time to go around. We cannot be all things to all people at all times. Any time we commit to doing something, we likewise commit to not doing something else. It's that simple.

Early in the life of my blog, I mentioned that I'm a fan of Dave Ramsey and some of his ideas and philosophies that relate to financial debt. In short, I avoid financial debt like the plague, and hope to be able to continue to do so. Two of his ideas I like a great deal. The first is what he called getting "Gazelle Intense" on a goal. The idea is that a gazelle in the wild, if they are being chased by a cheetah, will put every ounce of energy they have into not getting caught and, subsequently, being eaten. When we get "Gazelle Intense", we do much the same thing. We focus our energies intensely on survival and getting that critical thing done, no matter what it takes.

The other idea that Dave is famous for is what he calls the "Debt Snowball", where you take all of your debts, smallest to largest, and you put the minimum payments towards all of the debts excepts for the smallest one, and you then take every resource you have at your disposal and you attack that smallest debt. Once that smallest debt is gone/discharged/completed, you move onto the next one and do the exact same thing. The idea is that, as each "debt" falls away, you take the money that you were using for that previous debt and keep piling it on to the maximum of your ability, applying it to the next in-order debt, and so on, and so on, until you have an ever larger pool of money going towards knocking out your debts.

Math aside (some people suggest paying down the higher interest items first regardless of the size), the idea is that, by starting with the smallest item and getting early wins and clearing the deck of commitments, you are able to use more of your resources to tackle the bigger financial hurdles. Ultimately, when you clear the deck completely, your income is now fully yours. As a by-product, you have also developed the muscles necessary to be more fiscally prudent and pragmatic (ideally). Your spending is no longer mindless; it's deliberate and focused, and hopefully driven by different habits because becoming debt free was intense and hard won.

This idea has been floating through my head the past few days... could the concept of a debt snowball also be applied to expectational debt? What if we were to, effectively, stop the promise wagon for awhile, line up our expectations from the smallest to the largest, and then plow all of our energies into completing those items that suck up our time or our energies? What could we accomplish? What would we be able to "ship" that we haven't been able to? How much of our time and attention could we divert from the niggling "oh, one of these days I'm going to do that" to "I'm nailing this one, getting it done, and moving on, and nothing is going to stand in my way!" I'm willing to bet that, if we could be more focused and aggressive and approach our time and attention the same way that we approach our financial debts, we could make huge inroads.

"The Hours" has helped me understand just how much time it takes to do certain things, and just how hard it is to properly estimate how long it will take to do certain things. It also has shown me that there are ways to get synergies in what we do. For me, that means doing all I can to find an immediately applicable and actionable aspect to what I am reading and working with. If I am reading about a  programming language or a technique with that language, it's tempting to play through all of the scenarios and methods described, do the examples, and practice with it, and then "oh yeah, let me see if I can use this in my work." The problem is, often by the time we get to the "use in my work", other issues have popped up and grabbed our attention. Thus, the better approach is to find what we are working on and make it applicable immediately. Yes, read through the examples, but instead of going through and repeating the examples and assignments by rote, make your work problem or challenge the first thing you focus on with that new knowledge. This way, instead of taking time to learn, and then practice, and then apply it to a problem later, you practice with the technique while you are looking to solve a particular problem. We already do this much of the time, this is just a more mindful way of doing it.

Will there be false starts? Sure, but again, the idea is that this is a way to start building muscles we either have neglected, or haven't really built. I remember my friend Jon, a musician in the same scene as me 25 years ago. we were talking about music theory once, and I kept saying "Yeah, I wish I had the time to learn theory". He said:

"I learned theory by writing a song every single day. Granted, some of those songs were horrible, but that was my goal; write a song, every single day. Each day, I focused on some new aspect, some new tip or technique, and sure, it took me a few years, but finally, I could write songs every day and have them be unique and different." 

The key thing Jon did was that he immediately applied what he learned. He didn't wait for mastery; he let the mastery come with doing what mattered to him. Sure, he could have mastered the theory part first by doing all the recommended exercises. Instead, he figured it would be time better spent applying everything he learned immediately, even if it meant going down a number of dead ends.

Regardless of the approach, the best way to avoid expectational debt entirely is to never make promises. Unlike financial debt, that's just not possible (or should I say, it's not possible if we want to live a fulfilling and involved life with others). Since it's not possible, and expectational debt is somewhat "unavoidable", it's then wise to find ways to minimize it where we can, and leverage the opportunities we do have to lessen its grip.

More from "The Hours"... What's My Role?

I'm now several weeks into "The Hours", and I've made a startling, but painfully obvious conclusion.

I'm drowning in expectational debt.

As I have started to piece together the true value of my time and attention, it's showing me just how long it takes to do certain things, and how grossly inadequate my estimations for how long it really takes to complete things really is. I don't say this to ask for any one's pity. I say this as yet another realization that I'm human, just like everyone else.

I sat down and I did a simple experiment, based on the time commitments of many of the things that I would like to accomplish, as well as the things that I need to accomplish. On one side, I put down the roles of all the things I need to do, should do, and want to do for my job and career and how long it takes to do them all using a standard eight hour day. If I spent a solid six hours each day doing those things, it would be a pretty solid representation (I say six hours because there's always meetings, email and other necessary distractions that keep us all from doing 100% all day every day).

I balanced that with all of the things that I do in my off hours, and it was a very interesting list:

- Husband and Father
- Church member
- Scoutmaster
- AST Treasurer
- ED-SIG Chair
- Podcast Producer
- BBST Instructor
- WTA Facilitator
- TESTHEAD blogger
- Conference Presenter
- SummerQAmp materials curator/developer
- Administrator for local music web site

Now, let's just imagine that I wanted to spend a simple amount of time on each of these endeavors... say my customary "hour per day". Add in a commute that is realistically door to door an hour long each way (2)

Plus a solid work day (8)

Plus putting in some time to work on all of these listed areas (12)

Oh, and let's say that we want to have a little time to shower, shave, brush teeth, get dressed, keep clothes clean and maybe do a little work around the yard to keep the house barely presentable... I've gone into negative hours, and I haven't even factored in sleep.

That's what we call rampant expectational debt. The really sad part, it pains me to want to cut from anything. Each and every one of things is fun, and interests me greatly. I don't do them because they are forced upon me, I do them because I'm genuinely interested and having fun. Still even having fun reaches a limiting point.

The danger with expectational debt is that we keep making promises, and we know that we really want to fulfill all of them. We have every intention of fulfilling them all, and if time would just cooperate with us, we would finish them all. That's the problem. Time doesn't stop. For anyone. It just keeps inexorably marching forward. At some point any of three things happens. In one scenario, we cross the finish line and get everything done, but hey, some of it is late, and we can live with that. In another scenario, we do our best to move everything forward, but much like the minimum payment on multiple credit cards, it moves us only fractionally forward, even though we have expended a monumental effort. In the final scenario, we get frustrated, declare expectational bankruptcy, and just throw our hands in the air and say "I quit!". Well, I'm struggling to be the first, frequently resemble the second, yet I refuse with every fiber in my being to be the third. The thought of me giving up and letting people down really kills me; I'd rather do anything than be considered a flake.

Still, when we rack up large amounts of expectational debt, we do no one any favors, least of all ourselves. I'm realizing that I have to re-negotiate a few things, and that that re-negotiation will mean that some things will be done in synergy with other things, some things will be scaled back, and some things will, at least for a time, need to be eliminated altogether. It's the nature of the beast, and in some ways, it's painful, because no one wants to let anyone down. Not really, anyway. The flip side to this is that, when we take on way more than we can feasibly do, we are already letting everyone else down. We are driven to distraction, and we find that, no matter how hard we try, we can't fill the gap. In this wise, it's better to take the medicine and upset the few rather than find ourselves in the situation where we are upsetting everyone.

As I've stated in the past, I blog about these things not because I'm some guru, but because I genuinely struggle with this stuff. I realize in some ways this post will rip the mask off of me, and expose me for the human being I sometimes wish i could pretend I am not. Still, it's through various techniques like "the Hours" that we finally discover who we truly are. Not who we claim to be, not who we desire to be, not who we deeply wish we'd be. Instead, we get to face ourselves, warts and all, and see what we really value and what we possibly don't as much. If we prioritize our lives, some things just have to give. For some, that's easy. For others, it's the hardest thing in the world to do. Take a wild guess which camp I'm part of?

Developing Book Review: Cucumber Recipes

For quite some time, I have been considering the best way to handle doing book reviews for beta titles. Two companies that have been pioneers in this process, Pragmatic Publishing and LeanPub, give readers the opportunity to purchase books at their first availability, and then they get the chance to offer feedback, grammar checks and other errata fixes. and watch the book grow as its content gets created and developed over a period of several months.


I've had the pleasure of watching books develop from their initial beta offering through publication many times through Pragmatic Publishing, including titles such as Build Awesome Command Line Applications in Ruby, Technical Blogging, The Cucumber Book, tmux: Productive Mouse-Free Development and Practical Vim (which is, actually, still in Beta).


Often, I will find the initial value compelling, and I will work through the titles and enjoy the experience of having them months earlier than anyone else. Sometimes, though, I feel that there is great information that people are missing out on because I'm waiting for the book to be finished, but think it's unfair to give a lukewarm review for a book that isn't even finished yet. So what to do?


In this case, I've decided to change my own policy and create a new kind of book review. This will be specifically for beta titles. The key point to any beta title is it is a work in progress. It is missing sections. It has spelling errors, it may have half thought through paragraphs, and the page flow may be less than stellar. It may be missing figures and graphics. Also, the examples may or may not work as they are presented. To which I say, fair enough. If we extract all of that, is there a value in getting this book now? Is there a value to being one of the people who will be willing to work with all of those former vagaries to get to what will ultimately be a good product? That's what I hope these review will represent. Also, these reviews will be converted to full reviews and updated after the Production release books ship.


The second title I will consider for this treatment (since "Cucumber and Cheese" was really the first book I reviewed this way) is "Cucumber Recipes" by Ian Dees, Matt Wynne and Aslak Hellesoy. Mat and Aslak may be familiar to some readers for creating The Cucumber Book. Ian may likewise be familiar for his book Scripted GUI Testing with Ruby. Those two titles are tutorial books, and are meant to work with programmers and testers unfamiliar or having a relatively low understanding of the technologies. Cucumber Recipes is not a tutorial book. It expects you to have some working knowledge of what statements are and how they work, what step definitions are, and how to create them, as well as some working knowledge of Ruby. The real value of Cucumber Recipes is in the variety of avenues that you can explore in just a few pages.


Unlike a tutorial book that requires the user to go from beginning to end, more or less, to understand the details of what is happening, Cucumber Recipes does not have that limitation. Each "recipe" is its own section and is a standalone article. The subtitle of the book is "Automate Anything with BDD Tools and Techniques" and that is the key feature of each of these recipes. They are not just being offered as "here's how to use Cucumber to test something on iOS". Instead, it's "here's how to use BDD principles in this particular instance, and here's how you can carry those BDD techniques to it, and use them in other ways". A comment that Seth Godin made in "Linchpin" is that there are millions of "cook books" in just about any profession, but there are few, if any "chef's books". Cucumber Recipes, through its structure and approach, strives to be a chef's book.


Cucumber Recipes also looks to cast a wide net, and give the readers a broad set of possibilities. Not everything will be applicable to every reader, and it's possible whole chapters will be of little interest to some. Having said that, even with the material available at B1.0 (first beta release), I was able to find several examples related to such diverse topics as fixing Windows quirks, better reporting, data comparisons and transformations, and techniques for testing on iOS.


Each Recipe starts with a Problem statement (the issue that needs to be tackled). Then each recipe contains an Ingredients section. This contains any elements you need to be aware of, whether that be a particular class, gem, or external tool to use to make the solution work, and then a Walkthrough into the proposed solution. Again, the solutions require that you already know a bit about the given area, but the solution is walked through so that you can go from start to finish and see it in action. Each recipe runs from 4 to 10 pages on averages (some of the to-be-added ones may run longer, but I can't speak to that yet). Each recipe ends with a Further Exploration section, which may point to another Recipe, an external site or Ruby Gem (or library, jar or archive if you are using other languages like Java,.NET, Erlang, etc.), or some other noteworthy item (lots of footnotes and references here).


At the present time, the ToC has listed 42 recipes, of which many are still to be included, as well as a pending RSpec tutorial, and pending topics include testing on Arduino, Android, Linux, JavaScript, Java, .NET and Windows. There's something for just about everyone, provided the everyone in question is looking to use Cucumber somewhere in their mix.


As I said previously, not everything is going to be relevant to everyone, so check the book's Progress page to see if the areas you are interested in are ready or how far along in the process they are. Also, if you find issues, consider commenting in their Forum or Errata sections. If you want to wait for the whole book to be finished, that's cool, but if you have an itch to get to the party early, Cucumber Recipes is proving to be a worthwhile title to do exactly that.

TESTHEAD REDUX: My "Software Testing" Toolkit

One of the things that I have tried to do over the past two and a half years is look at what I have learned and determine, ultimately, what is worth my time and attention. It should be no surprise that there are things that I would learn, or start doing, that would eclipse older habits or activities.

In this vein,  I decided to go back and review old posts. Could I update them? Did I still agree with them? Have I totally abandoned some of the things that I used to do? One of my first entries (more specifically, my third), was called "My Quality Assurance Toolkit", and was an honest attempt to explain the tools and the things that I considered important to my work at the time.


What has changed since then?

The first and most noticeable change is that I no longer carry a "Quality Assurance" toolkit. The past two and a half years have shown me enough times that there is no such thing as "Quality Assurance", at least not in or around my sphere of influence. Instead, today I carry a "Software Testing" toolkit.

Then: Test Plan Templates
Rationale: having a few ready-made templates to use for certain circumstances can cut down on the time needed to write a first pass test plan.

Now: HTSM Mindmap (and XMind), Test Heuristics Cheat Sheet (Mug), Rapid Reporter
Rationale: Seriously, I have not written a traditional test plan in over a year. The reason? I work in an Agile shop now and, at least in this current environment, I don't need to. Now, before anyone stops to think that I don't use guides to my testing, I do. I use different guides now, more based on exploration and less based on scripted test cases. I actually use three tools for this. The first one is a mind map that I made from James Bach's Heuristic Test Strategy Model. I use this whenever I want to go through and examine a new piece of functionality or get to know a system that I'm unfamiliar with. In addition to just traversing the map, I also write down observations in the map for future reference. The second one is a coffee mug that sits on my desk. It's my Test Heuristics Cheat Mug, given to me by Elisabeth Hendrickson, and encapsulates all of her Test Heuristics Cheat Sheet (actually, it's never had any beverage in it... it holds pens, and sits just beneath my monitor screen so I can spin it around and get fresh ideas any time of the day). Additionally, I also use Shmuel Gershon's "Rapid Reporter" tool for recording observations during test exploration. Alas, it's only available for PC at the moment, but when I test on my PCs, it's a beautiful thing to use to record and capture my test ideas and meanderings.

Then: A Test Dashboard
Rationale: A simple dashboard will give you a heads up in how to communicate what you are doing to others in your organization. What matters is that you are communicating the relevant information in them and that your data tells a story about what you are seeing.

Now: Cucumber
Rationale: A test dashboard makes a lot of sense if you are in an environment that counts test cases and cares a lot about pass/fail rates. Now, I look at stories and their acceptance criteria, and I write test cases in Cucumber that examine that acceptance criteria, and show the pass/fail rates that way. More to the point, I tell the story in a different way now. Instead of giving values such as "well, I ran 700 tests, and of those 700 tests, 690 passed and 10 failed", I now focus on explaining what I have learned from observing these test runs. Qualitatively. Sadly, dashboards are not really good at telling a qualitative story.

Then: Cygwin
Rationale: There's something to be said about the quick and direct elegance that UNIX pipelining of utilities provides, so cygwin is my simple compromise.

Now: OSX, Ubuntu, and Cygwin
Rationale: I currently work in a web services world, one that is built on Rails. The development machines are Macs running OSX. Our users could be running anything. Thus, it's important to be able to spin up any environment to test with. Right now, that means VirtualBox on a Mac, as well as a couple of standalone PC laptops, but the need to have Cygwin as a necessity on a PC is lessened. It's still a great set of tools, but if you have access to a dedicated UNIX platform as your primary machine (as well as Dropbox for storing results files), it's no longer such a necessity.

Then: A Scripting and a Development Language (C#, C# Script, Perl)
Rationale: At the time, C# and C# Script were the languages I was trying to learn to work with better, with Perl as my back-up scripting language (mostly from having done CGI for web servers years earlier).

Now: A Scripting and a Development Language (Ruby, JavaScript)
Rationale: As I have had the advantage of working in a shop where my tools are the developer's tools, I have taken on the challenge of trying to learn as much of their programming methodology as possible. Many tools are used in our environment, but Ruby and JavaScript are far and away the most used.

Just like before, getting up and running with scripting isn't hard, but getting proficient with any language (programming or scripting) takes considerable time and effort. I'm still working on the proficient part.

Then: An Active Library Card
Rationale: The ability to get access to books on just about any discipline fairly quickly is very valuable. However, the true gem in my library card is the subscription that it provides to Safari Books Online.

Now: Blogs, GitHub, and an Active Library Card
Rationale: Though having a library card and access to lots of books through the library system, I have found that, at this point, most of the books I have not yet read are considerably out of date, at least the print versions. The Safari Books Online listing is good, but it's limited to the last two years, and thus has a limited listing of titles. For established topics, this is fine, but for emerging or developing topics, blogs are much more helpful, as are going directly to the GitHub repositories for open source tools that are currently available and reading what has been written for and about them.  For a good start on the blog front, looks at my blog roll; there are several dozen more where those came from. Check out Testing References for a more comprehensive list.

Then: Some Open Source Test Tools
Rationale: Developing some familiarity with an open source tool or a number of open source tools will give you an edge and provide you the ability to test things "right now". These tools can range anywhere from basic macro recording tools for applications to sophisticated web based capture/playback tools rivaling features offered by the professional offerings.

Now: Lots More Open Source Test Tools
Rationale: If nothing else, this is the one area where little has changed except me doing a lot more of it. Selenium/WebDriver, Watir/WebDriver, RSpec, capybara, Cucumber, and a host of other supporting tools have all made their way into my workaday world, and I find them very helpful. I see my involvement with these tools progressively increasing over time.

Then: Some Basic Reference Books
Rationale: "Testing Computer Software", written by Cem Kaner, Jack Falk and Hung Quoc Nguyen. "Effective Methods of Software Testing" by William Perry. These have been my go to books for years. Additionally, I felt it valuable to have books that were helpful with developing Domain Knowledge for the area I was testing.

Now: Blogs, Twitter, BBST and Some Basic Reference Books
Rationale: Today, my book choices have changed a bit. The testing book that I consult most frequently now is "Lessons Learned in Software Testing", written by Cem Kaner, James Bach and Bret Pettichord. I also like "Everyday Scripting with Ruby" by Brian Marick and "Perfect Software: and Other Illusions About Testing" by Jerry Weinberg. There's also "How to Reduce the Cost of Software Testing", but that's me being a bit gratuitous, since I helped write and edit it :). The real big change is where I'm now finding my testing inspiration, and it's coming less from dedicated testing books and more from books about history, philosophy and general sciences. One of my go to books now is "The Day the Universe Changed" by James Burke. I've also enjoyed titles such as "The Structure of Scientific Revolutions", "Philosophy Before Socrates", "Who Killed Homer?", and "The Social Life of Information", among many others. The point? These are not "testing books" per se; they are thinking books meant to challenge the way that we view the world we live in, and how we interact with it. Again, much like the variety of books, I've found that dozens of blogs and a Twitter stream tightly focused on software development and software testing make for more of my current reading as compared to the older reference books. I'd also be remiss to not mention the huge library of resources that is included and referenced in the BBST series of courses. Two and a half years ago, I didn't even know they existed. Now, I help teach them... that's a change for the better (and extra points if anyone remembers the commercial from the 70's that that comes from :) ).


Then: A Virtualization Library
Rationale: Having the ability to build and update environments on the fly can be a huge benefit.

Now: A Virtualization Library
Rationale: The exact same. Having the ability to play "what if" and not worrying about destroying my application, machine or network is hugely valuable to me. The fact that I can actually carry these environments with me now on a thumb drive is even more mind blowing and cool!


In addition to this, tools like Skype, Typewith.me, and CorkBoard.me deserve special mention. Perhaps the most import part of my Software Testing Toolkit, though, is the one that's the most encompassing, and by the power of the Internet, available anywhere... this blog. It acts as the repository of my hopes, dreams, frustrations and triumphs. What's more, it's an encapsulation of my ideas and efforts, both good and bad, and shows, I believe, the body of knowledge that I possess and practice, hopefully with considerably more emphasis on the latter.


How about you? How has your toolkit changed over the past few years?

Photo: http://www.fine-tools.com/G309550a.htm

Examining "The Hours"

For the past few weeks, I have been using something to help me get a handle on and find some sanity in the myriad of activities I participate in. For those who are long time readers of my blog, you will know that, while my primary focus is on software testing and learning about software testing, there is a strong undercurrent in my posts that covers topics like motivation, the use of time and "expectational and emotional debt". If that sounds weird and squishy, it's because it is! 

When I refer to time, I don't mean the passing of it. Time is constant and something I have little control over. I don't have the ability to bank time, I can't stretch it, I can't compress it, and make no mistake, there is no way to manage time, either (more on that in a bit). There is only one thing we can do with time, and that is USE IT.

To this end, I do a bunch of things that have me track time, measure time, make quantitative judgements on the time that I use, and how valuable it is (and valuable is, of course changeable with context). What I realized from all of this measuring, though, was that I was getting a list of all the things I was doing, down to the second in some cases, but very little understanding of why I was doing them or what I was actually accomplishing. Take for example Twitter. Depending on what I should be doing at any given moment, Twitter could be the biggest waste of my time imaginable (if I were to be doing a very specific and time bound testing requirement, what am I doing on Twitter?!) or it could be some of the most valuable uses of time during my day. Most of the testing articles, discussions and debates that help lead me to new discoveries and better testing are found on Twitter. This is because 99% of the people I follow on Twitter are software developers and testers. Quantitative tools don't tell you that. Qualitative tools need to do that. But really, there's only one qualitative tool that's going to be effective, and that's my own brain.

To this end, I decided to put something into practice a few weeks ago called "The Hours". I wrote a bit about this last week, but I want to go a little more in depth on it today, since it may be something other people might find interesting or useful. First, "The Hours" exists nowhere digitally. It resides in a single leather bound journal book, the nicest one I own. I dedicated a brand new book to this very purpose. From there, every page looks remarkably similar. It's a listing of hours, starting from 4:00 a.m. and running up until 10:00 p.m. The 18 hours are repeated each day, an I write in each hour what I actually did. Not what I wanted to do, or what I planned to do, but what I really did. Next to each hour, I use three symbols (for now). The first is an asterisk (*). this means I met the objectives I needed to. Nothing special, just that I completed what I aimed for. Other times, I use a frowning face ( :( ). that's to show that I was distracted, or I didn't set out to do what I intended to do. I also use a star for hours where I did more than I intended to do, or accomplished something that was important enough to call out attention to it.

After looking at this, some things are starting to jump out at me. Here's a few takeaways from playing "The Hours" these past few weeks:

1. An hour is a very small block of time. The fact is, it can go by very fast, and unless you make a commitment to be very focused on one task, you can lost the plot and drift very easily. However, it's a very useful yardstick for making progress on goals that require maximum focus. If you can define what you want to do, define what you are willing to give up for that hour to do it, and then make sure the distractions are kept at bay, then you can make real progress on a goal.

2. It's amazing how many distractions we can find. I had intended to work on a coding related issue in a given hour, and while I was doing it, I ended up fiddling with my keyboard layout, checking my settings,  changing my .vimrc file, playing with the settings in tmux to be more effective, looking up the best way to find out how to search for patterns in files in multiple nested directories... and before I knew it, my hour was up.  All of the things I did were wins for productivity and I learned a lot... but I didn't accomplish my actual goal for the hour. In fact, out of the hour, I ended up spending 10 minutes doing actual coding!

3. Scheduling is less effective that I thought it would be. I thought that, if I carved out blocks of time for specific tasks, that I would be more likely to do them and be effective. In truth, the opposite was the case. It seemed that something would either contradict or conflict with the time I decided to do something. The more onerous the task, the less likely the scheduled block would take place. Instead, I found that snap decisions and carving out time right then and there was the most effective. Instead of waiting until 4:00 p.m. to write a report or work on a presentation, I would say "it's 10:00 a.m., and I have some breathing room. Let's hit that presentation... NOW!" and then jump into it. If I did that, I was much more likely to make real progress. Which leads to...

4. Begin with the end in mind. Sometimes there are things that just need to be done, and we need to make the commitment to decide what that thing will be, what we will not do to make sure it happens, and then dive in to do something about it. Even then, we may find that our brain wants to wander. We struggle with the time we have set, and we find that we just can't hold on, no matter how hard we try. Give yourself permission to drift. Just a little bit, but yes, allow some randomness during that hour. Here is where a Merlin Mann style "Procrastination Dash" approach works wonders. In this case, set a timer for 10 minutes, and every ten minutes, allow your brain to drift for two minutes, and then get back to the focus for ten more minutes. Do this five times. Let your brain explore during those two minutes, but remember what your main goal is, and get back to it.

5. Splitting up tasks is much more effective compared to plowing through. Sometimes, this is not practical. If you are replacing boards on your deck or painting those replaced boards, you have to finish what you start, "The Hours" be damned. For many things, though, splitting up the task and working on something else allows the brain to rest, process, and organize what it needs to do. I often find that splitting up a heavy mental task with doing something physical (writing a paper for one hour, then organizing the garage for another hour, and then getting back to the paper) I get more done in both areas by splitting up the tasks. I think, again, it's allowing the brain some time to process what it was doing that makes this approach effective. It also makes the progress that much more tolerable (and therefore faster) for both jobs.

6. Slice your objectives as thin as possible. I'm stealing this from agile software development methodology, but I've found it works pretty well. If a task can't fit into an hour, chances are you've got too fuzzy of an understanding of what you need to do.  Get more specific. Put more of a focus on the particular tasks that need to be done. Instead of saying "write a paper about x", set that hour for "review articles or blog posts that would be reference material for x" or "write the first draft of my introduction for x", something that, again would effectively sit within an hour and be accomplished in that time. Like stories in agile development, many small stories make a release, and many releases make an epic. Don't try to accomplish the entire release at one sitting. Make a pace that is reasonable and obtainable, and for me, one of the best ways to do that is to get specific.

7. Honor thy energy and be deliberate with your choices. While I have entries for 4:00 am, I don't use them every day. There are times where the most important use of my time is to say "sleep", and mean it. Another important use of my time is to say "visit with friends" or "read from a magazine purely for pleasure" or "watch Anime with my kids"... and be totally OK with that. I have several entries that say exactly those things, and there's a smiley face next to them. The reason is because they were deliberate choices, made at that moment, an I wrote down the intention and honored it. While it's entirely possible to get into gratuitous and totally selfish uses of time this way, I've discovered it doesn't happen very often.

It's been an interesting experiment, and one that I have every intention to keep doing. As I go through the process, I may come across additional insights and interesting things I discover. Make no mistake, if I find something interesting, I will share it here.

What Lies Beneath: A Cautionary Tale

For the past 13 years, I've been living in the house my family has called home here in San Bruno. It's a fairly standard house for the neighborhood, on a regular sized lot. One of the things that interested me was the fact that we have a very long deck in the back yard. The deck starts off the kitchen side door and runs to the fence, and then runs all the way to some terraced planter boxes against the back fence. By comparison, 50% of our usable back yard is wooden deck.

Over the years, I have wondered why this is, and I have also considered at various times the thought of removing sections of the deck to re-purpose it. How fun would it be to have a fire pit in the back yard… oh wait, not possible with a redwood deck. Well, one of these days, I'll look at taking out a section and just using the concrete underneath it. I mean, how bad can it be?

Last week, I discovered how bad. As I was walking on the deck, a small section gave way under my weight. As I inspected the boards around the area that gave in, the weather, moisture and movement around the boards made it clear that there was a big section that needed to be replaced, six 2 x 6 x 12 planks worth, as well as three other boards that were one offs in other places. OK, let's get them out of there. Hey, here's my chance! I can actually check out what it would be like to have a section without the deck!

It took me about an hour to get the boards out (the weathering had also done a number on the screws used to secure the boards; I couldn't unscrew them, I had to actually use a hatchet and split the boards to get them out). Once I did, I fully understood what there was a 70 foot long deck covering half of my back yard. The concrete was split up, uneven, sections without concrete and just dirt, etc. Note, I've lived here for 13 years, and this has been my first chance to see this. The deck itself has probably been here since the late 70s, so it's doubtful the previous owners knew what was under here either. I did a quick calculus of the area, and came to a conclusion. I'd need a jackhammer and a backhoe, plus a lot of work and money, to get that section to be flat ground again and able to set up an outdoor fire pit, or anything else for that matter. With that, I sighed, bought several redwood planks, and repaired the section. The continuous deck will be there for awhile more, it seems.

In many of the applications we test, we can see lots of pretty eye candy and a surface that looks really attractive. Often, we focus on just the superficial issues that we come across. If we are lucky, we may find a hairy issue in the line of sight of an important feature, but oh, if we could just thrust our pick axe a little further from where we're being asked/told to work, we could find something genuinely glorious (as in gloriously bad). However, if we do, what are we prepared to do? As was painfully brought home to me this weekend, sometimes there are areas that are devastatingly bad, but they would be so monumental to go in and fix that it just isn't worth it to even try. I told my wife and let her see just how ugly the pit under our deck was, and we both made the decision to cover it right back up again. We know we will need to deal with it at some point, but today is not that day. Likewise, even at work when I find something devastating, not having it worked on isn't an ignoring, it's a realization that, sometimes, it's better to just re-fortify the covering than it is to deal with the crags underneath. 

Constraints and "The Hours": Using Both To Your Advantage

One of the things that has been a recurring theme in my world is what I call an ebb and flow of natural distractions. Often I don't intend to do this, but what happens is I get so many balls up in the air and I try to juggle so many things at the same time, that I end up driving myself to literal distraction. Sometimes, it's fun, but other times it can have adverse effects on both my family life and my professional life if I'm not careful or if I'm complacent.

There's also a flip side to this, too, in that I sometimes bury myself in so many good "to do" items that I hide from myself (for a time at least) that I am procrastinating on a huge project or commitment, and I am fighting to try to find time to make it happen. The difference is that, often, I am finding the excuse to use the other important things I want to do manifesting as a distraction and a procrastination effect on the things that I really need to do.

I've written in the past about the fact that I often procrastinated because I was bored. I can truly say that's not the case this time around. I'm genuinely enjoying all of the testing advocacy that I'm involved in. It feels like I'm fighting a good fight, and I love that aspect. Sometimes, though, I feel like I'm being faced with something that my pride won't let me put down. Right now, that's automated testing. I admit it, I'm not great shakes when it comes to programming. I will likely never get hired to be a software developer because it's just not something I like doing enough to commit to being excellent at it. I do, however, like to solve problems, and I feel elated when I can solve them, and frustrated when I can't. Thus, I find myself in the situation of having to learn so much, feeling like it's hopeless and never ending, and thus, not meant to happen. This situation keeps repeating itself until I find I'm spending an inordinate amount of time trying to do something, being ineffective in the process, and dropping the ball on other things that are just as important, but not getting the attention they deserve.

Does this sound familiar to anyone? I know I can't be the only one that deals with stuff like this, but yet I feel like it comes up regularly enough that I need to try to approach is somewhat differently. It's through this that I'm trying an idea called "Constraints and 'The Hours'". During certain hours of the day, I put certain efforts into different piles. Active exploratory testing I consider hugely productive time. Reading blogs to get testing ideas and insights, I consider productive, but not as productive as actively testing. Dealing with email from my work account I consider neutral time. It's neither productive or distracting. Email from my personal accounts I consider very distracting during this time. Social network like Twitter and Facebook I consider to be very distracting during this time as well. The truth is, they may be either distracting or productive, depending on what is going on. For the most part, though, I try to maintain as well as possible the idea that anything that is not work related during work hours is to be treated as a mega-distraction.

By doing this, I give myself constraints, and then it becomes almost like a game. How long can I keep true to the constraints I have set? How long can I keep the chain going? Still, even with this mental play, I have deliverables and things I need to do from many different quarters. How can I make sure to give them all time? This is where my game I call "The Hours" comes in. The goal of "The Hours" is exactly as it sounds. Make up a list of things I want to or need to focus on in a given day, week, month, etc. Once I have the list, then it's time to prioritize the list and decide when in the day I want to do the various things. The constraint this time? I have exactly one hour to do it. It doesn't matter if it's something I really enjoy doing, or it's something I am struggling with. I get ONE HOUR to focus on the thing at that particular time, and then I have to set it down. Do I want to learn more about RSpec? Cool, then set an hour for it at 6:00 PM to focus on just doing that, and stop at 7:00 PM. If it's something I enjoy doing, that forced stop means I do so wistfully. If it's something I'm dreading, well, at least I only have to put up with it for an hour.

What I've found interesting about this approach is that I find myself willing to do things that otherwise I would find arduous or taxing with a greater sense of desire and interest. It also allows me to not get burnt out on things I'm actively enjoying, too. Of course, sometimes you just need more than an hour. What to do then? Ideally, I stagger activities. If I have to do something I know is going to take me several hours in a given day to accomplish, I schedule hour long breaks to do other things, with the idea that, as soon as that hour is over, I can get back to what I was doing before. For technological things (writing, coding, testing, etc.) this actually works pretty well; it's like applying Session Based Test Management to multiple endeavors. There are, of course, some things you just can't break from. If I'm setting concrete or digging up something in the yard, I can't just say "Oh look, my hour is up, I have to go do something else now. No, in that circumstance, you just have to dig in and do what is necessary. Most of the time, though, especially with computer related activities, that level of focused time is not required, so playing "The Hours" makes sense and works pretty well.

Sometimes it is helpful to put constraints on the things that you do, as well as to limit your immediate exposure to them. By doing so, you open up the prospect of making time for things that have been languishing, and you also open up the possibility of making and committing more time to activities that are just a lot less fun than others, at least at first. Once we make the commitment to focus those hours individually and routinely, we may find that "The Hours" dealing with something challenging and irksome, may over time become some of the best hours of any given day.

TESTHEAD Talks: CAST 2011 and 2012

With much thanks to Ben Yaroch and TheASTVideos channel on YouTube, you can now hear some of my talks that were given at CAST 2011 and a presentation on CAST LIVE for 2012.

In 2011, I wa the lead off presenter for the first Emerging Topics track, and I did a talk called "Beyond Being Prepared: What Can The Boy Scouts Teach Testers?" In it, i discusssed some fators that relate to the stages of team development, and how both our leadership style and interaction style can have an effect on those stages. If you were on the Live stream in 2011, you had a chance to hear this. If not, I'd like to help remedy that right now :).

Also, I had the opportunity to present some of what the EdSIG is up to, as well as AST's involvement in SummerQAmp on CAST LIVE 2012. If you are interested in hearing my take on that, then this is for you as well.

Again, my thanks to Ben Yaroch for posting these and giving me a chance to share them with more people. It's is greatly appreciated.