Sometime back my favorite podcast Radiolab – released a short called “The Loneliness of the Goalkeeper” . The short was a re-broadcast of an english show on football (soccer) and the role of the goalkeeper in the game.
In soccer the goalkeeper plays a truly unique role – the opposite to the role of the remaining 10 players in the team and indeed one could argue the aim of a game of football. The goal keeper has to defend the net and prevent a goal being scored.
Of course, the other players in his team also help him in defending the net, but there are few differences that make the goalkeepers stand apart. The primary one, of course, is that he is allowed to use any part of his body to handle the ball during the play in a restricted area in front of the net – the penalty area. If the ball enters the net – even if it is through a mistaken strike, an ill-conceived pass or fumble from him or his own team – the goal counts against the team…
This means that a goalkeeper rarely ventures outside the penalty area – he is the last line of defense to prevent the ball from getting into the net. This is the loneliness of the goalkeeper – he is ultimately responsible for any goal and must protect the net from all comers – friend or foe…
Image via Wikipedia
The narrator of the piece goes on exploring the mental make-up of goalkeepers – the strange almost contrary nature that is needed to be a great goalkeeper. There is a subtle psychological difference in the mindset, brought on by the role of the goalkeeper. A goalkeeper does not have a single moment of triumph, there are only moments of disaster… A goalkeeper’s mistakes are obvious and public while his success is not. After all – a goalkeeper who manages to prevent the opposition from scoring the entire game has simply done his job while a striker that scores that final goal takes his team to victory or saves them from defeat – is the hero!
As I listened to the podcast, I was struck by the similarities between the role of the goalkeeper and the role of a software tester. Unlike the rest of the team, the goalkeeper’s motive is to prevent a goal being scored – similarly the aim of a software tester is to find defects in code that is created by the team. In a way the software testing role requires an almost opposite mindset to that of a software developer, who wants to build a working product.
It is preached everywhere that a good programmer tests his code. Indeed nowadays it is a given that software should be written test first and the agile philosophy embraces this as a core tenet. I think the concept of TDD is brilliant and that it promotes good coding habits. But I think in all the hype there is one point that has for a long time not been emphasized and that is the writing code in the test driven style does not mean that your code will be defect free.
I have seen a lot of people claim that they write their code test first as if that somehow means that they don’t need to test it. This assumption then leads to an impression that all one needs to do for getting defect free code is to embrace the test driven development style. However what people don’t consider is that when a developer sits down to write code , he does so in a certain context. Code does not exist in a vacuum, it needs to interact with other code and in many cases the code itself might be a small section of a module of a feature in a platform.
The tests referred to in TDD are simply the ones that validate the requirements for the code that you are writing at that point of time. These are unit tests and do not test the software product – only the code being written is to be tested. Writing tests for even that narrow scope requires a mental shift. Programmers who are used to simply writing code (and I count myself as one this group) find this mental shift a pretty big hurdle. It is really hard to force yourself to sit down and think of the requirement and then do the coding and writing the tests needed to validate it (especially if you have a deadline or worse a manager breathing down your neck). And after you do all that, you find yourself having to mock the environment around your code and tests to get them to run consistently (or at all). Sometimes it is simply not feasible/cost-effective or even necessary, to write tests that cover every error that your code might meet. To tie this back to the football analogy, I would consider that software developers can make at the most – defenders of the goal. They are restricted both by their role and by their mindset from being able to truly subject software to the test.
In contrast, a software tester approaches things from a totally different perspective. The role of the software tester is to find defects – it is his goal and his responsibility is to the quality of the software product as a whole. Testers approach software from a product perspective and not a code perspective. They look at the entire product, its various layers and the seams in the code, where the different features come together – and then look for defects. They write code (in fact I think good software testers need to write as much code as developers) to probe the product from various angles. Software testers need to test the various modules, individually and in combination and using different types of input.
Testing is a matter of diligence – the sheer focus needed to go through all the combinatorial options for all the inputs and apis available in a typical software product requires an intense mental focus and very tidy and organized mind. It is this mental makeup that make great software testers. It is not easy to find people with such a unique mindset – in fact I was reading the other day of a startup company that hires autistic people for software testing. Traits that make great software testers – intense focus, comfort with repetition, memory for detail – also happen to be characteristics of autism.
The role of a software tester is a lonely one – it is not something that will endear you with developers – after all you are pointing out defects in the code they wrote. If the software product fails the responsibility of failing to find the defect falls on the software tester. If the software tester does his job well and all the defects in a software product are fixed – he has merely done his job. Indeed if he does his job too well, and there are no defects to fix people will start wondering if there is a need for the role at all…
Like the goalkeeper – the software tester has a lonely job, but a vital one – he is the last line of defense – the responsibility of the overall quality of the software product lies with him. Software developers may have written the code for a killer feature but it is the software tester that ensures that it enhances the software product instead of breaking it….
Related articles
Technikhil Writing 
In the music field he plays an indispensible role and leads the direction of the development of the music.
“The role of a software tester is a lonely one – it is not something that will endear you with developers – after all you are pointing out defects in the code they wrote. If the software product fails the responsibility of failing to find the defect falls on the software tester. If the software tester does his job well and all the defects in a software product are fixed – he has merely done his job. Indeed if he does his job too well, and there are no defects to fix people will start wondering if there is a need for the role at all…”
I roughly disagree with every point of this paragraph. Developers should be glad when they have testers on their team. They should give heed to them. Likewise testers should not be afraid of giving bold feedback to developers. If a developer is offended over a defect that the tester found, then he (the developer) is not a good team player, and probably doesn’t care much about the product he is developing. If a software tester does hid job well and there really are zero defects in a system because of the software tester, then the organization should be making him some higher-up offers, maybe bring him on as a team lead, but they should never doubt that there are no defects because of the tester. On the other side of this argument, you might think that there are no defects because the developer is so good at programming. I don’t think that either of those are likely to be true. It is more likely that the software tester and the developer don’t understand the code well enough to test it thoroughly and thus determine that there are no defects, until it is released to production. The problem with software is that it only makes the computer do what you told it to do. It can’t think for itself, it can’t understand your intentions. It just does. and so often software doesn’t fall short with the tester, or even the developer, but rather at the business requirements level.
Yes, I agree that intellectually it does not make sense that there be antagonism between a software developer and a tester, – after all in both cases the people concerned are doing their jobs… I don’t think you will find any software developer out there who says that he is against testing or testers – that would not make any sense. What I am referring to is more of an instinctive and unconscious emotion rather than an intellectual one .
This IMO is a natural reaction – after all no one likes to be told that their work is defective. People naturally turn defensive when subjected to criticism, however honest it is – that is the initial reaction. It is the reason that direct communication is so useful in the case of the relationship between developers and tester.
Often the communication between tester and developer is through formal email and test documents, either because they are not co-located or because they are in different departments (or even companies) . And this is another reason for friction since formally written documents are inferior tools to communicate when compared to a face to face conversation.
Very true, TDD is just to ensure that the code works as required, it never covers which all conditions that an end user will make the code to pass through or other all places the code has made the application vulnerable. Ultimately tester takes the pain of thinking all negative stuffs, the negative testing.
You just walked us through the human deficiency, of willingness to see only what is shown to him. That’s when he miss to remember the goals blocked and errors caught at testing. Only the goals compromised and issues reported by the clients are considered and of course goal keeper and tester are there to take the blame on.
Thus, as the goal keeper is the firewall at the goal post, a tester firewalls the programmer in and out ( in – catches the error before release, out – takes the fire of issues reported after release. )