First a couple of clarifying definitions:
I also remember that there was a buzz in the small XP community of the time that we wouldn't need testers anymore because our microtests would solve world hunger, cure cancer and probably fix the southern hemisphere ozone hole as a nice side effect.
Prior to joining the project where I learned about XP, I had the privilege of working with some really, really good testers who worked directly with me - we paired without knowing that it was called pairing. :) Those people helped me to think much more critically about what I was coding, and that translated directly to much better quality from my code. Adding the automation aspect of frameworks such as JUnit only served to improve that further. However, it wasn't enough!
It didn't matter how well I (or anyone I worked with) had tested an individual class or even small collection of classes, the higher level interactions in the system would still have some issues that the microtests may not have covered. That wasn't a shortcoming of microtests, but rather it was never the intention of that level of tests to cover everything! Microtests and TDD show that the code is doing what the programmers intended it to do, which of course is very good, but those tests don't and aren't intended to show that the system is doing what the Customer or Product Owner wants it to do.
Fortunately, there were voices in that "we don't need testers anymore" wilderness such as Lisa Crispin, who co-authored Testing Extreme Programming, and ensured that the "programmers only" attitude was as incorrect as the "no documentation" myth.
Microtests and TDD are excellent, excellent practices and enable teams to drive towards zero defects in a very cost effective manner. You still, need, however, other levels of tests and testing to achieve that goal and to sustain a team's ability to be agile over any extended period of time.
- "Microtests" is a term coined by Mike "GeePaw" Hill - it's a synonym for unit test, but avoids the baggage of that term which can mean anything from manual running of code to automated tests that take weeks to write.
- "Tests" in this context are synonymous to the term checks used by some people.
I also remember that there was a buzz in the small XP community of the time that we wouldn't need testers anymore because our microtests would solve world hunger, cure cancer and probably fix the southern hemisphere ozone hole as a nice side effect.
Prior to joining the project where I learned about XP, I had the privilege of working with some really, really good testers who worked directly with me - we paired without knowing that it was called pairing. :) Those people helped me to think much more critically about what I was coding, and that translated directly to much better quality from my code. Adding the automation aspect of frameworks such as JUnit only served to improve that further. However, it wasn't enough!
It didn't matter how well I (or anyone I worked with) had tested an individual class or even small collection of classes, the higher level interactions in the system would still have some issues that the microtests may not have covered. That wasn't a shortcoming of microtests, but rather it was never the intention of that level of tests to cover everything! Microtests and TDD show that the code is doing what the programmers intended it to do, which of course is very good, but those tests don't and aren't intended to show that the system is doing what the Customer or Product Owner wants it to do.
Fortunately, there were voices in that "we don't need testers anymore" wilderness such as Lisa Crispin, who co-authored Testing Extreme Programming, and ensured that the "programmers only" attitude was as incorrect as the "no documentation" myth.
Microtests and TDD are excellent, excellent practices and enable teams to drive towards zero defects in a very cost effective manner. You still, need, however, other levels of tests and testing to achieve that goal and to sustain a team's ability to be agile over any extended period of time.
Comments