We recently sat down with the testing team at Infinio in Cambridge, MA to learn how they have implemented their test automation strategy. The cool thing about their strategy is that the whole development team (developers and testers) work together to create testable code that can be exercised to its fullest extent by the testing team so they can "test the most code in the most environments in the shortest period of time..."
According to the team at Infinio, one of the most satisfying things is trying to sell cultural change to a development organization from a QA position. An example of this is in how they use fault assertions in their automated testing. When you first get a release, it's unstable so testing error code handling paths is simple because the instability triggers so many errors under normal testing.
But when the mainline stabilizes, the bug count starts to go down and it becomes much harder to test how the code handles error conditions because they occur so much less frequently. Rather than deciding the code is solid enough to ship without checking all the recovery code that's been added, you can use fault assertions in your automated tests to uncover any problems that exist in your error handling.
With overt control of your error handling code paths, you can have greater confidence in the code you deliver. Part of this requires a negotiation with your developers to deliver faults with the code so it's testable by your automated test suite in all the environments you need to cover. This collaboration between development and test to create testable code can save a lot of time and investment later in the cycle.
Does your development team discuss ways to make your code more easily testable? Let us know what works for you!