Elisabeth Hendrickson raised a point on her blog on test automation. She raises a very good point on the time-value of information. She states that just as money today is more worth than money tomorrow, information known today is more valueable than knowing the same thing tomorrow. Agile practices such as Fail Fast and iterative development enable teams to know more informations when making a decision. This is also true for (A)TDD of course.
While reading through the comments of Elisabeth’s blog entry, I noticed James Bach’s thoughts on it and felt to have to respond on it immediately. One thing I realised lately is, that there seems to be a discussion about whether to automate testing or not on-going between testers from the Agile school of testing and the context-driven testing school. Personally while trying to answer Bret Pettichord’s question whether I have to pick a school of testing or not, I feel, that both schools are right to some degree. This does not mean, that they are wrong to some other degree, of course. The point here is, that this is no well-structured problem – you’re faced with well-structured problems in elementary school. Software and by then software testing as well is an ill-structured problem of our adult world. There is no test automation is always right or sapient testing is always right out there.
Despite thinking in just two categories, I encourage to think of test automation and manual testing as a symbiosis. You can do a lot more manual testing, if you have covered those tedious to repeat tests with automation. On the other hand you can more easily automate software testing, if the software is built for automation support. This means low coupling of classes, high cohesion, easy to realize dependency injections and an entry point behind the GUI. Of course by then you will have to test the GUI manually, but you won’t need to exercise every test through the slow GUI with the complete database as backend. There are ways to speed yourself up. If you’re lucky, they are open for you – this seems to be the case on most Agile developed projects. If you’re not lucky, you have to find ways where scripting or automation can speed up your tedious manual test cases. But having both in place together is the best choice you can take from my point of view.
Markus, I agree with your post. I don’t think there is any one way to do things. We have a set of tools in our toolbox and we need to learn when to use them (know your context). There is not a one size fits all, although without automation, an agile team would have a hard time keeping up with the testing effort. At the very least, a good suite of automated unit tests is necessary.