Re: Diminishing ROI with NO Automation in Agile development
- Perhaps I work in a different type of IT shop than the typical developer, but I'm really astonished that in 2010 someone can suggest that we can live without automated tests. (The comment is not directed at you, Don.)
Our system consists of over 2 million lines of code. A single test plan for a single complex feature takes ~70 pages to print, given that there are hundreds of variations.
If you printed the entire set of tests (single sided), it would be over 6 feet tall. I know, we did it once for fun, and to provide a important visual clue. :-)
Before we automated the vast majority of the tests, it would take over a month to manually execute the test suite.
Now, how on earth can someone suggest that they're doing agile development, delivering working software every few weeks, when the execution of manual tests alone would account for weeks of time?
On top of that, the vast majority of (regression) tests do not fail when they're run each the end of each iteration. What a colossal waste of time it would be to have your talented team poking away at the system, when they could be adding value elsewhere.
--- In firstname.lastname@example.org, "Don MacIntyre" <don@...> wrote:
> I describe the need for the adoption of automated testing and other XP practices to new Scrum teams something like this...
> If you don't adopt the practices that are best suited for iterative development, you may experience an initial burst in productivity, but you will likely soon discover that you are just building crap faster than you were before.
> I feel that continuous integration and automated testing are necessary for iterative development.
> You can do typical unit testing and have your CI system kick off other automated suites (we currently use selenium) but the biggest bang for the buck is Test Driven Development.
> My current teams have been slow to totally embrace TDD, so I'm making a real push now with weekly how-to sessions. One of the guys will also spend the next 3 days at Ron and Chet's Agile Skills class. Hopefully that will be enough to drive it home. ;)
> --- In email@example.com, Ron Jeffries <ronjeffries@> wrote:
> > Hello, Adam. On Monday, October 4, 2010, at 2:46:42 PM, you wrote:
> > >> It does
> > >> mean, however, that if a team is new to automated testing, almost
> > >> every test they are not doing probably should be automated, because
> > >> they will be so far behind that they are likely not doing very much
> > >> really good testing.
> > >>
> > > I had to read this sentence several times to make sure I parsed it
> > > correctly. I'll say what I think you mean, and then you can correct me
> > > ;-)
> > > I think you are saying that any test that is not being done manually
> > > should be automated, because otherwise there will be too many tests
> > > that are not getting done. Is that right?
> > Let me try.
> > If your team is new to automated testing, it is likely that most
> > every test you are now doing should be automated. The reason is that
> > if you are testing manually, you are probably doing very few tests
> > that only a human can do.
> > So my advice would be to err on the side of over-automating for a
> > while.
> > Ron Jeffries
> > www.XProgramming.com
> > www.xprogramming.com/blog
> > [S]oftware engineering ... "How to program if you cannot." -- Edsger Dijkstra