Bloggo back to the blog
If you want to really know, ask a tester!-->
Who should really know what is going on with the project, and how the software works (perhaps as opposed to how the software should work)? Not unsurprisingly, Peter Morgan advocates that it should be the testers that have this knowledge, both because of what they do, and because of their role as “the eyes and ears of the project”.
I am not entirely sure where the expression comes from, but I grew up with the phrase “If you want to know the time, ask a policeman” somewhere in the background. It could be from an old (music-hall style) song – but the phrase is really saying that if you want information, go to someone who should know and that you can trust.
So, who has good knowledge on your project? Who ought to know, and who ought to be reliable and trust-worthy? I would maintain that it should be the test team, and their knowledge is valuable on two counts. Firstly, testers have to know how the software should work as part of their job – they have to draw up some kind of expected results against which to measure success or failure. The success criteria has to incorporate not only the module or sub-system being examined, but the whole software solution – it is no good having a perfect billing system if this is not enabling customers to pay, for example. So the first kind of knowledge is about the big and small elements of what the application under test does, or ought to do. (Of course, even though this is about the functional behaviour, it will of necessity encompass what Brett Gonzales calls the famous ‘ability’ brothers – key elements in non-functional testing; use-ability, maintain-ability, port-ability being three from the ‘ability’ family).
The second kind of information comes from the fact that testers are the eyes’ and ears’ of the project. It is our task to see whether elements are working as they should, both in isolation, and when joined with other areas of the overall software solution. Don’t get me wrong – it should not be in our brief to alone decide whether the solution is “ready” (whatever that means). However, we do have a key role to play in providing information to others who collectively will make such choices.
In the software industry, we need to get systems into production. If as testers, we continually fail to enable software to enter production, we will soon be out of a job. However, it should be better software because of our involvement, or the confidence of the project team as a whole should have risen because of our efforts; “do you know, the test team crawled all over it, and found nothing of note!”
Amongst the reasons that testers should not be the sole voice in deciding whether the software is ready to ship is that we are pessimists. We see problems, and would sometimes rather concentrate on the one outstanding cosmetic defect rather than acknowledge that all showstoppers, major and minor defects that have been found thus far have been removed. It is because we are continually looking for problems that any discrepancies found have perhaps a disproportionate prominence in our minds. If you listen solely to testers, the software may never go live – and that is a career limiting prospect.
So my final remark is that testers have lots of good project information, and deserve to be listened to. However, we have to earn the right to be heard, and need to be aware of our own shortcomings, as professional pessimists.
Peter Morgan is a testing professional who has been involved in the ICT industry for more than 30 years, and worked in the freelance marketplace for much of that time. His time has sometimes moved from testing to ‘development’, but he would add “always using the mindset of a tester”. He is passionate about testing and a firm advocate of testing qualifications. An enthusiastic speaker and author, Peter tries to base his output on hands-on experience, attempting to relate fine sounding ideas back to how it will affect Joe or Jane Tester in their everyday working lives in the war of attrition that we call software testing.