Tuesday, January 12, 2010

Testers not required

I don't like testers. Let me rephrase that, I don't like needing testers. We had a debate today regarding how to future-proof a legacy system to make it viable for the long term. We've had a number of production issues that have caused us some embarrassment and the project manager wanted to find ways to avoid these in the future. The system itself is a large, poorly architected, poorly coded system with many external dependencies. The code is brittle and without a completely automated build it takes significant time to setup even a manual regression test.

The project manager (and many of the developers) wanted to get testers into the team to ensure full test cycles are carried out before putting a release out to the business. Whilst not completely against the idea I saw this as an attempt to treat the symptoms of the problem (bugs reaching production) rather than the cause (bad code). If we're seriously suggesting using human testers to perform regression tests in 2010 then we're doing something wrong. Testers have a place for new functionality but we're really not producing enough new features - due to the bad architecture - to warrant a dedicated tester just for new work, and in any case we have a BA capable of doing this testing.

This is a simple case of technical debt. Paying testers to regression test is like paying interest-only on that debt - not reducing the principle but still servicing the loan. In order to reduce the interest payment we need to payoff some of the principle - i.e. refactor, replace, re-architect the code. To do this we need skilled senior developers not testers.

But there is another reason I don't like testers, especially on teams with more junior developers. The developers seem to believe that having testers absolves them of the responsibility for preventing bugs getting into production. They can say things like 'well who tested that function - how did this get through?' with genuine indignation. This transforms into a tendency not to test their own code, automate tests, or even think about tests before coding - all things we _require_ to be done on new projects.

So if you find you need testers to stop bugs leaking into production software what you probably need is better software with continuous integration and automated tests - i.e. what you need is better developers. Once you have this in place you'll find you only need BAs and business users to test new features.

Ergo - Don't become a tester!

No comments: