A Developer's Tips for Testing Software
Let's face it, being developers, we haven't quite come to accept the fact that we're not actually infallable. In fact after we finish writing a class and wiring it into the rest of the application we think:
This is awesome! This design is clean and the implementation is elegant and accurate; I bet it'll work exactly as-is!
Then we hit Ctrl-Shift-B (for Build)...and the build errors start to pop up. Well crap, surely there's something wrong with the compiler, let's do a Clean and Rebuild because my code can't possibly be wrong. Double-crap, same errors, so we reluctantly start looking into the errors and find a missed semi-colon here or a forgotten method parameter there, etc.
This is a funny scenario that we're all, all too familiar with. The sad fact of the matter is that we do all write buggy code, at least on most days. The quicker we can accept that fact and learn (read: force) ourselves to thoroughly test our code the quicker we can take our development skills to the next level. Here are some quick tips to help us test our code better as developers.
- DO IT - yes, the first step is actually testing your code. Either write automated unit tests or test how the code actually functions within the application. Better yet, do both!
- Test the happy path - Frequently we have a specific scenario, or set of steps, that we expect the user to perform when using our application. This is known as the happy path, be sure to test the happy path.
- Test BEYOND the happy path - This is EXTREMELY important: Don't just stop after verifying the happy path. Keep going and think of different ways that normal users (or even your slower users) could use the system. Try anything from slightly oddball steps to some flat out crazy-town stuff.
- Cover ALL execution paths - This is taking a more code-centric approach but your goal here is to exercise each possible path of execution that could be taken through your code. You're looking for as close to 100% coverage as you can get.
- Don't neglect regression testing - Believe it or not, it's not all about the shiney new code that you just wrote. That code has to integrate and work with a large swath of existing code within the application. Even though your code may be working correctly, it may have broken something somewhere else. Think of other functionality and features that your new code could potentially impact and test those areas of the application as well.
Final note:
Once you start testing, don't stop until you're done! Resist the urge to research and fix the bugs that you find. Just write them down (including detailed steps to reproduce the bug) and continue testing. How do you know you're 'done'? You're done when you've covered all your code paths and have regression tested every area that you're code could impact. After that you can fix any bugs that you've found.....and, you guessed it, test it all over again. :)