Even though at heart, both software developer and software tester have the same goal, which is delivering a software project with good quality, they go about it with completely different mentalities. The software developer has a constructive mentality, he/she is the builder, they think about creating things from other things that may be similar or may have remotely the same features, or even create things completely from scratch. While they’re working, they’re thinking “I want this to work”. They think about the business from a number of points of view and start tackling these visions they have of how the system should work. Once the system is working in a way that satisfies their idea of “working”, they have achieved from 80 to 100% of their goal and the feelings of satisfaction and achievement start to kick in.
The software tester, on the other hand, has a destructive mentality, but not in an evil way. The tester starts working on the project by doing a thorough analysis of all the things the system should and should not do. They map the SUT to the requirements in a way that “should” ensure the system does not misbehave so to speak. At the next stage of testing, the destructive mentality kicks in. the software tester starts working with the purpose of finding the bugs in the system; trying to find every possible mistake, misbehavior, and anomaly, however improbable it may be. They think of all scenarios, in an attempt to capture any idea the customer may have had about the behavior of the system that was not conveyed clearly in the system’s documents and may, by chance even, occur after delivery. And so we test and test and test, we look for bugs and misunderstandings, only wishing we find all the most probable bugs because we know that we will never find them all.
Here lies the dilemma of the software tester. We execute test cases upon test cases with limited time and budget. We usually do priority based work, where we execute the most critical test cases from the business point of view then we move on to the improbable scenarios and tinier bugs. Yes, we get our satisfaction and sense of achievement from finding other people’s mistakes. The problem is we will never be fully satisfied. The developer may feel at peace after fixing most of the bugs in the system, but the tester will always know that there are still more bugs that may come up. The tester knows that humans make mistakes and even though it is their job to find other people’s mistakes, they know that no one will find their mistakes unless it’s too late since the system will most probably be delivered to the customer live at this point. At this stage, the impact of the tester’s mistake will be too great to be “just a human mistake”.
Ok fine, I’m being a bit too morbid. In my case as a software tester, I can never feel satisfied when the system is delivered, no matter how much effort and time I put into the work. I always have the feeling that I’ve missed something, or that I haven’t worked hard enough. I’m always worried about the what-ifs. At the end of the day, I know the system I delivered isn’t perfect, and I know it is buggy even though the bugs are probably beyond noticing. But that knowledge will always take away my sense of satisfaction and achievement about a job well done.
