What is a software tester?
Software testers go by different names depending on the whim of the employer. They may be known as Software Test Engineers, Functional Test Specialists, or simply Testers. The title has little bearing on the tasks performed by the individual occupying that position.
A misrepresented definition of software testing has been floating around since the concept was first introduced. It states that a software tester’s primary duty is to find faults or defects within the program being tested. This perception is misleading for a couple of reasons. First, by definition, if testers are unable to find any faults or defects in a program, they are not doing their job. In practice, testers may find many defects within an application that is being developed; however, the goal is that eventually they’ll have eliminated all discrepancies. At this point, they are unable to continue the job.
Second, approaching a task as an error-finding duty instantly makes the tester/developer relationship antagonistic. If the tester’s job is to find fault, it follows that the developer will be defensive. Instead, the two roles should be working towards a common goal. An antagonistic environment isn’t conducive to positive results.
Verification versus Validation
The tester’s approach should be to verify and validate the software being tested. The terms verification and validation may sound similar, but they are quite distinct when applied here.Verification is about proving that the application is working properly and doing the job that the developer intended. If the programmer’s intent is to provide the sum of numbers inputted by the user, the entry of 1, 2, and 3 should produce the result of 6.
Validation, on the other hand, confirms that the program is performing the task requested by the customer. Taking the previous example, let’s say that the customer requires only odd numbers to be used in the sum-finding package. The entry of 1, 2, and 3 would produce the new result of 4; that is, 1 and 3.
Verification certifies that the product does the task properly; validation guarantees that the product performs the right task.
A More Realistic Example
Suppose that we have a situation with the following requirements: when the application is run, a window will appear containing an identification number box and a “View” button. Once the user inserts an ID number and presses the “View” button, data containing personal information (such as name, age, address, social security number, and so on) about an individual will be displayed. Before this happens, though, the user’s authorization level must be checked. If the user is not authorized to view such information, the data won’t be displayed and the user will be advised accordingly.
The developer might think, “That’s easy enough. I’ll check the user’s authorization permissions and, if he’s not authorized, I’ll simply disable the ‘View’ button, making it unusable. Problem solved.
Enter the software tester. In her role as user, she logs on as being without the proper permissions to view personal data. She enters an identification number and tries to press the “View” button. Nothing happens. “Well,” she thinks, “The program seems to be working correctly under these conditions, as the sensitive data is not being displayed. But shouldn’t the user be notified in some manner that the request has been denied?”
The tester takes the problem to the developer and explains her position.The developer responds that his approach is much simpler as it requires less code (therefore, it is more cost-effective). The tester replies that, while she understands the developer’s reasoning, more is required.
Together, they present their case to the customer, who confirms that a message should appear stating why access has been denied to the user. The developer now has the authorization to re-open the code and make the necessary modifications.
Finding defects at this level is much more cost-effective than discovering the same fault after the system has been delivered. The rule of thumb is that each level a defect progresses costs ten times more to fix than it would at the previous level. In other words, it costs ten times more for the tester to find and initiate the fix of the fault than it would if the developer had discovered his own error. And uncovering the problem in the field would cost one hundred times more.
Teamwork Equals Success
When testers and developers work as a team, there’s a much higher rate of success than when working independently. Clearly, it’s imperative that a compatible and respectful working relationship is established between the two early on. Not only does this produce a good basis for achieving goals, it also makes for a more pleasant working environment.