Even Subject Matter Experts Need a Programming Background

[article]
Having Something in Common Helps
Member Submitted
Summary:

Subject matter experts who test can have a hard time communicating with programmers unless they understand the challenges of the programming profession.

Boris Beizer, in his 1984 classic, Software Testing and Quality Assurance, listed "Experience as a programmer" as the number one quality he observed to be beneficial in a good QA worker. I tend to agree, in most cases. You see, there are many different types of testers: subject matter expert, system performance guru, automation expert, and test engineers who use programming skills to make software products more reliable. For all but the subject matter expert, experience as a programmer would probably be a prerequisite for the job. What I want to argue is that programming experience (or at least the equivalent exposure of a college minor in computer science) is an important part of being an effective subject matter expert. Here's why.

Subject matter expertise assumes familiarity with customers and their environment, so my first point is that programming knowledge can act as a balance for the involuntary prejudices developed during this previous user contact. I've noticed that one of the few drawbacks of recruiting testers from a company’s customer support department is the zeal with which they attack their first programs. If these new recruits have no previous background in programming, they might not realize how difficult an intellectual challenge programming is. Without this technical background they might have little empathy for programmers' concerns, while echoes of irate customers still ring in their ears. They might have even concluded, from their previous experience, that careless programmers were the cause of all that pain and suffering. A programming background will likely soften some of these harsh feelings. Not only that, but a common technical bond might engender some mutual respect that can take the edge off a relationship that is adversarial by development process design.

Besides easing the human antagonisms inherent in the developer/tester relationship, subject matter experts with programming knowledge might be able to describe bugs in a way programmers can more easily and quickly understand. Another even more important benefit is that the tester will know how important it is to verify bug fixes promptly. I recently spoke to a maintenance programmer who was livid because a fix she did a month ago was finally being tested, and the tester found a problem. She was asked to drop everything immediately to re-do the bad fix. First of all, a tester who understood programming might not have let the fixed code sit so long. But even if the delay was unavoidable, the tester would have at least approached the programmer with more tact, realizing that the complexity of software problems and solutions is not something that can be instantly accessed, like tracks on a CD.

Another way subject matter experts benefit from programming knowledge has to do with "Lesson 287: Test to the maturity of the product" in Kaner, Bach, and Pettichord’s book Lessons Learned in Software Testing. The lesson's importance is not obvious unless one has programmed. Writing a program or crafting a solid fix for a complex bug will probably require some trial and error to make everything click, so a tester must test "sympathetically" in the early stages, more “aggressively” as the program takes shape, and “meticulously” in the final stages before the customer sees it. Being meticulous too early can really hurt the early stages of development. Dave Olson, in his 1993 book, Exploiting Chaos (Cashing in on the Realities of Software Development), also noted this effect: "Don't assign a 'total control' person responsibility for the early design stages of software development. This level of control early in a project is dangerously stifling to the overall effort." Now for the caveats.

Subject matter experts can actually have too much programming knowledge. By definition they are user advocates, so the perspective developed through their programming experience can interfere with this primary objective. Or, the tester may actually be an aspiring developer who took the QA position to get their foot in the door. In working closely with developers they may suggest solutions that will affect their ability to maintain an independent point of view when testing the program, because they now have a collaborative stake in its success. Maybe this particular tester's career goal should be one of the other test specialties, like automation or system performance expert.

Once in 1998, in a course called Software Testing and Quality Assurance, the instructor, Ross Collard, told his class that "There is no substitute for subject matter expertise on the testing team." He also listed "QA and Testing Techniques” and having a "Technology Base” as the other two skills needed for success. I think Ross is right. And I believe testers who consider themselves subject matter experts should ground themselves in programming skills and the cultural attitude that surrounds this interesting profession. It can really improve your relationship with the developers, and make your job a whole lot easier.

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.