I’ve been meaning to write an article that focused on testing, but somehow struggled to organize my thoughts enough to actually do it. That is ironically similar to the general approach I see to testing on most projects; it is something we are always going to get around to doing but it never really receives the necessary time and focus. Have you ever been on a project where the testing was given its full, allotted time and attention? It’s a rarity.
We all know that testing is an essential part of any project. Many life cycles have a phase called testing, or dedicated to it. But when push comes to shove testing invariably gets shortchanged. While we should be living by the mantra “do less better” we placate ourselves with “doing more poorly,” believing that more is better and quality will eventually “be there.” Why is this so, and what can we do to get out of this delusion?
We could start by looking at testing from a human perspective, rather than a process perspective. The reasons for insufficient testing are more than just not having enough time in the schedule to test. There is something more primal at work here-FEAR.
First-Reduce the fear of feedback
I believe that the primary reason we don’t give testing its appropriate due is because we subconsciously fear any form of evaluation. (Does anyone have their true weight on their driver’s license? And why do so many people refuse to ask for directions?) We prefer to live in the comfortable bliss of denial, or at least intentional ignorance, even if in our hearts we know that we don’t really know what’s real. Either would seem to be preferred over seeking proof that our reality is just that: our reality alone.
Ironically, this fear often stems from the fact that we have some sense of what is real and may even know what we should do to correct it, but find comfort in ignoring that reality because it is better than dealing with it. The hope is that it will just go away, but it doesn’t. The only way to reduce this fear is to get more comfortable shining the light of feedback on it.
On projects, we fear that the result of our efforts may not be acceptable to the judge/inspector, and in turn we will be judged accordingly. Think about it: what is your gut reaction when you are asked, “Can I give you some feedback?” Usually it is defensive and closed. You fear the feedback because you feel it reflects negatively on your work and ultimately on you. Being judged or evaluated threatens and challenges one of our basic human needs: social acceptance. How we are perceived by our peers or supervisors is important to us. Inviting something that would threaten that need would feel uncomfortable. And if we feel that could lead to even more dire consequences, the threat level increases.
Unfortunately, this fear of evaluation starts a destructive cycle. It makes you tentative and shuts down communication, impeding the feedback loop necessary for the positive and constructive dialogue that is essential to testing. If fear is getting in the way, it may be because you are putting your personal interests and needs in front of the goal of the project or your deliverables.
Testing the product isn’t about you, it’s about the product, so don’t take it personally. For a great exercise on learning to reduce the fear of feedback and creating a constructive feedback loop, see one of my earlier articles, “Learning and Feedback. Focusing on the outcome and the product instead of protecting people’s egos will eliminate some of the fear of feedback.
Second-Apply feedback early, often, and in small doses
Once we’ve gotten past the personal assault on our ego, there is still our fear of the negative consequences to our scheduled workload. Testing could reveal potential changes, or rework of what is already thought to be correct and done. Who has time for that?
Some time ago I consulted with a software firm that employed close to 100 developers and not a single tester. That is not to say that testing wasn’t being done. It was, but mostly by production customers in real time. While this created a high level of customer intimacy for the support staff, it was usually in an apologetic and recovery mode. Management refused to hire testers because testing was seen as a roadblock to quick development and implementation.
Of course, the fallacy here is that eventually more development time was spent fixing bugs than developing new features, while support staff increased disproportionately and implementation complexity increased. Avoiding the tests actually elongated the time required to deliver business value to the same customers they were in such a hurry to deliver to. They were in a self-fulfilling downward spiral and needed to pull out. The old adage that we never have time to do it right but we always have time to do it over is unfortunately too true.
To avoid this situation, get in the habit of testing early, often, and in small doses. Rather than having a phase for testing, make testing part of the development process. There is a lot of material being written today on Test Driven Development, which employs this approach. While there is a lot more to TDD, the general mindset of continuous testing of all product outputs is a core principle. Examining every outcome or product against some predetermined acceptance criteria, known or unconscious, to confirm that it is acceptable is more easily accomplished when it is done often and on smaller chunks of work.
Asking questions frequently and testing incrementally reduces the fear by reducing the magnitude of the consequences. It also provides ample opportunities to affirm the correct result and increase certainty of expectation. Either way, it confirms the expectation or starts the dialogue to discover expectations. To escape this fear of the unknown in projects where uncertainty reigns supreme (aren’t they all?), start the conversation early and keep it going. You will find the “small and kind corrections,” (my daughters’ term for my suggestions) work a lot better than dealing with the resistance that is inevitable if you wait until things have strayed too far off course.
The Goal-Get Real
The third and biggest reason I believe we avoid testing is because we fear “real reality.” Testing is about knowing exactly what is real and what we have fabricated in our minds and believe or assume to be real. From this perspective, testing could be seen as time spent telling us what we already know. Why look in the mirror if you already know what you look like? Testing is about getting real. Testing is
about knowing what is and what isn’t. Without the mirror of testing, the current state of your project outputs, and therefore your project as a whole, is at best a wishful guess.
Let’s admit it: developers and engineers don’t live in reality and we don’t really want them to all the time. The output of a creative process is by definition a deviation from the current state, and developers are asked to be creative, to think beyond what is to what could be. In contrast to that, testers are asked to determine the known state of that creative output. Developers see what they believe; testers believe what they see. In the creative mind of the engineer, it all works. For the tester, what works is what can be empirically validated-nothing else.
As a project manager, I am constantly asked to accurately represent the reality of the project status. Status reports and schedules will only be as accurate as my knowledge of the known state. Without testing, I’m just guessing at the known state, or worse, relying on the altered state of reality most developers
live in.
Building a Culture of Reality through Courageous Dialogue
Getting real starts with the desire to truly get real. It means having the discipline and courage to stand in front of the mirror and see exactly what is reflected with as few filters as psychologically possible. No “yeah buts,” no excuses, no comparisons, just a true reflection of what is, warts and all. Judgment and evaluation can come later, but first see things as they really are. Living in a state of altered reality is rarely a good thing, even if reality is unpleasant.
But it does not have to be that way. Implementing solid and deliberate testing behaviors is a step toward creating a culture of reality. The process of testing is the same as the process of doing a retrospective or post mortem. It requires the same safe environment that is designed to seek the truth through open dialogue, rather than lay blame and crucify the guilty. When teams can openly discuss the good and bad, the working and the broken, the clear and the foggy, you have set the stage for creating a culture of reality.
Here’s a simple game I used with my girls when they were younger. Before “inspecting” their work, I would ask them what grade they felt they should receive for the work they did. If it was anything less than an A I would ask them what they knew could have been done better. They usually knew so it saved me “testing.” If it was an A, a few simple questions usually got us to mutual expectations and an opportunity to re-grade if necessary.
By the way, turnabout is fair play, so they got to ask me the same question when I was doing something for them. Painful as it was, it started the dialogue. That is a great first step, even when reality sucks!