Developers tend to be notorious at avoiding testing activities. Any excuse will do. “The dog ate my test script.” “The test script ate my dog.” It doesn’t have to sound likely — really, ANY excuse. But testers are not just important to the testing process, they’re mandatory participants if the entire process is going to work.

Let’s begin with the concept that we work toward no user ever seeing an improperly-working program. It’s not possible, but it’s the goal we word toward.

First of all, there is unit testing. Every developer must be their own unit tester. Unit testing, at its most basic element, is the opportunity to beat the living daylights out of a program. Nobody can possibly know all the paths as well as the person who wrote those programs, i.e., the developer. When I worked with totally custom software, we would write test scripts and a team would review the script and, possibly, an independent person would run it. We don’t have those teams when we’re implementing purchased software changes for our customers. Thus, it is the developer, themselves, who must verify that the program works in a robust manner. The word “robust” is used by programmers to indicate the program is sturdy — that it won’t fail when used. Each time changes are made, and this is where we separate the truly committed programmers from the lazy ones, but the unit testing much be redone after each block of changes.

Right now, you’re wondering if someone independent of the programmer who wrote the programs should give them a sanity check. Yes, now that the program is unit-tested, someone should check that it works well for the process in which it was intended to be used and someone with a fresh view of it, i.e., not the person who wrote the program. The ideal person would be one of the project’s business analysts. They should know the business process better than the programmer and are independent of the program. They are usually the best choice to check the program out. And, this gives the team yet another chance to look for errors before any user tries the program.

The reason we try to get all the bugs and process errors addressed before the user gets the program is two-fold: 1) The user is not a unit tester. They should not be expected to figure out common program errors. 2) The more errors the user sees, the less confidence they will have in the final program and, thus, possibly less likely to sign-off.

Past all of this, if the project is a large project, the developer will be required to participate in other testing activities. If the project is a regulated project, developers are likely to be involved in writing and/or running OQ (Operational Qualfication) scripts. If it is not a regulated project, there are a variety of names, such as system testing, integration testing, system integration testing, and other testing stages.

On the smaller LIMS and ELN projects, we sometimes have developers who aren’t interested in testing. It shows when they try to get the users to use the system, and the users are seeing problems. Usually, this type of problem can’t be tolerated on large projects. But user on the the small projects don’t deserve crummy programs, either, nor do they deserve to be given a pile of junk to work with. Those people who work hard to deliver the best work they can for every project deserve some recognition. I would like every customer reading this to stop and think about the programs their receiving and to stop and tell the people involved what kind of service is being delivered, good or bad.

For me, I’m not looking for some kind of recognition from my customers (really), it’s just that I want all customers to be very aware of the difference between getting what they SHOULD be getting and understanding how to recognize when they don’t get it so that they can demand it. As I’ve said many times to customers, before, “It’s your money — if you don’t ask for the most from it, no-one else will do that for you.” So, if you as a customer accept crummy deliverables, if you don’t care, why should anyone else care for you? We’re supposed to all be professionals and deliver our best for you, but not everyone does that and if you accept crummy service without compliant, you’ll definitely get more of the same.

Gloria Metrick
GeoMetrick Enterprises