Comment:     by Don Mills 4/6/2005 Good article, Johanna, and I have only one quibble (which has gotta be good for a tester). You wrote, "On an ideal agile project ...", which suggests that not all agile projects are "ideal". Converely, I could write, "On an ideal waterfall project ...". The majority of my major customers (government, banks, finance houses, etc.) are still committed to waterfall for core systems. Some of them, at least partly due to my personal influence in consulting and training, now use the V- (or W-) model, practising what I've called for twelve years now, "test-first development". In "TFD" projects,...Read On Author's Response: 4/6/2005     Don, I agree with you, that many of us who have been working on projects for 20+ years use techniques that work. Many of those are also considered Agile techniques :-) I bet you also use continuous integration, although you didn't say so in your comment. Thanks for reading.
	Comment:     by Denis Yurkin 5/14/2004 "If you've ever been on a project that tried to improve performance or reliability late in the project, you know how difficult late improvements are." Johanna, do you mean agile projects here? How does this correspond to these two? http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast http://c2.com/cgi/wiki?RulesOfOptimization Author's Response: 4/6/2005     Denis, I meant that on projects where we had attempted to do BDUF (Big Design Up Front), changing performance or reliability by orders of magnitude is close to impossible. Contrast that with Agile projects, where you constantly check performance or reliability (whatever is important to you) as you proceed, modifying the design as you go.
	Comment:     by Lisa Crispin 11/20/2003 Hi Johanna, great column! This is a great explanation of the role testers play on agile teams. I would add that testers who don't have a programming or test automation background shouldn't be discouraged from joining an agile team. I have talked to several people who made valuable contributions as testers on XP and other agile teams, but the programmers on the team did all the test automation. Working on an agile team that uses the pair programming practice is a great way to develop test automation skills. There are many other ways testers add value, though. Even if the tester is skilled at automation, she's likely to need support...Read On Author's Response: 11/21/2003     Lisa, thank you. You're right about testing skills vs. programming skills. As long as testers understand how to test using various test techniques, they don't need the programming skills, as long as someone else can provide those skills. You make a great point about design for testability. To me, the positions on agile teams become quite blurry (who's a developer? who's a tester? who's a project manager?) because of the need for self management and the insistence on delivering value from every piece of work every day.
	Comment:     by Anko Tijman 11/20/2003 Thank you Johanna for this supporting article! Next month I will be presenting at Eurostar, introducing testers to agile software development, such as Extreme Programming, Scrum and Crystal. It is very nice and good to hear that so many of the well known "testguru's" embrace agile development. I think it's a major breakthrough in software development for delivering quality software on time to the customer. Gone are the techies that make decisions for the customer, it's all about business value. Thanks again! Anko Tijman Author's Response: 11/21/2003     Anko, thank you. The more of us who write (and practice!) agile development, the clearer it will be for everyone to understand how to do it. The more technical and schedule risk in the project, the more agile practices make sense, so that the project can deliver value.
	Comment:     by Sandy Frazier 11/18/2003 Hi Johanna, I really enjoyed your article. It helped me to understand what Agile Testing means. My question is in relation to analysis. After reading your article it sounds like with Agile Testing the only analysis takes place between the Tester and Customer. Is there any other resources involved with this (other than possibly the developer to let them know if there is a system limitation)? Also if you try to reduce the documentation on a system by using the Agile Testing method, do you feel that over time, as resources move from system to system, you will also lose knowledge of important processing that may be taking place? Author's Response: 11/18/2003     Sandy, woops, I left you with the wrong impression. The customer works with the testers *and the developers* to discuss (analyze) the requirements. But the customer (in my experience, the testers) write the user acceptance tests, which more completely define the requirements. System limitations are usually described more in this form: "it will cost us x person-hours to accomplish this task. Do you still want it?" (Because almost everything is do-able, it's a question of how long and how many people it will cost.) People are not supposed to move off agile projects (although there is almost always some sort of normal turnover). If you move people off a project before its last iteration, yes, you absolutely lose system domain expertise. But you lose that when you move people off a traditionally planned and organized project too. Maybe you've been on a project where the developers and testers have maintained the project documentation, but I can honestly say that in the last 25+ years, I've only been on one project where people did maintain the project documentation, where it wasn't required by some regulation. Since people are --in general-- not good at maintaining design documentation and choices documentation, the agile methods require conversation among the team so that the team understands what choices were made and why. To me, that's better than one person having a conversation with himself and the rest of the people being left out in the cold :-)
	Comment:     by Joshua Barnes 11/17/2003 Johanna, I would like to inquire about the sentence "The customer ranks the user stories (1,2,3,4, and so on) to determine which user stories the project team will approach in this iteration". Customer priority is a huge part of planning an iteration, but I feel that it is an input to the prioritization of the use cases (or stories in agile speak) that the software architect does. Meeting the customer's needs is what we are all here for, however, the customer generally knows very little (nothing) about architecture (as it should be) which drives much of software development risk. Were you working from more of a construction stand...Read On Author's Response: 11/17/2003     Joshua, in agile projects, each user story is assigned an estimate of how long it will take to implement (the cost). If the customer wants features now at the expense of the architecture later, the team explains that the cost to insert that other feature later will increase. The customer has the choice: pay less now for the user story that helps the architecture development or pay more later. It's always the customer's choice. The one thing that's not the customer's choice is refactoring. Refactoring is mandatory during each iteration, so that the project does not incur technical debt. This has multiple positive side benefits: the architecture emerges according to the most important customer-requested user stories, and the customer always sees how expensive (or not) each user story is. (A user story is a few words, and is really a promise to discuss the user story, not a use case). In my experience, many projects make (too-)early architecture decisions that don't actually meet the needs the customer has once the project is closer to complete. This technique helps the customer understand the problems and costs of not knowing their requirements at the beginning *and* this technique doesn't unduly penalize the customer for not knowing. Yes, it's more expensive to add architecture-changing things later, but almost all the projects I've been on do that anyway. This techniques makes it more obvious.

Back to Top