What’s your perception as a software designer about the people who use your design to test a piece of software, the ones calling themselves software testers? I bet it hasn’t always been a good one, has it? Maybe you still have strong feelings about testers using your hard work with the sole purpose of tearing it apart for the sake of some project. I know I have. Even worse, I have been one of them for a significant part of my professional career.

Then I became a software designer. And what I learned is this. As a tester I thought I could do the work of the designer. I was doing his work anyway, just a couple of years too late (this was during a very long project). But when I became a designer I started to think the other way round. "I can be a tester. I know more about the piece of software than anyone else. After all I’ve written the d$%&n specs, haven’t I!" There’s truth in both, for both attitudes create test driven requirements. The only thing is, that it's far more effective to create test driven requirements as a designer than as a tester, for if you have to do it as a tester the project is probably burning down in some way. And that’s exactly how professional testers always feel. That they have to be like some firefighter saving the day. That’s where there pride stems from, feeling like the hero.

Here’s where the second rule of test driven requirement engineering comes in. After you’ve created a set of compelling visualizations for the client/end-user and the developer so they both know what to expect, reverse engineer your own visualizations into a set of test driven requirements. Every button, every field, describe everything in a way that leaves no room for interpretation, as best as you can of course. If you do that, designing and testing are united into a solid requirements list which can easily withstand the abuse of any experienced tester. What’s more, as a designer you’ll be able to take the role of software tester yourself while expanding as a professional in the software industry.

I’ll leave you with this for the moment. In future blogs I’ll will be sharing specific tools about how to exactly create test driven requirements and reveal the inconvenient truth about software designing. See you next week!