Tuesday, July 20, 2010

Make it or break it

Some times I am working on a project alone doing both design, planning, programming and testing. I have found it useful to separate these different kinds of work as much as possible. That's because programmers are not good testers. Programming and testing requires totally opposite mindsets:
  • Success as a programmer is to get something to work (make it)
  • Success as a tester is to find something that doesn't work (break it)
If I start testing while I'm in programming mode, I will not try very hard to break it, so lots of errors will slip through.

But on the other hand, I can easily get into programming from testing. When I am testing, I am working with an example, and the example helps me to focus my programming. But I try to avoid jumping from programming to testing anyway, because it is hard to get back to effective testing again.

1. Design
I get the best results if I start with designing a few examples of how the functionality will be used. The examples help me to focus and remember all details. I will also use them as my test specification. Then I create automatic tests based on these examples.

2. Implementation
The automatic tests will remind me what I need to do, so it's no problem to take lunch or end the work day now. But often I am so focused that I just continue with implementation until all the automatic tests pass. After this I take lunch or a long break before I start manual testing.

3. Manual testing
I don't write a test specification for myself, I just run through the examples I designed in the beginning. If I find any errors, I don't fix them right away, but write them down in a test log. When I have tested everything, I can get back to programming again. Since I have some automatic tests in place, it's usually easy to add some more tests that captures the errors.