Where Do the Testers Go in Agile?

Hacker News LinkedIn Facebook Twitter by Abby Fichtner

Rumpelstiltskin While I love to write, I occasionally prefer the role of reviewer or editor. I find it a nice break to sit on the other side and evaluate someone else’s work for a change. How much more comfortable to critique someone else’s product then to summon the courage to create something myself!

But how much easier would it be to create if we had a magical safety-net that guaranteed whatever we did would turn out well? How much more would we accomplish if we knew our every endeavor would be a success? Imagine a kick ass editor or, in software, a fabulous tester who had our back. Let’s call them Rumpelstiltskin. Able to take Garbage In, and turn Greatness Out.

We might find that the tables had turned. That the need for courage had passed from the creator to the tester. We only have to give them straw. They have to find a way to turn it to gold.

I have seen this happen on software projects, where the senior developers’ time has been deemed too valuable to “waste” on bug fixes. Have you seen this? A team of developers up in their ivory tower, banging out new features, while a test and bug team come in to clean up behind them. All so the senior folks can go work on the next big thing.

I just can’t imagine this situation is satisfactory for anyone involved. Not for the senior developers because we ask them to invest all that hard work but then deprive them the satisfaction of a job well done by forcing them to stop short of learning whether they got it right or allowing them to sculpt it into the final solution. Not for the testers or bug team, because they’re left with the onus of getting it right, while the senior developers get all of the credit.

Even when the developers are writing unit tests to ensure their code “works,” so many of the problems we find in software are communication, rather than technical, issues. And the further we remove developers from the process of validating whether their software does what the customer really wants, the more the problem gets compounded.

In agile, we seek a better answer with our notion of All Together. One where we all require courage, but where finding that courage is made easier by the safety nets we put in place. If testers are really good at working with completed software to The Seven Dwarfsensure it meets the customers needs, why not just allow them to do this throughout? Let’s skip the separate bug team and it’s test/fix cycle and just get it right the first time.

Testers can work with customers up front, before a feature has been developed. They can dig beyond the stated requirement to learn what it will take for the feature to actually be usable. The criteria by which users will judge it. In the end, success is defined by the software’s usefulness to the user, not by its adherence to documents. And so if testers are going to have to figure out how to validate that it meets those user needs, why not figure that out up front – and allow that knowledge to help drive development in the right direction?

The truth is, it’s a waste of testers’ skills and an exercise in frustration to leave them until the end – trying to inject quality into something that’s already built.

In the beginning…

So, agile puts testers at the beginning. It gets them involved with the customer, helping elicit acceptance criteria in terms of objective tests. And sharing these with developers so they can design the right solution to build from the start.

The middle

And it puts testers in the middle. We talk a lot about having developers testing their own code. Well good! As developers, we should be able to test our own code. But the truth is, most developers haven’t been trained in testing and so figuring out what to test can sometimes be daunting. Why not let testers sit down and pair with us while we’re writing some of our tests? Give us a second set of eyes and help us find techniques for writing effective tests as simply as possible.

At the end

And it put testers at the end. Not the end of a release, but the end of a feature. As we integrate our new features, testers provide us with their wonderful safety net of tests to ensure that our software continues working as expected. And since most defects will have been prevented or dealt with by this point, it allows testers to look further. To inspect the software and feed ideas for improvement back into the process we use as we move on to the next feature.

I know that for a long time our industry has believed that to be effective, tests must be independent. But in agile, we value the customer’s opinion as the final say, not some techie’s. So lets allow our testers to instead work with the team and help us move forward with the confidence of knowing that it is within our ability to deliver success.

Where does your project put its testers?

» See Agile Testing by Lisa Crispin and Janet Gregory for more information and wonderful ideas on testing in agile.

  • Preach it girl! I have been trying *so* hard to get these same exact ideas across to my development team for 4 months, to NO AVAIL. I even gave a presentation to our executive staff about how you “can’t test quality into software” (see my blog for the ppt, I made it generic and available). My dev manager actually told me “I see no value in having a tester involved early; in fact, it will just be a distraction to the developer.” Even my “try it for a short period of time, what are you risking?” was met with a firm NO WAY.

    When you answer how to get it to happen, please let me know.

    I’ve got a blog post upcoming about at what point you have to determine that you are not going to be able to convince your team that these things are worthwhile. I have spent 4 months being held back, treated like a second-class citizen, prevented from doing my job, being used as someone to blame when customers have issues, and feeling worthless. I’ve given up, and have decided that I would rather be somewhere I can add value.

  • Abby Fichtner

    Linda! Thanks so much for stopping by and for the awesome attitude on agile. Very interesting to think of how agile impacts roles we may not think of as often like tech writers. But now that you mention it, combining tech writing with usability testing seems almost an obvious (duh) fit, very cool!

  • I agree too!Excellent topic. As a Technical Writer who has done waterfall for over 20 years, and agile for only one year, I LOVE agile! The documentation usually is worked on about the same time as testing — at the end, right before the product goes out — and that is TOO late. Agile makes the developers accountable for the info that goes in the docs in an ongoing process and that helps me greatly. I also do usability testing with the customers. Using agile, when that testing is part of the process, we can report back the results of the usability tests to make the product better — early on, while there is still time to make changes.

    I have worked with writers and developers who have quit their jobs because they hate agile — I just can’t understand that…

  • Well written. I totally agree that testers should be involved through the whole process, but wouldn’t want to tie that principle to Agile (although that’s a topic for a much longer post).

  • If we consider development to be a constraint, then the concept of putting quality control in front of it aligns with the Theory of Constraints. (ToC) Well written!

    Check out my PMBOK, Agile & TOC series of posts at: http://www.chadalbrecht.com/

  • Anonymous

    We have “testers” all thorugh-out the process in our development projects, we just don’t label all of them as testers. (Lables are translated to english)

    The ones labeled testers are the guys doing low level software verification. They test that the function 2plus2() actually returns 4 or that UTF8 arabic letters print correctly on the output graphics, but makes no judgement whether that function is useful to the customer.

    We have another group called project technical leads (not a manager) which are responsible for making sure that the software is useful to the customer. This means working together with business “experts” and the customer through-out the project to understand the requirements and communicate with developers and managers to validate that what we are building is the right thing.

    The second group is a much more demanding job and requires quite different skills than the first. The consequences are also a LOT bigger if they fail or do a bad job. Bugs are relatively cheap to fix compared to a software solution that the customer is only partly satisfied with.

  • Passed this on to a second client also today. It’s one of those posts that I reckon I’ll be referencing frequently. Feedback will come to you as I receive it. And I wrote something about testing myself yesterday — http://bit.ly/OJGOQ

  • Abby Fichtner

    I was soo worried that 1st paragraph would be taken as snobby but, I think the truth is sometimes we’re so in our own little world that it feels like we’re doing all the work while we’re really just leaving a pile of, erm, straw :) for others to have to make something out of.

    And it’s no wonder when we pull testing out into its own separate phase and separate team that we can’t ever even see that anything we did could have been wrong… how can we learn anything that way?

    Good luck to your client! Would so love to hear their thoughts on this and if they see any way that agile can help.

  • Excellent post. I like that “straw into gold” metaphor for the way traditional testing works. I shall share this post immediately with a client of mine who has much QA-pain (see, they even use the term “QA”).

  • Abby Fichtner

    Thank you both so much. I just got back from facilitating a round table on the topic at our local SPIN chapter and was impressed by the positive response – that people clearly get the benefit to having testers involved throughout.

    So now the question is simply…. how do we get this to actually start happening? :-)

  • As always, a great post Abby. We (to our detriment) put testing at the very end.

    I liked this bit: “In the end, success is defined by the software’s usefulness to the user, not by its adherence to documents.” It’s one of those things we don’t quite understand around here.

  • I completely and totally agree! Couldn’t have said it better! :)