Adam Jordens@littlesquare:~/

Obviously software testing is a good idea. I’ve been a software developer long enough to realize the benefits of investing in up-front testing of the software. It’s baked into my development process and I wouldn’t commit code without at least thinking about the test scenarios, let alone consider writing them up as [unit|integration|regression]-tests.

I started writing this post a couple days ago when I found out that I’d be tapped to help our QA group with some end of iteration testing this Friday (today). My first reaction to GUI regression testing is that it’s an annoying thing for a developer to have to do. It being the act of running through written regression tests and effectively clicking buttons and ensuring that the application behaves accordingly. We’ve actually done this (successfully) for years but luckily the QA team is starting to get large enough that they don’t require many testing resources from development. On one hand that’s good, developers can remain focused and don’t have to do manual regression testing, but on the other hand, there’s a lot of potential improvements (automation and other-wise) that could be accomplished rather trivially by properly motivated developers if given the opportunity.

I don’t think that developer written tests should ever be considered a substitute for end-to-end system regression testing. However, developers should know the in’s and out’s of a system and if motivated enough, be able to make the running of these regression tests more efficient.

Here’s a couple concrete examples:

- Automating data creation. ex) We’ve got a process that imports an excel spreadsheet who’s format is dependent on pre-existing data in the database. The data changes and therefore you’re forced to make a new spreadsheet for each testing session.

- Performance testing. If you’re using a stop watch to gather performance statistics, that’s gotta be annoying. Invest a few cycles in building an automated test suite that covers enough scenarios to determine trends and problem areas. Run them frequently and without much human intervention.

I don’t think that developers make good testers and vice-versa. However, there’s a definite synergy between testers and developers that if you could just let each do what they’re good at, the overall outcome would be better. If you must have developers help out with testing (assuming they’re not your only testers), consider giving them the flexibility to improve the process alongside simply pushing buttons.