Friday, September 2, 2011

Thoughts on Agile & Agile Testing

This past weekend, I finally made time to start reading Agile Testing: A Practical Guide For Testers And Agile Teams, Lisa Crispin & Janet Gregory, Addison-Wesley (2009).  I made it through the first two chapters before life called me away.  After I put the book down and starting going about accomplishing a mundane series of errands, I realized that I was feeling disappointed and that the disappointment had started growing just a few pages into the book.  Not because of what the book had to say, what it said was pretty good – not exactly how I would have expressed a few things, but thus is the plight of a writer reading what someone else has written on a topic they also care and write about.  What was disappointing me was the fact that the stuff in those chapters needed to be said at all.

You see, as Lisa and Janet were describing what Agile Testing and Testing on Agile Teams was all about, and explaining how it is “different” than “traditional testing”, my first thought was:

Boy was I ever fortunate to start out my career in software in the company I did.  I don’t think I’d have made it 3 months in one of these ‘traditional’ environments.
My second thought was:
What earned this stuff ‘traditional’ as an identifier anyway?  That’s certainly not how I learned to think about testing, but I guess there’s nothing to be done about the fact that before my time, some person or people, decided that software testing was fundamentally different from anything else I’ve ever encountered that was called testing.
My third thought was:
No wonder I could never figure out what the big deal about testing and Agile was… it’s because this thing, apparently called Agile Testing, is exactly what I thought software testing was before I ever worked on a software project.
Pondering those thoughts while running errands, I realized what was making me feel disappointed.

I found myself disappointed with the entire field of testing -- every person, organization, and software or business related field that enabled or allowed software testing to get to such a state that those two chapters should be classified as a “must read” for everyone who has anything to do with testing software, directly or indirectly, before being permitted onto their first software project.  At least coming from the background I did, it seems entirely baffling that these two chapters are describing some kind of nirvana that most testers and teams either aspire to or fear instead of these two chapters representing the givens, the lowest acceptable bar to entry, ya’know, all the stuff that while you’re reading, you keep thinking “Duh.  Stop wasting my time telling me all the stuff everyone already knows and get to the good stuff!”

I found myself disappointed that after all the hours and years that so many people have dedicated to making software testing a respected and reputable career, the vast majority of testers and organizations, for reasons that aren’t their fault, at least not entirely, haven’t even made it *up* to what I’d consider “ground-zero”.

Honestly, how messed up must software development have been for a group of some of the most respected and influential people in the field to feel the need to get together and collectively remind us that (to paraphrase the Agile Manifesto):
  • People, collaboratively, solve problems.  Processes and tools will never solve a problem without people.
  • No matter how well we document what we’re trying to do, it’s pointless if we don’t actually do it.
  • No contract will ever make a customer find value in a product.
  • “Stuff” happens, and if we don’t deal with it, we might complete our product cheaper or sooner, but it will be the wrong product and no one is going to want it.
And how messed up have we remained that for the subsequent decade the entire movement that claims the same name as these self-evident truths, has been rejected, debated, and wildly misapplied?

Isn’t it about time that we get over our hang-ups and start simply doing the right thing?  Have we become so caught up in the things we’ve seen misapplied that we’re willing to “throw out the baby with the bathwater”?  Is the entire software development industry so broken that testers feel they need these “traditional” approaches to protect the business, the users, and themselves from evil?  Or has the term “Agile” simply become so overloaded because of a decade of people misapplying the principles and misusing the term that we need to start over again with a new term?  If that’s the case, why don’t we just say that the process of developing software should be:
  • Mission focused – meaning that if we’re not delivering working software that serves the purpose for which it was created, what *are* we doing?
  • Accomplished in manageable units – 7 year, strict waterfall, development projects simply don’t work.  You figure out what a manageable unit is *this* time, and *next* time too.
  • Collaborative across the entire team – testers included
  • Value to Cost appropriate
  • Able to react to change
  • Reliable
  • Sustainable
Call it MACVARS, agree to avoid all the “I’m gonna rebrand my old stuff as ‘Agile’ to improve its search engine rankings… whether it’s actually ‘Agile’ or not” crap, and get on with doing the right thing.

If that’s not the case, I wish someone could enlighten me as to what the all the debate and rejection of collaborating to deliver products that serve their desired purpose without running up expenses by doing lots of not-so-value-adding stuff is all about, ‘cause I don’t get it.
 
--
Scott Barber
Chief Technologist, PerfTestPlus, Inc.
About.me

Co-Author, Performance Testing Guidance for Web Applications
Author, Web Load Testing for Dummies
Contributing Author, Beautiful Testing, and How To Reduce the Cost of Testing

"If you can see it in your mind...
     you will find it in your life."

2 comments:

Mark Tomlinson said...

Scott, my friend, I have had a different experience.

I actually found that my experiences testing in the beginning, using waterfall/SDLC type methodologies was actually more respectful of the people doing the development and testing than the new "agile" methods.
Here's 3 reasons why:

1 - the contemporary understanding of the agile manifesto equates "traditional" methods with incompatible of the agile manifesto. That's just not true in my experience, but perhaps the guys that wrote the agile manifesto were making a political statement in rebellion against BAD waterfall or SDLC practices. As you state, perhaps they threw the whole thing out the door accidentally.

2. Developers aren't having a better time or more successful using agile - any more than before. Since they sort of left out testing (assuming it wasn't that hard), I saw many developers struggling to learn how to replace their testing teams. They struggled. They failed. They pushed bugs into Operations. They got pulled out of development and into operations to fix bugs full time. We used to prevent that by doing testing.

3. The agile testers I do speak with are being forced to become developers (with tools and profiling code) and they are prevented more and more from practicing good testing/critical thinking and analysis of the greater context for the effort. Being a good tester in agile should not mean you are just an entry-level developer.

That's just my opinion. I could be wrong.

Scott Barber said...

Never be sorry for sharing an experience. We all have experiences and they are not right or wrong, they simply are. And they *are* part of how we view & interact with the world.

So, I start with a positive view of "agile" because the manifesto (not the marketing usurped terminology for decidedly "non-manifesto-compliant" practices) embodies what "we" were having success with.

Since then, I've had many, shall we say, less positive experiences -- and in each case I've had to ask myself "What is this thing that's going on here, 'cause calling it Agile don't make it so."

So, I think our points are really pretty similar -- which boil down to "If there weren't so many people doing such a bad job of embracing principles, in favor of embracing unvalidated marketing crap, there would probably be no need for the book. And there would *certainly* be no need for the first two chapters!"

Which is why I'm disappointed in the first place. Agile is something I *know* can be good, but it often isn't because far too many folks with far too many marketing dollars have have sacrificed the beauty and elegance for the rest of us in pursuit of the almighty dollar. That disappoints me greatly.