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.”
Recent Comments