Testing

It's a bit weird for me to write a blog about testing but with TestBash happening at the moment I thought I'd take the time to at least document a recurring conversation I keep having with a colleague of mine who is funnily enough a tester.

The conversation usually revolves around me trying to assert the idea that there is no developer or tester, there is simply someone involved with software.  What I mean by this and typically fail to impress on is that a developer does (or at least should) also test code just as a tester can write code if they want to.

The important thing in this conversation is the statement "if they want to".  There should be no impediment to a tester getting involved with writing code if they want to, just as there should be no reason a developer can't come up with all manner of ways to test a system if they want to.  There should be no voice of dissension should either camp decide to get involved, if there were this would be like some sort of apartheid and detrimental to the individual as well as the team.

There are advantages and disadvantages to allowing this but let's be honest we're all people not our designated labels so choice should be the driving force and we should aim to integrate these two areas of discipline that exist within the same sphere of influence, they are not polar opposite, far from it so let's realise that and work together!

When testers code it can on the one hand lead them to focus on the possible issues that will be encountered from a programming point of view such as numbers being out of range e.t.c., this focus can lead to identifying areas worth testing rapidly...however...this focus can lead away from possible odd scenarios.

This all leads on to the fact that finding bugs and prioritising bugs are two very different things, if a bug is found but the likely hood of it happening is a million to one shot and the cost to the customer is minimal as compared to the cost of repair then does it need to be repaired.  This philosophy reminds me of a scene from Fight Club where the Ed Norton character is telling a passenger on a plane that if the cost of an out of court settlement multiplied by the frequency that the failure could happen is less than the cost of a recall they simply don't do one, this is probably closer to fact than fiction than we want to admit, after all businesses are in the business of making money and this sort of gamble is how they keep the bottom line healthy.

Anyway testing and development need to share as divided we fall!

This particular conversation keeps happening almost as regularly as the non-argument about test automation...don't get me started on that though!