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 :).