Notes On Software Testing Habits

In LinkedIn, I recently forwarded a post by Martin Lush entitled “Don’t Blame the Person – Fix the System!” One outcome for me from that is that it started a variety of side conversations with other people in the industry. One area of conversation that came up is that of testing, as a general topic and, today, I want to share my own thoughts on testing.

Regulated Versus Non-Regulated

Software must be tested properly whether it goes to a regulated or a non-regulated area. If your project is not a regulated project, you still need appropriate testing. The main difference is that the regulated implementation gets more specific documentation with more specific names and structure than a non-regulated project might. With that, the non-regulated project doesn’t necessarily get less documentation or less structure, but it is dictated more by good software lifecycle management practices than by a regulatory agency.

The Purposes

There are several purposes for doing a rigorous job of testing software. If you’re regulated, it’s because you must show that your system is in-control. But for any system, at all, the purpose is so that it does what it’s supposed to do (which is really just what being “in control” is about, if you think about it).

We should never have the idea that our users should test for us. By the time we get to user acceptance testing, regulated or not, we should feel we have done our best to eradicate errors. And then, we must prepare ourselves for the errors the users will find and ensure we have proper time allotted to address those because their tests will be different than ours and will find a different variety of issues – issues that we might have missed.

General Good Habits

For those out there who say it doesn’t apply to LIMS, ELN, LES or SDMS systems or because their system has “configuration” or “scripting” instead of code, that’s not entirely true. Some configuration is so complex it must be tested. Some “scripting” creates more programming than if we just used some standard programming language. So, we can make excuses to avoid testing but that’s all they are is excuses.

And to those who say “I can’t because I don’t know how” then you just have to learn how to do it. Get out there and talk to the others in your industry about what they do and learn from them.

If you’re putting together your project plan, right about now, or if you’re getting ready to do any type of testing, there are some good habits to follow. In my next blog post, I will make a short list of a few things I believe to be crucial to this effort.

Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/