Getting testers involved early has been a goal of traditional teams for decades. Eliminating waste, automating tests and focusing on the customer are concepts that can be adopted by any team. So what makes agile testing different?
SearchSoftwareQuality.com invited two veteran software testers, Matt Heusser and Lanette Creamer, to answer that question. In this conversation, they debate which side created test-driven development (TDD) and whether TDD processes differ in waterfall and agile testing.
Before we get started, meet Heusser and Creamer, who truly come from two different testing worlds.
- As a lead tester at Adobe Systems, Creamer has worked primarily on traditional, mature software teams that regularly release complex integrated software packages every 18 36 months until recently. She joined her first agile team about a month ago.
- Heusser, a boutique tester and software process naturalist, specializes in testing in fluid, high personal-responsibility environments undergoing rapid change. His SearchSoftwareQuality.com tips series on ways to speed up software testing in agile development, spurred this debate.
So, let's listen in as two testing veterans discuss the finer points of testing.
Creamer: Matt, I read your previous article on
Requires Free Membership to View
accelerating
agile testing, and I can't help but think that eliminating waste, adding automation to our
process and getting code quality earlier in the process are all things not specific to agile and
should be a part of any software process. How can agile claim these under its umbrella?
Heusser:Did I write that? I thought my idea was to make agile development possible, and to do that, we had to compress the test effort. So I proposed a list of ideas to compress testing. Lots of people want to compress testing, even you 'evil' traditionalists. So it doesn't surprise me that a traditional company, especially a high functioning one, would already be using some of them.
But I grant your point that agile testing can reasonably be expected to have a different 'slant' on the issues. Shall we take them one at a time?
Test-driven development not just for agile
Creamer: Let's start with getting code quality earlier. For years now, we've been hearing that Test-Driven Development (TDD) is its own thing. Is there some difference between agile TDD and non-agile TDD?
Heusser: I believe that TDD is a practice that grew out of the agile literature, and its original purpose was to enable refactoring or changing the low level design of the code. TDD has evolved to have a purpose more of test-driven design; enabling emergent design, as opposed to document driven design. So I think it's fair to call TDD an agile practice, even if it can be applied by traditional shops. Do you disagree?
Creamer: I agree that it can be used in this way, but I thought that TDD was also put in place to avoid early mistakes and prevent scrapping the work done so far to start over later in the process.
We have been using TDD to validate that we are meeting the stakeholder requirements earlier during development. When working on a new software project it is far easier to refactor without causing major pain to other teams, but when you are talking about numerous core technologies and over 15 products interacting and relying on each other to deliver one consistent end user experience, what could be a minor change for one team can cause serious problems downstream.
In our context, very few teams are an island, and there are more stakeholders to please. Our situation makes refactoring more risky and early problem notification more attractive. It could be that we are using the same exact method, but for different goals.
Heusser:When I hear 'test driven development', I think about code; at a low level only technologists can understand. I'm curious how you mean you're using TDD to validate the stakeholders' plain/English requirements. It's probably just a terminology thing. I'd be likely to call that Acceptance Test Driven Development (ATDD). If you're using ATDD to get over a dozen development teams on the same page with standard interfaces, well, more power to you.
It sounds like we're using the same tool, but you're doing it to control change -- with good reason! -- and agile teams use TDD to enable change. So I see a subtle distinction.
Creamer: As much as we'd like to adapt to change, we require some amount of cohesiveness to be able to coordinate integration across products. We are controlling changes with multiple methods, including using acceptance test. I believe that some teams are also using TDD in the sense you mention, in the code, before most of our testers see it. Those teams are mainly the teams who have started using agile, so that is a useful distinction.
 |
||||
|
|
|||
|
||||
This was first published in October 2009
Join the conversationComment
Share
Comments
Results
Contribute to the conversation