Integrity Helps Build the Bridge

What is integrity worth to a tester? It's the one thing you don't ever want to lose. I think Kaner, Bach and Pettichord said it best in lesson 227 from Lessons Learned in Software Testing: "You don’t have to promise the impossible. You don't have to lie. You don't have to cover up problems. In fact, as a tester, the essence of your job is to expose problems and not to cover them up. You don't have to, and you never should, compromise your integrity." And further on,"Your power comes from having the freedom to say what’s so, to the people who need to hear it. If you compromise your reputation for integrity, you'll weaken one of the core supports of your power." Amen.

After testing for 11 years you bet I've been confronted with the integrity issue. I've been told not to report bugs until after the release just so we could make our proposed ship date. I've been told that “you’re not supposed to find bugs this late in the game," after finding bugs in the fourth pass of a program as the deadline looms. I'll admit a tester can go too far. Rex Black, in his book Managing the Testing Process, said that “Beyond being equipped with the basic skills, the best test engineers show real commitment to testing as a specialty, have pessimistic but flexible attitudes toward any system under test, possess curious but not obsessive minds, and demonstrate an ability to focus intently." I've learned that having the flexibility to accept differences of opinion & approach on the project can actually make the product better (see my article The Path of Least Resistance). To accept the free-wheeling style of the programmer as an undeniable and unchangeable fact of software development is the beginning of getting more tested code from your colleagues. Instead of being an "inspector" looking over a programmer's shoulder, you can now be their ally. An ally who thinks up test cases that otherwise would go unnoticed; who describes bugs in a way that will make it easier for them to find and implement a solid fix; an ally who can help set up complicated test scenarios; and an ally who can complement the programmer's free-wheeling style with some much needed discipline as the project enters its stabilization phase.

Getting back to integrity, Boris Beizer in his 1984 classic Software System Testing and Quality Assurance described the qualities he felt would be beneficial for a tester. Besides experience as a programmer and tolerance for chaos (among others) he listed "honesty," and described it this way: "Fundamentally honest and incorruptible. Agony over perceived compromise. A dedication to 'right'." Everyone has this quality to a degree, some more than others. The important thing is to hire testers who have more than less of it. Why? Experience tells me that a tester without it won't stand up for the customer when it counts. Everyone knows how painful the stabilization phase of a project can be. Fixing those relatively minor bugs and retesting the same fix once, twice, maybe three or four times before it's right goes against the previous forward motion of the design and coding stages. As Bret Pettichord said, “Good testers must not shy away from argument. It's their job to report bad news—and this is not always taken well." (from Testers and Developers Think Differently, STQE Magazine, Jan/Feb 2000).

If you’re not convinced about the importance of integrity by now I doubt that you ever will be. Maybe you're more of a "developer" type who just can't see why people would want to intentionally make their lives so hard. That's OK. Like I said, it's important to have different ways of thinking. I'm not a Buddhist (my grandfather was a pastor in the Methodist church), but I think it has to do with "yin" and "yang". Both the developer mentality and the tester mentality are inescapable and intertwined parts of the dynamic of software development. Once you're aware of this principle, the knowledge can be used to your advantage. Instead of being frustrated by the developer's seeming lack of care for the quality of the release, you can understand how hard they have worked to get the product as polished as it currently is. Your role changes from one of adversary to one of bridge builder. The raging river that separates technical developers from their less technical customers becomes less of an obstacle if a bridge is built over it. Think of the stabilization phase of software development as the building of this bridge. With integrity on your part, that bridge can become a reality.