At my first job we didn't have testers. Had I spent a longer period in that company, I may have become an experienced developer who still didn't understand what testers were. There are a lot of organisations that create software without employing dedicated testers. I don't think that a poor understanding of testers is an unusual position for an experienced developer to be in.
Developers who have never worked with testers are likely to have an understanding of testing, but as an activity rather than a role. Testing happens as part of their work rather than being lead by a separate person. Why would testing be delegated when a developer can successfully write and release quality software on their own?
If you are a developer with this mindset or history, it can be really challenging to encounter a tester for the first time. Allow me to introduce you through analogy.
No Tester
A restaurant chef is a creator. They make a meal that is delivered to a customer. Quality is determined by the skill of the chef, the quality of their ingredients, and the practices that they follow.
In many restaurants the food is made, delivered to the table, and consumed. The earliest feedback that the chef receives is from the customer. In the event that they have a negative opinion of the meal, it can be difficult to fix the problem. The damage is often done.
There are parallels to software development without testers. Quality is determined by the skill of the developers, the quality of their platform, and the practices that they follow. Feedback comes directly from the customer, who can be unforgiving.
Restaurants can succeed in this model, as can software development.
Waterfall Tester
As a student, I worked part-time as a waitress. In one of the restaurants where I worked the restaurant manager used a small workstation that was located directly outside the double doors to the kitchen.
The chef in this restaurant was temperamental and territorial, so the restaurant manager would rarely venture into the kitchen. However, during meal service, she would intercept the wait staff as we moved plates from the kitchen to our customers.
If the meals for a table were ready at different times, she would hold service until they could be delivered together. If the presentation of a dish was sloppy, she would tidy it up. In the rare event that she was unhappy with portion size or the quality of cooking, she would return the plate to the chef.
The chef didn't like having his food returned. He would often over-correct in spite. You think the sweet and sour pork portion was too small?! Then you'll get double-sized dishes for the next hour! However he would ultimately settle into delivering a more appropriate size of meal.
On reflection, this restaurant manager was my first experience with a separate tester. Once development was complete she examined the final product. With a fresh perspective, she could identify problems that the kitchen had missed.
The restaurant manager contributed to the quality of the product through small actions of her own or by reporting problems back to the chef so that he could make improvements. He may not have always responded well to these reports, but he did alter the meals, which improved what the customer received.
Testers bring the same contributions to software development - a fresh perspective to identify problems, fast feedback from someone with a customer focus, and the ability to make their own small contributions to the overall quality of the customer experience.
Agile Tester
The restaurant manager was improving quality of a finished dish. What if there was a way to improve the meal as it was being prepared? Then a chef could adapt as they worked, rather than trying to alter their end result.
Sometimes there are multiple elements of a meal cooking at the same time. As a chef, it can be difficult to keep track and sometimes things get burned. What if someone else had set a timer, noticed when it had lapsed, and could intervene?
Sometimes there ingredients in a dish that look similar and might be easily confused. This week I prepared a meal with two spices: tagine spice mix and couscous spice mix. What if someone else had noticed when I opened the wrong packet?
Sometimes there is a requirement for consistency between meals. How can a chef be sure that the crème brûlée they create today is the same as yesterday? What if someone else could check that the recipe, portion size, and presentation met a minimum standard?
Hypothetically, this all sounds reasonable. Realistically, if you're a chef who likes to cook alone, this might sound like a nightmare. Perhaps you would rather have to throw away the occasional plate of food that was burned or tasted strange than accommodate another person in your creative space.
There is a parallel to the role of a tester in agile development. Success relies on collaborative working relationships that can be difficult to negotiate. Dealing with feedback from a tester can be frustrating, particularly when a developer is not used to receiving it. The tester will need to explain and demonstrate how their perspective can contribute to an improved product.
It can be difficult for the developer to adapt their approach and accommodate feedback. If they find that the information from a tester is not relevant, timely, or delivered in a constructive manner, then they should let them know. It takes time to form a useful working relationship and investment is required from both sides.
Every Tester
Whether a tester is contributing in agile or waterfall, they want to help deliver the best possible product to customers. If you are a developer who is encountering a tester for the first time, the first thing to assume is positive intent.
Testers bring a fresh perspective to identify problems, fast feedback from someone with a customer focus, and the ability to make their own small contributions to the overall quality of the customer experience. Allow them to influence the product. Ultimately they help to create a better outcome than what you could achieve alone.
