Editor’s note: We often think of software quality assurance as an action – not a process. But testing is really just one small piece in the larger picture of software quality assurance. This begs the question: does testing really improve software? Well, yes – it does. But perhaps not in the way you think.
According to Michael Bolton’s thought-provoking blog post Testing vs. Checking, testing is about asking and answering the question “Is there a problem here?” This means that part of the tester’s role is to reveal problems.
Without revealing problems, there is no problem-solving, since we can’t solve something we aren’t aware of. Each solved problem is one fewer problem in the software—and the software is improved each time a problem is removed.
So, improving software needs a cause (testing = revealing the problem), which then hopefully leads to an effect (development = coding the problem solution). And due to the fact that without a cause there is no effect, testing improves software. Period.
Think about waking up today. Most likely, you woke up when you heard the sound of an alarm triggered by your phone or an alarm clock. The loud sound of the alarm was the cause. Without the alarm, you probably would have overslept. In this scenario, the alarm (revealing the problem) had the effect of you waking up (coding the problem solution) at a certain time.
This is what I mean by cause and effect. It’s not a single action; it’s a process—a set of actions—that makes the software better. Here is part of that process:
1. Testing: Reveal the problem (done by the tester)
“I revealed a problem. Here it is.” Now, stop there. Does the product get better? No.
2. Design: Conceptualize the problem solution (done by the product owner)
“I conceptualized the problem solution. Here it is.” Now, stop there. Does the product get better? No.
3. Development: Code the problem solution (done by the developer)
“I coded the problem solution. Here it is.” Now, stop there. Does the product get better? No.
4. Operations: Release the problem solution (done by the release engineer)
“I released the software containing the problem solution. Here it is.” Now, stop there. Does the product get better? You may think so, but I argue not quite yet.
The software ultimately improves when the people for whom we build the software say, “It’s better now!” This is the point where the value of the problem solution is realized.
So, the person responsible for checking in a fix is certainly not only the person who is improving the software. It’s a group effort—it’s the commitment of each individual that improves software.