Tester vs. Developer

Often a battle of many rounds, the tester is seen as the anti-developer, with the developer standing for creation and the tester the destroyer of the developers work. On many occasions you will see their two departments almost fighting battles as each tries to prove its worth and capability. The smart developer will realise that the tester is there to enhance the impression given by the developer. A developer who is told where the bugs are is able to modify their code and the result is a far happier end user. Not only that, but if the tester is involved in static testing of requirements, the difference to the developer can be huge, with each requirement being unambiguous and so far easier to develop in the first instance. When code goes live and the volume of bugs is minimal with positive user experience, it is rarely the tester that is thanked for their diligence: more likely to be the developer thanked for their fantastic software.

Yet all too frequently, the developer and their skill set are valued above the tester. Within the project life-cycle, development is considered essential, testing as a "nice to have". The disciplines are two sides of the same coin and occasionally someone migrates from the dark side to the light or vice versa. (Up to you to decide which is which?) The developers mind set is one of creation whereas the tester is one of destruction. There is no doubt that the tester becomes redundant if there is no development whereas the opposite is not true. Many projects are still run today with no focus on testing and the onus is placed on the users to experience the problems and report them.

It is well cited within the testing industry, that each progression of a defect to a later phase in the software development life-cycle (SDLC), makes it 10 times more expensive to resolve. So a requirement costs £1 to fix, design costs £10 to fix, development costs £100 to fix, testing costs £1000 and live costs £10000. Defects that translate into an outage for a business, where large volumes of resource are stopped from working, are indeed expensive. Surely this makes the role of the tester incredibly valuable to the SDLC.

Here are some other considerations on the value of the humble tester:

1. The tester must be able to analyse requirements and in static testing take on part of the guise of the business analyst
2. Rather than looking singularly at how a function should be used, look at all of the permutations then look at all the permutations of how it should not be used
3. Pressure is high as the time allocated for testing on a project is regularly reduced as earlier phases slip, resulting in late code delivery
4. The tester is trained in multiple testing disciplines and techniques, enabling them to perform sufficient testing
5. There are as many types of testing that the tester should be able to handle, as there are development languages
6. Automation, Performance and Security Testing require levels of expertise akin to a developer or network specialist
7. The go-live decision of a project relies primarily on the advice of the tester and the evidence that they can provide to support the decision
8. Advising and working with the business to perform acceptance testing
9. Able to witness the unit and integration in the small testing performed by the developer
10. Efficient management of defects through to closure.