Book Review: Technical Blogging

I figured, what better way to celebrate my 500th TESTHEAD post than with a book review about a book dedicated to blogging!

Blogs exist for just about every conceivable nice you can think of. For that matter, blogs have exploded in so many different directions, it's hard to even pin-point what counts as a blog any longer. WordPress, a blog platform, Blogger, a blogging service. Many roll their own with Jeckyll templates and other open source tools.

There's also those of us who roll with a special niche style of blog, and that's the "technical blog". These can range from programming, web design and robotics to agile practices, clean room manufacturing and, yes, even software testing. For those of us who spend a lot of time writing "somewhat technical content" for our blogs, we don't really have a lot in the way of "expert advice" on what to do or how to set up or even how to present a technical blog. Today, Pragmatic Publishing's "Technical Blogging", written by Antonio Cangiano and edited by Michael Swaine, received the P1.0 designation, and thus, a book that I've been reading since its initial beta is now out in the wild and I can talk about it :).


Technical Blogging is a primer and a how to guide for anyone who wants to take a mostly technical message and make an online presence around it. The book is organized around five sections. Each talks thoroughly about the variety of options that are open to content developers who want to make a name, develop a presence and announce and advertise a market expertise. As an added bonus, there are tips for those who would possibly like to make some money from their blogging endeavors.

This book hits a special spot for me, in that it comes at a time when I am at a crossroads as to what I hope to have my own blog represent. What started as a simple way to take notes and try to write down my own ideas about software testing has itself grown to an appreciable niche readership that, while not earth shattering in numbers, ranks very respectably with other software testers. Naturally, I've been thinking about how and what to do with the "next phase" of my blog, so this title has come out at a very opportune time for me.


Part 1 focuses on Planning. This is where you ask yourself what I want my blog to actually be. Should it be a general blog, should it be a specific niche blog, should it be a solo project or a group collective? From there, plan out what you want to have your blog cover as its primary topic and get ideas for your first dozen posts. If that process was easy, then you may have a topic with the ability to continue writing about. If it was difficult, you may need to change your focus or broaden your niche. Tools that can help the blogger determine the potential market for their niche are also discussed. Targets for readership and registering a memorable domain name are also covered.

Part 2 is all about building your blog. WordPress and Blogger get the most coverage here, with the lions share going to WordPress, but any blog platform user would do well to read about the nuts and bolts about what makes for a good and usable blog layout. Some of the changes my blog has undergone in the past few months have been directly from recommendations in this section. Layouts and themes and widgets are covered (again, much from a WordPress perspective, but still relevant to other platforms). Sidebar layouts (and why) are covered, as well as feed readers, newsletters, and tips on creating solid content for your readers. There is also a very helpful section that talks about writers block and ways to overcome it.


Part 3 is all about Promotion. Let's face it, we wrote it, we want to have people read it. How do we best do that? Marketing is important, and yes, the magical and often maligned Search Engine Optimization (SEO) techniques are important to consider. Outside of direct marketing, more traffic will come to your site through search engine queries than any other. Linking, getting others to link to you, page ranking, etc. are all covered here (and a few ways I had never heard of before). I absolutely use the tools to promote on Facebook, Twitter, and Google+, but there are several others I haven't yet focused on (and may well try). The big takeaway is that, if you have a technical blog, your best promotional tool is to participate in your community, not just post "hey, look at my blog!" links.


Part 4 covers the fringe benefits of having a technical blog, which includes, but is not limited to, making money off of it. Ads through Google AdSense and other alternatives are discussed, as well as how to diversify that income and make sure the ads don't overpower the content. Getting sponsorships and working with affiliates is also discussed. Amazon affiliates is also mentioned, though it's currently in dispute for some states (that's the only "revenue enhancement" I've used on my site to date). Though it's not a "revenue" per se, it's definitely something I do on my blog; I actively review technical and business books (hint, just like this one :) ). Other avenues such as donations and merchandise are also considered. It should also be noted that developing expertise, improving skills, getting attention from potential future employers, and potential freebies play into this as well. I should note that a number of book reviews I do, the titles are sent to me at no charge specifically because I review books. For full disclosure, I paid for the beta version of this one so I could watch it develop from the very beginning.


Part 5 is all about scaling your technical blog. Think of sites like TechCrunch or Slashdot. They have morphed from blogs to full scale online news sites. Other sites have hired a staff of bloggers to post content and publish multiple articles each day. You could add job boards to your blog, or any number of additional services. The sky's the limit if you have built the brand up to a point where that's possible. In addition, you may want to develop an integrated Social media strategy, going beyond just a personal page and developing fan pages and other ways to promote and actively drive traffic to your site(s).


Bottom Line:


This is a wonderful resource for any aspiring blogger, and for those who are trying to fill a technical niche with their blog, it's especially valuable. Will you realistically use every suggestion in this book? Probably not. Still, even if you only find 15 or 20 actionable tips, you will have a significant change of game underway to your blogging presence. It's been a lot of fun to review and consider this book, but the real beauty is that it gives me a blueprint that I'll be able to work with and follow for months and years to come.

The Humor in the Situation

Every once in awhile, I like to go back to my old blog, which has admittedly fallen very fallow since I started TESTHEAD, and see what I wrote way back when. Some of it is of a personal nature, and some of it doesn't really belong on TESTHEAD, but every once in awhile, I find something I wrote that still resonates with me today, so today I'm going to share one of those. this post was originally written on 01/20/2009.



I received an interesting comment over the weekend, and it led me to do a little bit of reflection. Someone commented that it was amazing how much of myself I put out there, and the way that I can comment on it, both the good things and the bad, or if not actually bad, at least potentially embarrassing.


I thought about this for a little bit, and I came to realize a few things about myself over the past couple dozen years or so. Somewhere between the ages of 15 and 22, I developed a sense of humor, and I think in many ways, that has made a tremendous difference in my life.


To put this into comparison, when I was a teenager, I felt very isolated and somewhat out of step with everyone else I knew. For the longest time I thought it was something related to my personality or my "just not belonging". Looking back at those years, I was painfully shy, very awkward, and absolutely resistant to anyone poking fun at me. Being the butt of a joke or in any way being ridiculed was the most painful thing for me, and I'd often lash out at people who did it. Needless to say, this invited similar treatment to continue. It stemmed from wanting so desperately for people to "like" me, and so I'd try so very hard for people to like me by any means necessary... hardly a recipe for success. Looking back, I realize that I was a bit of a miserable twerp... who would want to hang out with someone like that?


As I grew older and put myself into endeavors that required criticism and rejection, I learned to open up and let go in ways I was never really willing to before. Two primary experiences in this vein were working for a modeling agency and being a musician. Modeling was fun in a way, but talk about learning to deal with rejection! I remember well going out for well over a hundred calls and getting asked to participate in perhaps a dozen or so opportunities. To put that into perspective, that was less than a 12% success rate... but it also meant I got to do a dozen or so things I wouldn't have done had I not gone out there. Likewise, it helped to teach me that really little things like the placement of my eyes, or the skin tone that I had, or the part and texture of my hair, while practically identical to the other person, made a difference between getting a gig or not getting a gig. What can you do in those situations? I learned to laugh about it. I also learned to laugh at some of the calls I went out on, as well as some of the more interesting propositions for work I received (and believe me, in San Francisco, as a male model, you can get some rather interesting, and some might say frightening, propositions... and yes, there were quite a few I turned down for being a little too interesting).


As a musician, I had to deal with a totally different kind of rejection. I wanted to play in modern rock or alternative bands, but I didn't have a voice that lent itself to that styling. I had a big, loud, scratchy rock voice that worked great with heavy metal. Now, don't get me wrong, I like metal just fine, but it was not my core influence, and singing about metal stuff just never felt entirely right with me. My first band has all sorts of songs that I wrote in deadly earnest that were, for all practical purposes, me wearing a mask and pretending to be someone else. I learned to deal with the rejection and the "in-authenticity", and slowly opened up to letting myself be more "me" as time went on. In effect, I learned to let those alternative influences come through and be part of my style. So what if they didn't exactly fit the music I was performing... we weren't a cover band, so why should it matter if my influences were more Sisters of Mercy than Guns N' Roses? With that, I decided that a smile would do more than a sneer, and a touch of humor would often disarm people and make them more comfortable.


Later on, when I started writing in newsgroups and such, I came to a realization early on that, when someone approached a topic with a little bit of self-deprecating humor, it allows others to share with you and feel less pensive or guarded. It also allows you the ability to make comments about what you see on a slightly safer ground, since it's lots easier to comment about people's "motes" when you've adequately identified your own "beams" :).


So yes, when people see what I write and wonder how I can be so open and so willing to skewer myself in public, the answer is that it took a lot of time and realization that, in many ways, whether it be an accomplishment, a failing, a shortcoming or even a tragedy, sometimes the best way to deal with it and communicate about it is to find the humor in the situation, and put the humor up front. Honestly, the alternative is just way to painful to deal with much of the time, but somehow, finding the humor makes even the worst times feel a little more bearable :).

Standing Up to "Stop Stealing Dreams"

Seth Godin is at it again.

In 2010, Seth wrote the book that had a galvanizing effect on both my goals as a tester and my trajectory with my career in general, but he also touched upon many of the aspects of education that I was frustrated with. As we are looking at a transformation unlike any in our history, we now have a very different reality facing us. Once upon a time, knowledge was scarce, difficult to come by, and therefore academic education was the only way to get it. Today, that is no longer true. While there is still a large body of "regulated professions" that require a certain education attainment (let's face it, if you want to be a doctor, a lawyer, a dentist or a CPA, you have to have credentials that state that that is what you are and what you do), there are many areas where that is absolutely not the case.


In Seth's latest work, Stop Stealing Dreams, he makes the point that we are setting ourselves up to be compliant, obedient workers for a factory system that no longer really exists. As he eloquently stated in Linchpin, the factory model, and the deal it represented to multiple generations of Americans, is over. Globalism and the realities of global capitalism has rendered it obsolete. We cannot survive on an industry of cheap, replaceable workers any longer, and most of us don't want those jobs. What we want is to work in areas with meaning, with passion, and with determination that we create and within bounds that we choose to set.


What would you think of a "school" that offered the following:

• Homework during the day, lectures at night
• Open book, open note, all the time
• Access to any course, anywhere in the world
• Precise, focused instruction instead of mass, generalized instruction
• The end of multiple-choice exams
• Experience instead of test scores as a measure of achievement
• The end of compliance as an outcome
• Cooperation instead of isolation
• Amplification of outlying students, teachers, and ideas
• Transformation of the role of the teacher
• Lifelong learning, earlier work
• Death of the nearly famous college

These are all ideas that Seth offered as an approach to learning and education that would revolutionize everything. Instead, we are still dealing with the model developed for the start of the industrial revolution. Rather than throw ever more money at a system that's past its prime, would we dare to tackle something even more audacious? A complete overhaul of the system.

These are the questions, and many more, that Set asks in the 150 chapters. Note, these chapters are often quite brief, less than a full page of text. they read like blog posts because, really, that's what most of these are. Taken together, they make for a compelling narrative of doing some thing different, anything different, and getting beyond the model of compliance and getting towards (or back to) a model of crafstmanship, passion, and real learning for the long term. Check it out. You may agree or disagree, but I can promise you, you will not be bored!

In Support of Context-driven Principles

There's been a lot of talk about varying "schools of thought" as of late, and this seems to have touched a few nerves today with an announcement made by Cem Kaner regarding the Context-driven School of software testing.

This announcement has caused a bunch of "bounces" and comments from various people in the testing community. Is Context-driven testing dead? Is the Context-driven School of Software testing dead? What does it all mean?

For me, it brings me back to the recent discussion of "Is Testing Dead?", and I feel like I have the same answer I had to that. For me, the answer is "no, but things will likely not go on exactly as they had before"... and frankly, I think that is entirely OK.

I have often found these discussions tend to get political very fast. Just like with philosophy, we often have little in the way of disagreement with the underlying core of a philosophy, the "principles" that guide our vision. What we usually end up having is debates on the implementation, the "whats and wherefores", and that tends to be a lot more contentious. In my world view, there can be many implementations of principles, and we can challenge, debate, and consider them all we want to. To borrow a line from Gamaliel, a rabbi mentioned in the New Testament:


"And now I say unto you, Refrain from these men, and let them alone: for if this counsel or this work be of men, it will come to nothing: but if it be of God, you cannot overthrow it; lest haply you be found even to fight against God" (Acts 5:38-39).


The point I get from this (and yes, this is specifically religious and borderline "out of context", but not completely, so work with me here...), is that we can argue all day long about the implementations of things that are ultimately cults of personality, or we can look more deeply at the principles that make up the movement. For me, I care a lot more about whether or not the principles are correct than I do if one or another thought leader looks at it from one angle or another.


This is fresh and new, and I will guess there will be a lot of comments on this going forward, both today and in the future. Will this be disruptive? Perhaps. Will it be damaging to the cause of context-driven testing? I don't think so. Too many people have shown the value of the context-driven principles, and they will stand the test of time if indeed they deserve to. Many people find tremendous value in them. Many people still believe in standardized best practices. Ultimately, time will decide which approaches will stand the test of time, and which will be enshrined as guiding principles in the future. I know where I'm placing my bets... how about you?
 

Far Away From Close

Well, as I should have had the foresight to see, it looks like the book project I discussed a couple of weeks back may well be dead before it even gets started. Much as it pains me to say, it looks like my musical history is repeating itself.

Back in the early 90s, I had the opportunity to play in the Bay Area music scene and in the process we managed to build quite a loyal following. We also had, through many years of influence and history, gotten to know many managers and labels that showed interest in us. that is, until they showed us their contracts and we questioned what was in them. Suddenly, the interest dried up, even as we were progressing and getting an even larger following. What was the issue? It had to do with long term ownership of our name and our assets, i.e. our songs. this wasn't a greed issue, it was an issue of controlling how our music was marketed and under what circumstances. Also, we wanted to have a very concrete explanation of where the money went that was earned from our music and performance sales. All we wanted was clarity. What we got was stonewalled, and then finally we didn't get offered any more contract opportunities.

I have told my band mates over the years that we suffered from a "lack of faith in Angels" and for the record, I am glad that we did. When I say a lack of faith in Angels, what I'm referring to is the notion that a large entity like a label or a manager would break us into a larger market and we'd become superstars. Instead, we went on our own wits and our own instincts. Sometimes they were rewarded. Sometimes we stubbed our toes. I should also mention that, ultimately, this venture of ours failed. The market changed, tastes changed, and we folded up our tent. What was good, though, was that we were able to keep all of the rights to the media we had created, so that, when the time came, we were able to make a deal to release our material on our own terms.

It seems that history is repeating itself. There was a lot of excitement about the two of us (me and my collaborative partner) working on this topic together, but first, there was just some details we wanted to have clarified. The request to have those areas clarified has been met with "radio silence". I've been around a while now, I see what's happening, and I'm willing to give solid odds that we will not hear back from the people interested in having the book written. We're too much trouble, we ask too many questions, thus, we're too much trouble to try to do a deal with. I could be wrong, but from past experience, that's certainly what this seems like. C'est la vie!

Does that make me a little sad? Yes, but at the same time, it's also giving me and my collaborator some other thoughts and ideas. The most prevalent... do we actually need to have a traditional publisher at all? As I've gone through and looked at a number of the titles I've read and worked through, yes there are a lot of traditionally published titles. there are also just as many titles that started out as web site content and self published ebooks. If I have determined that most of my titles are desirable in ebook format, and from alternate methods of publishing, how many others would feel the same way? Sure, there's a cachet to having a traditional paper-bound book made, but really, my goal is to explore the ideas and share them with other testers. Either way, we've decided to go forward with the project. How it will be distributed when we are finished, I guess that remains to be seen :).

Book Review: The Manga Guide to Biochemistry

As a tester, I used to tell people that I could go into any field and I'd be able to test their software, and for a long time I believed it. That is, until I went to work for a company with a product that was heavily dependent on physics and physical phenomena, which was not my strong suit.


I learned from that experience that domain knowledge is vital, and while you can fake knowing some things, or quickly pick it up as you go, there's some stuff you just can't fake. Physics is one of them. Biochemistry is definitely another. It's just not something you can casually pick up on the job, you really have to spend some time with it and come to grips with the world of biological interactions and the cross section of biology and chemistry. For a minimal pain related approach, The Manga Guide to Biochemistry is a wonderful way to get that fundamental domain knowledge.


NoStarch has gamely taken on publishing "The Manga Guide to..." series of books in English, and for those of us who are proudly Otaku in our general interests, to have Manga volumes dedicated to some of the headiest technical topics in the sciences is pretty awesome.

Make no mistake, these books do not dumb down the topics, but they do use the conventions of Manga to illustrate topics in the classic ways that have endeared generations of Otaku to Manga. The silly drawings, the subtle fan service, the inside jokes, the goofy drawing styles to show stress, pain, embarrassment and joy help keep the reader engaged and entertained as they go through what is, seriously, a challenging topic to digest. It's a true testament to the effectiveness of the Manga Guide series that they are able to tackle these subjects so effectively time after time.

The Manga Guide to Biochemistry starts at the beginning, and walks the reader through the basics of cellular structures. It then moves into the chemical structure of cells, the methods of nutrient absorption, and the chemical reactions and the mathematical models to understand and interpret the results of experiments. these experiments range over topics like respiration, metabolism, photosynthesis, lipid absorption, breaking down of saccharides, and amino acid construction and even protein folding.

There are two levels to these books. The first is the actual Manga story. We follow the daily adventure of a high school girl named Kumi obsessed with dieting, and her friend Nemoto hoping to get her to see beyond her obsession by teaching her about biochemistry. Aided by his biochemistry professor, Kurosaka (who also see that Nemoto is completely smitten with Kumio and decides to play matchmaker... hey, this is a Manga after all ;) ), Nemoto help Kumi understand the complex interactions inside of her body between lipids, saccharides, amino acids, cholesterol and enzymes and how they work and are constructed/deconstructed on a physical level). The second level branches into more in-depth discussions and study of how these processes actually happen.



Bottom Line:

There may come a time when you will want to explore this topic, whether as an introductory text to get your heads around it, or maybe even to give a first glimpse into what working in biotech might entail. While I cannot say this would be the only reference you will ever need (not even close), I can say that it will go a long way towards de-mystifying the subject and give you a lot of good tools to reason through. It will also give you a better understanding of how biochemistry happens inside of living organisms and how we can make use of that information and approach towards constructing tests to address that phenomenon. Yes it is "so kawaii" (meaning "so cute") but don't let that deter you. There's a lot of meat here to digest (pardon the pun) and this is a fun way to consume and digest it.

Foundations Flying Solo, Sort Of

It's almost Saturday, and it's the end of week three of the current BBST Foundations class being offered by AST. Yeah, I know, I've done this lots of times, but this class is a bit different. First, I think this is the first time a class has run without any input from Cem Kaner, Becky Fiedler or Doug Hoffman, at least that I am aware of. Second, this is the first stint where I'll be taking the reins of the entire monster that is BBST via AST, and from March 31st, 2012, it'll be all mine. That though is both exhilarating, and at the same time, absolutely terrifying.

Let me back up a bit here. For those who are familiar, the Black Box Software Testing classes were a joint effort developed by Cem Kaner and James Bach. The material that is presented was initially written by them and compiled over several years. It's been well researched, field tested, and run regularly for the past several years, always under Cem's watchful eye. Cem recorded all of the videos for the course, a huge undertaking and tremendously time consuming. In short, BBST has been shepherded by Cem and Becky for years. Both Cem and Becky have solid academic credentials, doctorates in different disciplines, and lots of background in academic circles. Still, after so many years, they decided it was time for someone else to handle the AST commitment to the BBST courses. That's where I come in, a guy who took twenty years to cobble together a bachelors degree, who has no higher credentials beyond that, and who, frankly, is much more comfortable speaking "dude" than he ever will be discussing or interacting with academia. Yet AST seems to believe that I'm a good bet for running this initiative, so I'm giving it my all.

Before anyone considers throwing a pity party for me (and really, I ain't asking ;) ), I have to say I've had a great staff this time around. Adriano Comai, Mohamed Lahrech and Ray Oei have been my partners in crime for this go around, and they have done a fantastic job keeping on top of everything, and sometimes that includes telling me when I'm forgetting something. Yeah, I'm their Lead Instructor, but they hardly need me there, to be frank. The group of participants this time around has been great. Sometimes there are challenges and clashes of personality (testers being difficult and nit picky?! Perish the thought (LOL!) ). Seriously, it's been a great group, and they've really been great.

Tomorrow at midnight, our final exam will be posted, and then we'll see if I and my band of brothers have pulled this off. It's scary to know you are taking over something that has been run by a man that's considered a legend in the testing community. For those about to head into the final exam, I wish you good vibes and I look forward to seeing your answers and commenting on them. For everyone else considering if they want to take any of the BBST classes, I of course hope you will. While I can't promise to be your instructor (though there's about four times this year that will be a good bet ;) ), I believe the volunteers who teach these classes are great, and I think your being involved with them will make for a very worthwhile month of your time. We may not be perfect, but we give it our all, and I think you'll see that. 

#STPsummit: Agile Transitions, Day 3

Just like yesterday, this is a "Live Blog" effort.

And we are back for day three, the final day of the STP Online summit for "Agile Transitions".

Today's focus is, again, meant to help give some "How's" to play with, and today's panel will be real personal. How so? I'm one of the panelists!!! Henke Andersson is first up, so let's give him the floor.

Henke's talk is focused on "Excelling as an Agile Tester". What's cool about this is that we get a glimpse into how Agile is practiced in Sweden. According to Henke, the best way to do this is to start with the following principles:

• Take Responsibility 
• Trust Each Other
• Solve Problems 
• Think Independently
• Espouse Creativity
• Have Open Communication

Agile Testing is meant to embrace the following abilities:

• exploration
• discovery
• investigation
• learning

We need to ask “Is there a problem here?”, and it's important we champion the search for new information. This information should be sought and driven by us asking questions that haven’t been answered, or for that matter, may have never even been asked before. In short, Agile testing must be a Sapient process! We must be thinking, we must be actively engaged!

A valuable tool that we can use in this process is Session Based Test Management (SBTM). SBTM provides us with time boxed and focused test cycles. We create a focused mission and then develop specific testing charters. These can go a long way towards giving us the ability to dig in and learn more about the product. Since the checking is the automated component, that means we need to dig for much more rich information, and SBTM will often help give us that boost. It allows us to visualize our testing challenges differently. It also gives us a specific and measurable way to show what is being done while we test.

The overall goal of SBTM is that it provides very tangible benefits. We can determine our testing velocity (to go along with the development velocity, of course you'll need to track points to really get a handle on that), it provides valuable communication, it can give us a gauge as to the health of the product testing process, and it allows for a tangible way to bring testing out of the dark; we can truly point to the time we really spent testing and how much our testing was effective.


My talk is next, and I focused on what it means to be a Lone Tester in an Agile World. I'm not going to be able to blog and present at the same time, so I'm giving a greatly condensed version of my talk right here.

Being an embedded tester, a lone tester, in an agile team is a common reality. While I consider it my specialty, it's something that a lot of people deal with. I only made my transition a year ago, so I'm very familiar with the discomfort and the strange sensations associated with becoming part of an agile team for the first time.

The Agile Manifesto gives a lot of time to how to make quality software. It doesn't say anything about testing. It's not meant to. It's meant to help software developers create better quality code. They have many tools at their disposal to do that. They use Test Driven Development, Acceptance Test Driven Development, Behavior Driven Development, and a number of other tools to help them develop better quality code than what was developed using traditional methods. It's sliced way thinner, and the featured are added one by one, often rather quickly. There's a lot of tips and techniques that talk about testing... but where are the testers?

Testers are not excluded from the process. We are not "old fashioned anachronisms", we are still needed and we offer a great deal of value, but we are not there to do the Status Quo "testing" of yore. Theres' much less of a need for a "last tackle on the field", the "bug shield", the "guardian of quality". Many of the simple things that used to slip through are handled with TDD, ATDD, BDD, and Continuous Integration. Many of the "obvious bugs" are weeded out in these early stages, and we should rejoice. So much of the grind of testing is taken over by automation and unit tests. This is a good thing. Be happy, because there is *SO* much we can still look at and focus on as testers! We can ask the hard questions of the product, the ones that require an active and engaged brain to interpret and consider. No automated test will ever take the place of that! Also, we have the chance to be any number of things to our teams. We can be anthropologists. We can be journalists. We can get the whole story (or as much of the story as we can find).

Finally, along with the Agile Manifesto principles, I believe being familiar with and actively using context-driven testing principles will aid significantly in you effectiveness with an Agile team. The Agile Manifesto and Context-Driven Testing principles complement each other very well.

...and now I'm done.

Our final session is "Scott's Top Ten Takeaways" and a Q&A panel with several of the presenters. Note, not every takeaway is going to be specific to Agile Transitions. These are what Scott felt were the most valuable takeaways. A lot of us covered many of the same areas, so it should be no surprise that several of the top ten were things that we all mentioned.

10. Agile implies being guided by the principles of the Agile Manifesto.


9. In Agile, "Developer" refers to all of us who help deliver the product. Yes, that includes "Testers"!

8. Testing is Testing, Agile is "Context"... and checking is checking, independent of context.


7. In Agile "traditional testing formalities" may not be necessary. If there's value in doing them, then we will. If there isn't then we won't. If there's something in between that makes sense, then do that.


6. In Agile, like in healthy families, everyone pitches in! Everyone needs to step up to the plate and learn and try new things.


5. For Agile to succeed, you can't just "do" it, you have to "be" it.


4.  Change is uncomfortable, big change even more so... even good change.


3. Successful Agile demands a collaborative, whole team culture. The team is responsible for success and failure. There is no "us" vs. "them".


2. Successful Agile demands that the whole team share the same vision and values.


1. At the core, Agile is about PEOPLE forming a culture around shared vision and values.

The presenters panel is now underway.  Our first question is about Acceptance Testing, and who is responsible for it an who does it. I answered that it's important for the tester to put an emphasis on acceptance testing to make sure that we are doing what the people paying for the work want. The product owner is the one that ultimately accepts the stories that are created, but it's up to me to make sure I have given them as much information as I can to make sure that they can make the final decision to accept the stories.

Another question was focused on pairing and when testers can pair, when they should pair, and how to approach the subject. I'm lucky in the fact that one of our founders gave me some good advice. If I need to learn whats going on and I need to pair test or pair learn, just go and do it. Sit and become a third wheel if pairs are already determined. Borrow a developer to look at something you have discovered. Work in with others on the team where it makes sense. If you do your homework, you'll likely be able to find plenty of helpful hands and lowering resistance to the process.

There were a lot of questions about tools and which tools are appropriate and work. Ultimately, I would suggest working with the stack that your development team uses. If you are automating testing, the best approach is, where possible, to see if you can come up with a format that works for you and that you feel comfortable using. You may have to make a stretch to do that, and you may have to learn a tool to make that happen. You may need to make your own tools, but ultimately, it comes down to solving problems, not "solution probleming".

Testing vs. Checking: what a loaded phrase (LOL!). The truth is, we do both, all the time. Let's make sure that we are focusing on what's important for that particular period. If we need to automate, then do so. If we are doing SBTM, then do so. Do what is necessary for the time and the need.

Well, that's it. This was fun :). I'd definitely do it again if asked.

#STPsummit: Agile Transitions, Day 2

Just like yesterday, this is a "Live Blog" effort.

And we are back for day two of the STP Online summit for "Agile Transitions".

Today's focus is, again, meant to help give some "How's" to play with, and today's panel will be giving us three somewhat familiar faces to see and listen to (well, I'm familiar with the three; your mileage may vary, but if you are not familiar with Lisa Crispin, Selena Delesie and Lanette Creamer... you need to get out more :) ).

The first talk for today (Session 4) is from Lisa Crispin, and it's Lisa's take on the topic of Successful Agile Test Automation. For most of us, we probably have a mixed bag when it comes to getting tests automated. There are a number of obstacles. In my world, we have unit tests and TDD level tests, and then we have my area that's mostly external facing tests (that's by design, but it does mean that what I look at is not entirely the same as what our development team looks at). Additionally, in many environments, we struggle with the idea of a sustainable pace. We face a real danger of things being back ended because we're often rushed, and because of that, there's just so much to do and so little time to do it. This is technical debt building up, and it ultimately saps our energy, the same way that financial debt saps our energy.

One area that we miss is that test code is often treated as second class. Out tests are as vital to our success as our production code, so it's important that we consider our test code on the same level, employing the same level of dedication, rigor and focus (this is why I have a github repository for my tests and frequently make changes and updates). We also have a bit of a challenge when we "own the automation" piece of the puzzle. I can vouch for the fact that we do spend a lot of time doing coding, debugging code, manually testing to confirm our scripts, and other maintenance issues. For a Lone Tester like me, that can often mean I have to choose whether or not I'm focusing on automation or actual testing. For us loners, there's no way to do both at the same time.

Testers do a pretty good job when it comes to identifying areas to be automated; exploration, troubleshooting, etc. For me, that part is not the problem. It's the mechanics of the automation that often causes me headaches. I was lucky in that I got a jump start with one of our developers where we paired for several weeks to get me up and over that initial hump. Still, I spend a fair amount of time tweaking the details so that they do what I really want them to do.

Our developers have a good handle on Continuous Integration, and my goal is to make it so that my tests can get the same treatment. Once I have my tests running in a Continuous Testing format, then I'll know I'm where I need to be :). Another important aspect is that, just as developers re-factor source code, we need to be ready and able to re-factor our test code. It's important to have a good focus on what we want to test first, then incorporate that into the way that the code is written. Experiment and learn, and see if new ideas come together. Another recommendation... under-commit. Don't slack, but really understand what you can really do, and then focus on the work that can be realistically done. Remember, testing is not a "phase"; it's always happening. Oh, and remember, "friends don't let friends Record and Playback" (with thanks to Claire Moss for that rather pithy comment :) ).

The second talk for today (Session 5) is from Selena Delesie and the topic is Culture & Inter-Focus Area Interactions. Let's face it, Agile is a great methodology and set of principles, but we all have to work with real people in a real world that's sticky, messy and hardly every working exactly as planned. We're just going to go and "Do Agile", and all of those underlying cultural realities where everyone is self directed, focused on the goals and willing to go with the whole approach will just fall into place... yeah, right!

In most cases, even when Agile is an active goal, what the customer wants tends to be what the team works on, methodology notwithstanding (in fact it's often not standing, it's set aside as often as its espoused). It takes a lot of behavior modification to make Agile work. Managers need to let go and stop micromanaging. Scrum Masters and PM's need to step back and realize that they guide and direct, they don't run everything. Most important, not everyone is on the same continuum. Development isn't in a vacuum, the rest of the company has to be on board with these changes as well.

A company's culture can be both wondrous and insidious. Regardless of where on the continuum you fall, it's important to realize that the culture is often deeply ingrained, and that culture can sabotage all of your efforts if you are not focusing on it. It's difficult enough to change one person's focus. Getting a full team or company to play along is a significant challenge. Coaching and mentoring is often needed to help foster this change.

Selena talks about an idea of "Living in Clover" and from that idea, she talks about "Clover Culture" which goes through 9 "C" concepts; Common values, Connection, Clarity, Creativity, Commitment, Collaboration, Cultivation, Competence and Communication.

- Common Values: Start with a common base, determine the teams values.
- Connection: Build connections to and relationships with people.
- Clarity: Seek first to understand.
- Creativity: Dare to look at other ways to do things.
- Commitment: Do what you said you would do, when you said you would do it, the way you said you would do it (i.e. the Larry Winget Golden Rule :) ).
- Collaboration: Work together... no seriously, work. Together!
- Cultivation: Succeed by giving your team members the chance to stretch and grow.
- Competence: once you've stretched and grown, harden that skill and keep upping your game.
- Communication: Once you have understood, seek to be understood.

Good suggestions and good ways to make it possible that we all have a better relationship with our team members and understand what we need to be doing to make our teams rock. They won't rock unless we make them rock, it's that simple!

Our third talk of the day is from Lanette Creamer and the topic is about "Avoiding Agile Perversion".  Lanette has recently branched out and developed her own company, and these changes in her reality have helped to shape the way that she looks at things. When we "pervert" something, we are taking something that was defined one way and misapplying what we are supposed to do. What we are supposed to do is certainly subjective, and varies in different scenarios, but generally speaking, when the functionality of a process is called into question, that's a time to step back and reflect on what we are doing. This seems like a good example of when we see "small a" agile and "Capital A" Agile. We often think in terms of one or the other (I consider my team to be more of an agile team in that there are certainly areas that we don't to the letter follow every single element so that we could qualify for "Agile(tm)" designation, but we're pretty close in my mind.

There are lots of reasons why teams implement Agile transitions. They range in several ways from faster time to market, to better code development, to helping deploy continuously, to taking on features and testing simultaneously, to getting out of the death march mentality. These are all legitimate reasons, and they may all help encourage a transition to Agile. It's important to realize that we will have stumbles, we will have setbacks, and we may not get everything into play at the outset. That's not necessarily a bad thing. As long as we are striving to get to that place, we're probably on a  good track.

Agile doesn't mean that all our problems will get fixed. It may help us identify them faster, but the fix may take much longer to implement after we have identified the issues. We often have a problem with admitting we may well be in the wrong, or need to make changes for ourselves for the other changes to be effective. Yet change we must if we are going to be effective. Clint Eastwood famously said "A Man's got to know his limitations" (note: that's all encompassing "man" in the generic sense). There is a level of exhaustion that we can't just overcome with more effort. Time and rest and recuperation are needed to get these things in place.

Many of the projects that failed that claimed to be Agile seemed to have a special kind of Agile system called "Don't Know". A lot of teams that claim to be agile really don't know what they are doing. Evaluating the transitions are often difficult, because we don't necessarily know when we are effective, or if we have to hybridize our systems while we put a more formal structure in place. Sometimes, we have to start in a place that's less than optimal, but start we must.

Lanette shared some various flavors of Agile Perversion:

Velociraptors: losing people, urgent fixes, no dates changed, heroics required. Survivors rare. To defend against Velociraptors, there needs to be a sacrificial victim, and each week, the person would change. A rather clever defense, I must say. The point is, there are always crises, we just need to ultimately manage and neuter the Velociraptors.

TallyMeasles: accounting and counting, it's all about the measurements, and what we do alone. It's all about the points. Politics are rampant, little is done for the needed areas, unless they help the point count. Whole Team is not in effect here. It should be and needs to be.

Fearcidity: Firings and layoffs happen frequently. People don't want to step out of their comfort zones, no one takes any risks, paranoia runs rampant, team members avoid each other unless absolutely necessary. Do not manage by fear, it's a lousy motivator.

Victimiosis: team members lose faith in the team, no hope for improvement, environment is toxic, unable to make improvements. Do your best to try to rid your team of this fear, give them ways to realize that they don't need to be afraid. Change the environment, run retrospectives and do what it takes to change the organization. Barring that, change your organization!

Agilepocalypse: This is the Agile at all cost crowd. "Too much Agile, not enough listening to the users". Very holier than thou approaches. Agile perfection isn't a destination, it's a process, and it's one that requires growth and continuous improvement. Agiler than thou is really not required, nor is it desired. Without good interactions with our customers, what we have is a pile of tools we're really good at using.

The point with these "perversions" is that they can be overcome. They might take time, they might take a lot of sweat and effort, but ultimately, to get beyond them, teams have to be committed to getting past the cultural baggage.

Tomorrow is the last day, and during the second hour is my turn! Hope to see you all there.

#STPSummit: Agile Transitions, Day 1

This is a "Live Blog", meaning it will be frequently updated during the day.

Today is day one for the Agile Transitions Online Summit that SoftwareTestPro.com is sponsoring. I had the pleasure to be asked to be one of the speakers for this online conference (I'll be doing my part on Thursday at 11:00 AM PST), but until then, I get to participate and hear the other speakers... and in a greatly abridged and condensed manner, so can you :).

The first talk was given by Scot Barber, and kicked off the conversation with "What is Agile, Really?" There's so many answers, and an immediate reference to the original manifesto (I have a feeling a lot of people are using this; I know I am for my talk :) ). For those who want to refer to the manifesto, you are welcome to go to http://agilemanifesto.org. The important thing is to see that they said nothing about automation, lack of documentation, or even a presence or lack of presence of testers.

The people and how they relate are what really matter. the phrase that I often hear is "we practice little a Agile rather than big A Agile". Ultimately, "agility" is just a way of saying "we agree with the principles in the manifest and will do our best to apply them". Testing is also important in the Agile world, contrary to some opinions. Testing may be different, it may be distributed, it may be done in different ways, but it is still needed, and it still matters. We also need to let go of the idea that software needs to be tested exhaustively to be successful. A key takeaway to me was that "Good testing leads to business success, as quickly and cheaply as possible". That's not heresy, that's honesty. If you've ever hear Scott speak, you can probably already hear his voice and inflections with these statements :).

Talk 2 was given by Robert Walsh, and focused on the differences between "Agilists" and "Traditionalists". Note the quotes. This is by design and is meant to show that these are perceptions of each, and that these are how we often see these  designations in broad stroke fashion. Traditionalists are often seen using waterfall/iterative processes, where the output of one section of the process is the input to the next, and how, if things change, the whole process is jeopardized. By contrast, Agile allows for change and options to be modified for each iteration. The Scope is different for each approach.

Scheduling is another difference, where testing done towards the end of development and is a distinct phase of the project. What often happens is that, if the development phase runs long, the testing phase is either curtailed, or it's bunched into "crisis mode" with lots of crunch time towards the end. More testing in a smaller space, but how good is the testing in these cases? By contrast Agile Schedules, while much tighter, are focused on smaller slices of functionality. Rather than a huge set of tests for a large round of features, there may be jut one feature to look at, or even one aspect of a feature (or even just one story).

The Approach to testing likewise differs in Traditional And Agile spaces. In traditional development, we may not even get access to the code until it is mostly completed. Once we do get the code, then we need to walk the various test scripts that have been designated (we may have some automation or computer aided testing, but often, we don't, and these are done manually). Changes late in the game run the risk of derailing the project. In agile environments, change is much less threatening, since the slices of product are so much thinner. Time to test is much smaller, and so, if there are needed changes, they can be made without totally threatening a project's delivery.

Bugs and defects can be a real "crusher" when it comes to traditional products and projects. There's a lot of cycle and churning that happens when we have to deal with a large number of features delivered at the sam time to be tested in bulk. Agile processes, and the slicing of the stories, as well as testing happening from the first iteration, helps make sure that the more catastrophic bugs are found early and by numerous different mechanisms.

Talk 3 covers transitioning from Traditional tio Agile Testing, and was presented by Bob Galen after a couple of technical challenges (what would a Webinar be without them ;)?). Bob addressed a number of myths and realties related to making changes from Traditional to Agile teams, and the first is that you must be highly technical to make the move (not true, though some programming and scripting will certainly be a plus). Automation is another myth; you don't need 100% automation to be agile, but if you can get a lot of your mundane stuff automated, start where you can and get as much as you can where it makes sense to be so. It also takes time and there are variations in what Automation actually means. It's also important to realize that Testers are not specifically responsible for automation; it needs to be a whole team effort. Ideally, all of the tests developed should filter into the Continuous Integration steps and processes.

A huge myth is that there is no test planning or scripts in Agile. It's not true, though the approach is different. I can attest to this personally, as many of my plans go into our Tracker or that I set up as shared docs. More times than not, though, they are discussed with the developers and they are agreed to on many of the stories. It's an  emphasis on "just enough process" and "just enough documentation" to do the job, not pounding out large documents that will never be read or referenced. Another myth is that all of the tests must be run all of the time within the sprint. That may be realistic at times, but at times it may not be. It may be especially difficult with a legacy application with a lot of regression and tons of tests that would run for an extended period. The fact is, tests are always scaled on a risk-based criteria. We want to run the mission critical tests first and often. Running everything may be valuable, but there may be times, even with automation, that that may be a challenge. It takes time to get things scaled and optimized.

Another myth I'm happy to see die is that Testers are the "Quality Gate", the last tackle on the field mentality. Everyone needs to be responsible for quality, and a Whole Team view is much more appropriate. Another myth is that the hand off from development to testers ends up happening late in the sprint, and that's just "the way it is". My own experiences show it doesn't have to be that way, but yes, it sometimes happens. It doesn't have to happen, though, especially if the work is split out as it's supposed to be, so that micro handoffs occur. Having a good communication flow is important, and again, we come back to the conversation. Have those conversations. Don't focus on filing issues, focus on getting them fixed.

Many times, testers believe they are second class citizens in Retrospectives,and that they don't have the ability to influence change or offer valid feedback. This is definitely false, and it's something that testers have a role in, but they have to make the effort to be part of the conversation. We can't expect to be heard if we don't make the effort.

So that's it for today! We'll pick this back up again tomorrow at 10:00 AM PST. Hope you'll join me again :).

May You Live in Interesting Times

One of my favorite Dan Carlin "Hardcore History" Podcasts is the one he did with James Burke. As many of you may know, I happen to be a huge fan of James Burke, and his series "Connections 1", "Connections 2",  "Connections 3" and "The Day the Universe Changed". One of Dan's first questions to   Dr. Burke was if he thought we lived in interesting times (the famous double edged Chinese Proverb of uncertain origin, but familiar to many).

Dr. Burke's answer was that pretty much anyone felt that they lived in interesting time based on the context of their age. Even the so called Dark Ages had brilliant flashes and amazing things happening (and we must remember that while Western Europe was dealing with its so called Dark Age, Arabia, India, China and the civilizations of the Americas and many civilizations in sub-Saharan Africa were celebrating a Golden Age.

This cartoon from Two Leaf Clover artist Aaron Scott reminds us that, even in the wonders of the ancient world, we don't really know the whole story. Because of that, we have made our own speculations and attached much of wonder and mysticism to places like the pyramids, the Kurgyns of the Eurasian Steppe, the Barrows of Europe and, of course, the various henges within the British Isles, of which Stonehenge is the most famous.

It makes me wonder... what will people 3,000 years from now think of our age? Will we be looked at with some sort of wild-eyed mysticism? Will we be seen as horribly backward by their standards, or will we appear to be very much like they are? Likewise, how much were our ancient ancestors more like us than different from us? How do we know that Stonehenge wasn't the office park of its day? the fact is, we don't know, but in a way it's kinda of fun to think about :).

Ready, Aim, Deep Breath, FIRE!!!

I've been on pins and needles the past couple of days.

As I said in my last post, I've been given the opportunity to write a book on a topic that is near and dear to me (yeah, I'm still being a little cagey because it's not a done deal, but it's looking very likely at this point).  What helped me talk myself off the edge? Actually, I didn't, a friend and compatriot did.

To give just a little more back story, I was sent a proposal for a book that ranges in scope from complete beginners to domain experts and everything in between. It's a title about a technology that I have used in the past, but I felt less than expert at it (and in many ways, less than expert is putting it kindly). However, I was also reminded that I had vivid memories of the frustrations that other people feel when they try to learn something new.

Often we start with trivial projects that we skim through because we feel way too silly actually doing them. They're so obvious after all. The problem often makes itself manifest after that gentle introduction. Now we're expected to have fairly deep domain knowledge and a more than passing understanding of what we are working with. It's like we were introduced gently and with great care to A, B and C... and then we pick back up again with K, O, Q and S. What happened with everything in between?!

The challenge is that we have a lack of context in general and a lack of personal context in particular. Some books get this balance right, while others miss it entirely. Having gone through the process of "Learn Ruby the Hard Way", I feel like I have had a really good model on how to do it where a natural progression can be shown and developed that is direct and terse where necessary, and also verbose and focused where also necessary. It also makes the point that to get it, you have to do it, and do it often, and do it in different contexts.

Still, I had that nagging feeling... what if I can't answer the tougher questions. What if I am limited my my own Peter Principle? How can I overcome that? The answer came as an email from a friend and collaborator. He excitedly emailed me and said "Hey, I know this is out of the blue, but how would you like to write a book?!" In his forward was the exact same proposal that I had received. I already know that the level of domain knowledge in this case for my friend is very high,and with that, my prayers were answered. Between us, we think we can do this justice.

And that's exactly what we proposed, that the two of us work on it together... and the reply back so far is a "yes". Note, this is very early in the process, and it's possible that any number of things could prevent this from happening, but I'm choosing not to dwell on that. Instead, I'm going to roll up my sleeves, work with my collaborator, and see if we can hit this one out of the park. Anyway, I can't wait to tell you what we have up our sleeves, but until we have something  notated and signed, y'all are just going to have to wait :).

Pulling the Trigger

One of the most terrifying things to do is to stare down a project or an idea that seems exciting, has a great potential, and the chance to grow and develop because of it is interesting and could really be a great growth opportunity. Yet we also often see these chances as dangerous and reckless. Are we up to it? Do we know enough to really do the topic justice? If we do, how do we know? If we don't, how do we know we are in over our head?

The reason I am asking these questions is that I have an intriguing offer. It is the possibility of writing a book for a publisher that I've done reviews for, and it covers a topic that I have some experience with, but don't consider myself an expert on the topic by any stretch. I could make many excuses as to why I could disqualify myself from doing the project... and yet, there's a part of me, that wannabe bold intrepid explorer, that has seen so many times that topics are only as mystical and mystifying as we make them out to be. Additionally, many topics are only as mystifying as the previous generation of authors that have written about them.

You will notice that I am being deliberately vague about this... that's because I don't believe in talking out of turn about things that may or may not come to pass. There's the "bold boast", and then there's shooting one's mouth off and making a fool out of one's self. Yet I've stepped back and looked back at my Book Club reviews for "How We Test Software at Microsoft", "How to Reduce the Cost of Software Testing" and the experiences of my Practicum posts for "Selenium 1.0" and "Learn Ruby the Hard Way". I've realized that I've learned way more about structuring these projects than I ever thought I could. Additionally, I've learned way more about the respective products and concepts than I ever thought I could, both the ways that things work as well as the irritating issues when things don't work as well as they should.

So this brings me to a fundamental question... does one wait until they are expertly knowledgeable about a topic before they plunge into writing about a specific topic, especially if it has to do with a particular product line or approach? Does the process of dissecting the topic at hand and digging into it to write about it in "layman's terms" make the difference between the casual practitioner and the expert?

I don't have the answer to these questions just yet, and truthfully, it's up to the publisher to decide if they feel I'm the dude to do this, or if I'm one of a number of contributors... or if they feel I'm worth working with at all for this. At the end of the day, all I can be do is be honest and show both my experience and my ignorance. I may not be an expert on the topic in question, but I know enough to know what frustrates people, and maybe, just maybe, that might be the most valuable thing that I can offer to see it through, because I truly would love to see a book on this particular topic be available... and really, that's all you are going to get out of me about it :).

I'll just have to see if, after an honest and truthful assessment of what I can really do, if they will be willing to entrust such a project to me. If they are, then, well, I guess I'll have to see if I'm man enough to pull the trigger at that point :).

Book Review: The Linux Command Line

What if you had a book that took you from the very beginning of the Linux command line options, and it took you through progressively interesting and relevant topics so that you really could develop a mastery of the shell? Oh, and what if it were written in a fun style that was less wonkish and easier to embrace and follow along with? Less tech, mode dude. William E. Shotts, Jr.'s “The Linux Command Line” manages to do that.


Let’s face it, learning the entirely of the Linux command line can take years. It’s unlikely most will walk through the book page by page and work through each example, but with this book, it feel like you could do exactly that and not get bored.

The first part of the book walks the user through the many commands that are relevant to all systems and all shells; the navigation options through directories, showing files, getting your head around terminals, finding and opening files, moving files and directories around, links (both literal and symbolic), learning about commands and how to learn more about them. All of this, as well as redirection, using pipelines, creating filters, expansions, and so on. A wonderful metaphor and explanation made in this section is that Windows is like a GameBoy, and Linux is like the world’s biggest Erector Set. While Windows is nice and shiny and makes for pretty applications, it’s difficult (relatively speaking) to roll your own applications without a fair bit of knowledge and packaged tools. Linux, on the other hand, right off the bat gives you all the tools you need to build just about anything in just about any conceivable way you might want to build it. 

Part 2 covers configuration of the shell and the environment variables that it keeps track of. Shell variables like DISPLAY, EDITOR, LANG, PS1, TERM and many others are explained and we get to see how simple shell scripts are implemented allow us to access and modify these values. We also get introduced to a variety of test editors, but with an emphasis on vi (and a mellow focus at that). The section is rounded out by learning how to modify the command prompt that we see and make it show us more details (directories, colors, etc.). 

Part 3 is a grab bag of all sorts of things that we often look at separately, but when taken together, make a lot of sense. We start with package management and making sure systems are up to date. Next we cover understanding file systems and the variety of commands that helps to mount disks, examine file systems, check and repair systems, get online and check the network for connectivity, copying files over a network and connecting via secure shell, performing archive and backup steps. The section end with a broad discussion on regular expressions, text formatting and processing and, finally, printing out files and compiling applications. 

Part 4 ties it all into the true big bad voodoo of the command line, the ability to write shell scripts. The section starts out with a fairly basic script formatting and then moves on to create a program that displays system information in HTML format. Along the way, we get to see how to use the shell and all of its properties and the huge toolkit of Linux commands to structure our work, and get an introduction to “top down design”. Subsequent chapters carry us through common development topics such as reading input from the command line, strings, numbers, variables and constants, and the variety of flow control ranging from simple branches to looping and case statements and arrays. The section ends with a grab bag of interesting topics including subshells, traps and error handling, asynchronous execution and named pipes.

Each section starts with the commands it will cover, walks through careful and thorough examples of each command, and then wraps with a simple explanation of the section covered, with sidebars aplenty. Seeing as this is a command line book, you bet that you are seeing a lot of the actual commands, and how they interact, how to apply permissions, manipulate text and manage processes. If you want practice with these things and not their graphical counterparts (and really, what “command line” book worth its salt wouldn’t make that its prime focus), well, you get your wish! 

Bottom Line: 

There are a lot of books that talk about the various Linux Shells, but you’d be hard pressed to find one that does so this entertainingly. Again, it’s the less tech (but not so much that the meat of the matter isn’t covered well) and more “dude” (but not to the point of being embarrassing or insulting) that makes this book a joy and a treasure. If you’re a novice Linux player, or just want to get beyond the pretty graphical wrapper of your MacBook, put this book at the top of your list.

The Watershed Moment

A couple of days ago, John Brownlee posted to the web site "Cult of Mac" what was an interesting picture. On the left, we see what cell phones looked like and were available prior to the development and the release of the iPhone. On the right, it shows what phones looked like after the iPhone was released.

Do you notice anything interesting? The first being that, in the first picture, there is a cacophony of different styles and formats for phones. Lots of different styles and features, many of which may be familiar to some and not so familiar to others. There is no question that many different varieties were to be seen and to be had. In the second picture, almost every phone looks as though it were styled and shaped like an iPhone.

What happened was that tech had a "watershed moment" with the release of the iPhone, and the rules of the game were changed. Yes, there were smart phones before, but no where near the sophistication of the iPhone at the time, and many other companies followed suit. The various Android phone manufacturers took many styling and design cues from the iPhone and made a system that was similar if not exactly the same. Even knock off phones not related to the iPhone or Android systems are following their design cues (I know, I have one).

In some ways, watershed moments are good, they show a definitive marker where things change, tastes align, and the world goes on a slightly different tangent than before. One needs just look at music to see similar examples through the years. Sinatra defined his era as clearly as Elvis defined his, The Beatles defined theirs and Led Zeppelin theirs. Add in Guns & Roses, Nirvana and later groups and you see what I mean. Oftentimes, those watershed moments obliterate all that has gone before... and frankly, that's a little bit sad.

As I've been thinking of testing these past couple of years, I've been able to look back and see some watershed moments as well. The ISO movement, and its brothers CMMI and Six Sigma. In the software world, the arrival of the record and playback tools, and perhaps today we could be seeing certification as a potential watershed moment in some places. My concern is not that these happen. If ideas are good and people embrace them, then there is nothing that's going to stop them and they will be adopted of their own accord. My fear is that much is being discarded that really shouldn't be. It's no secret that I consider the phrase "best practices" to be a terrible combination of words. I don't believe in them, but I do believe in various good practices that have their time and place. The danger with watershed moments is that they tend to sweep out many good practices because they no longer fit the fashionable "time and place" we are currently experiencing. 

In short, not everyone wants to move on from Elvis. Not everyone wants a big screen cell phone. And not everyone wants to have tools that make elaborate promises of "best practices" but don't really deliver. We want to be able to choose what works for us, whether they are fashionable or not.

Book Review: The Secrets of Consulting

First, I'm doing this in reverse order. I actually read "More Secrets of Consulting" almost a year ago, and from that experience, I decided to read some more of Jerry Weinberg's books (Weinberg on Writing, Perfect Software, etc.). Thus it's a roundabout way that brings me to the original "The Secrets of Consulting".


This is a book that every tester is encouraged to read. If anyone asks other testers or programmers about which Weinberg books to read, invariably "TSOC" gets mentioned. So what do we get if we follow up and check out this now classic title (if we use automobile standards, anything over 25 years old is "classic").


First, this book is a fun read, and it's a quirky book full of American idioms that will really only make sense if you've grown up in the US or have family that has told stories of the US from the 40's on through the 80s (when this book was written). The anecdotes may feel odd to people who didn't grow up in the America of that time period, but for those of us who have, much of these details feel right and their amusement factor helps us remember the concepts.


Weinberg gives names to many of his principles that are whimsical, and that whimsical quality helps make them memorable. There are many folksy stories included, and if you have read any of Jerry's books, this is a hallmark of his writing. For some, it may be off putting. For me, I find it endearing. Having had correspondence and communication with Jerry over the years, you recognize his voice and his demeanor in the prose, and it makes the stories very authentic. As such, principles like the Law of Raspberry Jam, the Orange Juice Rule, Rudy's Law of Rutabaga, Marvin's Great Secrets, etc. become easily recognizable and easily remembered. By themselves, these names are meaningless, but it's the memorable stories that help them come to mind and make them ring true for me.


Don't let the folksy qualities of the book fool you, there is a lot of very practical advice in this book, and while the stories may make you smile, maybe even laugh, or possibly shake your head, there is definitely a lot of real red meat in this book and letting it nourish you will indeed be worth your time. Some may complain that the advice is a little cynical in spots, or that they would never do the things that Jerry advocates, or that some of it comes across as unprofessional. To those people, I would suggest that they take themselves out of the equation for a minute, and examine human behavior. Jerry's examples and laws are not cynical, they are human, and they map to the way that people actually behave and interact with each other. Jerry's Laws are universal. The political, social, and behavioral problems we face tend to likewise be universal.


Most of all, this book is for every consultant out there, not just the ones that have that title tacked on their business cards and letterheads. When we get right down to it, every one of us is a consultant. We offer a service to our clients, and every law that Jerry espouses works just as well for us workaday employees as it does for official consultants. At some point in our careers each of us is going to need to be the bringer of news that others will not want to hear. How we deliver that news most effectively ultimately is up to us, but with these handy rules in mind, we can be more effective in sharing that news.


Bottom Line:

Don't think that because you are not an officially titled "Consultant" that this book will serve no purpose or have no value for you. In fact, I'd suggest everyone take a little piece of masking tape and cover up the word "Consulting" and write down "Dealing with Other People, Period". See, that way, when you reach for a copy of "the Secrets of Dealing with Other People, Period" then all of the story's, rules, limits, and laws will make much more sense, and their ready applicability to *everyone* can be better appreciated. I've seen many people say that this book is one they read over and over. I can certainly understand why.

Book Review: Head First HTML5 Programming

It’s a good bet that at some point your everyday tester is going to need to come face to face with the newest web standards, and if you have to get exposed to it from a books viewpoint, well, this is a friendly and straightforward way to do it. Head First HTML5 Programming uses a fun and graphically dense format to help get people comfortable with the ideas of using HTML5, CSS3 and Javascript.

OK, first and foremost, this is not an absolute beginner’s book, although you may well find that you don’t need all that much underlying understanding to be effective. If you have a basic understanding of HTML tags understand some CSS formatting and have seen and can recognize XHTML or XML, then you know enough to work through this book. This is also not a grans master’s book, either. It is not a comprehensive reference. What it does do is provide a basic framework and some fun text to help the user get familiar with HTML5 syntax and use JavaScript to help create web applications.

The book starts out with some basics, showing you how HTML5 is utilizing the standards of HTML, CSS and JavaScript as defaults, and the fact that many of the strict type details that were part of HTML 4.01 and XHTML are integrated.  Games such as crossword puzzles, word matches, sample programs and workbook projects are included to help get the gist of how to use recognize the changes and see them in action. Interviews with HTML5 and JavaScript are also included (no, I didn’t just make that up :) ).

The book then moves into JavaScript and explains the way JavaScript works, including a syntax run down, how to use it in simple programs, as well as how to put the scripts into web pages, and explains the Document Object Model (DOM) that is created and used to enact your JavaScript.

Creating event handlers and interactive controls to a user is up next. By making a simple song selector, the user is shown how to make buttons and tie events to them, , along with creating new elements to hold information and display songs. The exercises help the user see how the code and page elements interact with each other.

Functions and objects are next on the list. Chaining, constructors, and scope, oh my.

Geolocation gets a chapter, meaning that we can make our pages and our code pieces  location aware (by using the Geolocation JavaScript API). This can be done at a GPS level or an IP address level, but in both cases, this chapter covers ways to say where you actually are.

Web Services gets a chapter and a look at XMLHttpRequest, JSON, and JSONP, and shows when to use which, and how to fetch data at regular intervals to update the application you make (and with gumballs, no less).

The Canvas chapter explains how to use the canvas element to physically draw out parts of the page. With a T-shirt design problem, we create a square, manipulate the pixels to create fills, fail gracefully and inform users if their browsers are too old to support canvas, and create functions to draw circles and other shapes. Creative text can be displayed as well.

The Video tool allows developers to not just embed video in pages, there’s also playback, moving forward and backwards, handling different video formats, and embedding video images into objects that you have drawn onto the canvas tool. We also get to play with a variety of video formats including H.264, VP8 and Theora. Video also allows the user to use an API to focus on a variety of behavior.

Web storage, or more commonly, localStorage, gets coverage and an explanation of how it differs from traditional “cookies”. Starting with the space (cookies max out at 4kB, localStorage gives you 5MB for each domain).

The book rounds out with the topic of Web Helpers, the ability to spawn small JavaScript threads to take over the lengthier or more involved processes, so that the browser doesn’t wait forever for that particular process to finish (with an explanation of an exploration of Mandelbrot Sets just for fun).

There are also a number of topics that didn’t get covered, such as Modernizr, Audio, jQuery, XHTML, SVG, Offline Web Apps, Web Sockets, more advanced Canvas API, Selectors API, and many other things that would make a book already 600 pages much thicker (especially since most pages are graphically structured with examples, puzzles and a lot of pictures).


Bottom Line: 


It’s cutesey, it’s kitschy, it’s loaded with pictures, diagrams, and other stuff that may drive some people crazy (the “get to the point already” people), and I’d say that, for those people, they are probably already knowledgable enough to go beyond what this book offers anyway. If, however, you are like me, and don’t necessarily mind a variety of presentation options, and the “ooh shiny” quotient is high, and the need to have silly asides and corny jokes abound to keep you smiling, and engaged, then I have to say there’s a lot to like here.

Exploring Black Box Machines

On Saturday, I had the chance to step back and be a participant again for Weekend Testing. Albert developed and ran the session this time, and frankly, I think it was one of the best ones we've had.

This session was called "Black Box Machine", and it was based around, you guessed it, testing a truly black box device. We really didn't have any idea what we had or what it did. It was a screen with a gauge, a red LED, a green LED, 4 blue buttons and 4 yellow buttons. Click on the experience report link above to see the machine layout we used.

The buttons were functional, and combinations of the buttons controlled the lights and the gauge.

I had a chance to work with and discuss the approach with Russ Poole, a newcomer to Weekend Testing. Often, we split into pairs for these sessions to do the actual testing, with an experienced Weekend tester working with someone who is new to the format, or a more experienced tester working with a less experienced tester. We took some time to acquaint ourselves with the machine and worked through the buttons to see what they did. Through exploration, trial and error and questioning, we made a mental model of what the device might be. We knew the mental model might be wrong, but it was useful for a time to help us describe what we were seeing, and use a common language between us. With this approach, we were able to divide and conquer the problem and determine what the machine did. Well, determine what we thought the machine did.

Each of the testers or pairs of testers did the same thing in the time frame we provided, and each group or individual presented their approach. It was interesting to see that each pair had a slightly different method to their testing and their vision of the problem. Each of us used heuristics to help us define the problem, and to come to some conclusions. I explained to Russ that our mental model may be correct, or it may not be. Still, as long as we kept learning about the product and could try out our ideas, we were able to determine at least on the surface what we thought the machine was doing.

This exercise is built on a number of examples that James Lyndsay developed, the entire purpose of these "machines" being to help people understand exploratory testing in a way that may get lost when working with known products. With everyday well known software applications, we can use some markers and guidelines to help us, and those familiar items and ideas will naturally guide how we test. Tthese machines are void of any natural context, and as such, we are basically left to our own deductive and inductive reasoning to figure out what's going on.

Again, I think this was a fantastic session. My thanks to Albert Gareev for facilitating it, and my thanks to all of the participants for taking the time to come out and play with us on Saturday.

Online Summit: Agile Transitions

It looks like 2012 is shaping up to be a series of first for me. to that column I can now add "will present to an online forum a webinar/talk". How and when will I be doing that, you say?


I will be presenting at the SoftwareTestPro Online Summit for "Agile Transitions".


I've had to go through my own "cultural shift" the past year as I've made my transition away from being a software tester in a traditional testing organization to being a tester embedded into an Agile team. My goal is to share some of my own experiences, pitfalls, adjustments and lessons learned, as well as to offer some tips specifically for Lone Testers who are finding themselves embedded in Agile teams, or interested in making the transition.

The Online Summit will be held from Tuesday February 21 10:00AM until  Thursday February 23 1:30PM PST (each of the summit times will be three hours during that time period). The schedule is listed below (at least the schedule as it stands right now). My session is highlighted :).

The cost of the summit is $195USD if you sign up before 2/14/12, it will be $245USD after that.


Scott Barber will be hosting this online summit, and he has gathered a number of different speakers to present on various topics. I will be speaking on the topic of being a Lone Tester making the transition to Agile.

The cool thing about this approach... you don't have to travel. Depending on your work arrangements, you may not even have to block out any specific time. These courses are each about an hour long and only cover three hours each day. The audio and video from each session will be recorded. If you miss a session, you will have access to all of the session recordings once the summit has ended.


The schedule as it currently stands is a follows:

Tuesday February 21, 2012

10:00- 10:10 AM PT Welcome, Overview and Agenda

10:15-11:15 AM PT What is Agile and What's it Got to do With Testing?
– Scott Barber

11:10-11:20 AM PT Break

11:25-12:25 PM PT How "Agilists" vs. "Traditionalists" View Testing
– Robert Walsh

12:20-12:30 PM PT Break

12:30-1:30 PM PT Keys to Transitioning to Agile Testing: Lessons Learned from the Trenches
– Bob Galen


Wednesday February 22, 2012

10:00- 10:05 AM PT Day 2 Welcome and Agenda

10:05-11:05 AM PT The Secret to Successful Agile Test Automation
– Lisa Crispin

11:05-11:15 AM PT Break

11:15-12:15 PM PT Culture & Inter-Focus Area Interactions
– Selena Delesie

12:15-12:25 PM PT Break

12:25-1:25 PM PT Avoiding Agile Perversion
– Lanette Creamer

1:25-1:30 PM PT
 Day 2 Summary and Closing Thoughts


Thursday February 23, 2012

10:00- 10:05 AM PT Day 3 Welcome and Agenda

10:05-11:05 AM PT Excelling as an Agile Tester
– Henrik Andersson

11:05-11:15 AM PT Break

11:15-12:15 PM PT      The Lone Tester in an Agile World
– Michael Larsen

12:15-12:25 PM PT Break

12:25-1:25 PM PT 10 Tips for Agile Transitions & Panel Discussion
– Scott Barber & Panel

1:25-1:30 PM PT
 Day 3 Summary and Closing Thoughts


 Here's hoping I will see some of you there :).