Some tests will yield more insight than others.
Test-Driven Development (TDD) — the idea that you write tests before you write any code — is one of those killer ideas that we just keep coming back to.
At a technical level, most experienced software developers understand the inherent value in TDD: delivering a suite of automated tests alongside your code just feels a heck of a lot better and (it is definitely true) results in many fewer bugs. Years ago it seemed that very few firms adhered to this approach, whereas today it feels like a great number do.
What I love about the TDD approach, however, is that its value goes beyond the technical and into the organizational: it helps to address issues that somehow arise in every project. For example:
- There always seems to be time at the beginning of a project to talk about new features, but somehow there’s never enough time at the end for testing.
- Requiring that a suite of automated tests be created upfront tends to drive a design that contains a number of technical goodies (like well-defined, documented APIs and the decoupling of back-end systems from front-end user interface.)
- Testing at the end of a project can be drudgery, whereas at the beginning of a project testing can actually be fun.
What’s that? Testing can actually be fun? Right, you might say. About as fun as sitting on the beach in the rain. What is this guy smoking?
Somehow the software industry has evolved into a strange beast where testing and QA became a second-class citizen. I’ve worked places where it was just understood that software design was for senior engineers, while QA was for junior employees — maybe a stepping stone (perhaps) to getting to actually create stuff yourself.
While I don’t agree with this approach, I would accept it if it worked. But, the thing is? It doesn’t. Large numbers of junior people — whose sole job it is to catch things downstream — are never as effective as senior people who catch issues early in the process. How early? Well, ideally at design time — before the code is actually written.
Yeah, sure, you say. But how does that make it any fun? Well, I know of at least three ways:
- Designing tests before any code is written requires a lot of strategic and creative thinking. When you’re trying to design your testing strategy, you’re not trying to catch one bug, you’re brainstorming about what types of tests would catch a whole raft of bugs. In other words, QA design is software design. It requires you challenge your skills to try to write not just a few tests, but to really envision the entire problem space and think about where you can get burnt downstream.
- Designing tests is a good team sport. At this level, testing isn’t just for “QA people,” nor is it even only for software engineering. Involve everyone you can think of — product designers, marketing people, you name it — and ask the question: how would you break this? I’ve frequently been amazed at how clever people can be at inventing tests that I never thought of — but that, once created, make the system stronger.
- It gets everyone thinking about quality upfront — together. Nothing is worse than having to be the lone “whistle-blower” developer who shouts out just before shipping, “but it’s not ready!” Participating in designing automated tests upfront helps get everyone involved in the process of creating something of high-quality.
For some great resources on how to get better at not only TDD but thoughts on how to build great tests, check out a few of the excellent books over at The Pragmatic Bookshelf.
