Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Conclusions
I like what I see in test-driven development, and when writing software find that TDD works for the way I think as a tester. Prior to learning TDD, I could paralyze myself when programming because I kept thinking of all the areas that could go wrong. With TDD, I can start programming by writing a test, which as a tester comes naturally. I just had to get over the fact that when I’m starting out, I’m writing a test for something that doesn’t exist yet. I’ve found TDD to be a great complement to other kinds of testing. The more testing we can do, the more information we can gather to make decisions about the software we’re developing.
However, I will caution that TDD is not a cure-all. It doesn’t encompass all types of software testing, and it doesn’t replace testing at other interfaces, such as skilled manual exploratory testing at the user interface. I talk to too many developers who feel let down because TDD doesn’t solve all of their testing problems. Like anything we do in software development and testing, TDD involves tradeoffs, and we’ll know better in the long term how successful it is as a practice.
Conventional testers, try TDD with a developer and learn about it. Don’t be afraid to fail. Our failures tend to serve as wonderful lessons that stay with us. Be persistent, and don’t hesitate to ask a developer for help.
Developers, if you work with a conventional software tester, be prepared to learn other testing techniques that you can use in your own work. You might be surprised what you learn about your code by testing it from a different perspective.
I would like to thank John Kordyback for the TDD lessons, and Dana Spears, Michael Bolton, and Colin Kershaw for their review of and contributions to this series.