How do you perform critical process testing? Critical processes are sensitive to any failure, not just the major ones we tend to worry about most. When your products get out into the real world, they encounter a mix of simple, complex and very complex environments. Likewise, they are often used in a mix of simple, complex and highly integrated workflows.
“Any failure” is often an easily overlooked, simple little environmental thing. These little things didn’t cross someone’s mind early enough in the design, creation, production and testing processes. The simplest oversight or miscalculation about the nature of environments can easily derail a complex product.
Can’t see the forest for the trees
A rather disconcerting programming-related comment I’ve heard for decades is “Works on my machine”, otherwise known as “WOMM”. In context, the full comment might be “I tested the program and it works fine on my machine.” Unfortunately, that doesn’t mean anything. As Mike Tyson has said, “Everyone had a plan until I hit them.” Likewise, every program has been “tested” until it has been deployed.
A WOMM comment implies that the program wasn’t tested in an environment more complex than the one used to create it. In other words, testing wasn’t anywhere near as comprehensive as it should have been.
Don’t be so quick to think that your shop is immune to this simply because my example refers to software. A marketing process or sales process is just as likely to suffer from a lack of proper testing. This is the classic “Can’t see the forest for the trees” situation. Those creating your products are often focused too close to the product’s development to truly understand how it is normally and properly used in the field.
Management has a testing responsibility too
Not understanding how your products and services are used in the field is a disadvantage for your creative team. A frequent problem with all testing (not just critical process testing) is that it occurs too close to the environment used to develop the process. I’ve mentioned that I often proofread a written piece by reading it aloud. I do this because the use of a second media reveals obvious problems hidden by familiarity with a piece. Adding environments to your testing process is a similar tactic.
An instrumental part of your testing is making sure that the shifts in environment are properly covered. If your teams aren’t exposed to the reality of the environments where your products and services are used, it’s more difficult to take them seriously – much less know those environments even exist.
Making this happen is management’s responsibility. Allowing your creative team to spend the money and time to experience the real world environment where their products are used is huge. Taking a step beyond that to allow time for testing in real world scenarios and environments will pay huge dividends. These investments pay off in both product quality, and with the vision of your creative team being more in touch with your clients’ reality.
Whose responsibility is multi-environment critical process testing?
Your creative types (programmers, engineers, etc) may feel the duty of testing on a broad range of environments falls entirely to your quality control team. After all, your quality control team is usually tasked with a mix of testing new changes and testing for regressions (ie: new problems created in existing functionality) across many different environments.
That might seem the same job as developing in and for multiple environments, but it isn’t. When complex environments are involved, your programmers, engineers or other creative folks might often think their time is too valuable to spend creating and testing on a number of different environments. They have a point, but that doesn’t mean their development has to occur in the simplest environment possible. Left untreated, product creation will occur on the systems and tools closest and most familiar to the creative team. This leads to WOMM but also to designs that don’t reflect the reality of the environments where your creations are actually used.
The real world is far more complex any single programmer or engineer’s work environment. If you aren’t providing a range of ready to use work environments for them, the natural thing is for them to use the tools that are already available. This isn’t ideal for them or for your clients.
Think about and invest in your creative people and critical testing process: Expose them to reality.
Want to learn more about Mark or ask him to write about a strategic, operations or marketing problem? See Mark’s site, contact him on Twitter, or email him at [email protected].