Dedicated testing teams

When preparing a new piece of software or tool, it’s essential to test the software or tool and get the input of the people who will be using it in production.  This ensures that the software or tool is ready for production and that it will be useable for those who will be using it.  The major issue comes when you test in production.  Testing in production has several drawbacks and can lead to an inferior end product.

The drawbacks of testing in production

When you test a new piece of software or tool in production you are forcing workers with quotas to slow down to document errors and even stop working completely to write a report on the error.  This places unneeded stress on the worker and some may decide that the error isn’t worth documenting because they are already behind and doing the proper documentation and reporting would place them farther behind.

Errors going unreported leads to the second drawback of testing in production.  When errors go unreported they will be rolled out to the entire workforce and cause problems for all workers.  Not only will this lead to a reduction of output by your employees but it will cost more in lost revenue and the extra costs associated with quick remediation.  If you are testing a physical tool then it could be even more costly as you may be forced to remake all the tools for a second time thereby doubling your cost.

All this leads to the workforce having doubts about their leadership.  When workers start to doubt their leadership they will become apathetic about their work, and may even decide they need to start looking for a new job.  This could lead to highly skilled and valuable workers leaving your company and potentially going to work for a competitor.

Dedicated testing teams

The best way to avoid all these drawbacks is to build a dedicated testing team.  First, you select workers who would be best at testing the new software or tool and separate them from the rest of the workforce.  Then you explain that during the testing period, they have no quotas, they are free to stop and document any issue they come across for as long as it takes them to detail the issue.

When the testing team knows they have the freedom to stop and document issues without the need to meet quotas they will be more likely to report small issues that could derail the whole workforce once it’s rolled out to everyone.  It’s also a good idea to go over this idea with them prior to the testing phase beginning so that they will understand what is expected of them.

Keeping legacy software and tools

It’s a good idea to keep legacy software and tools in place after the rollout of the new software or tool to the entire workforce.  Sometimes errors will not come up during testing and the only way to resolve the issue will be to revert to the legacy software or tool until the issue can be fixed.  While this may be costly it would most likely be more costly to not be able to deliver your product to your customer because you had no way to revert to a legacy system or tool until the issue was fixed.


While there will likely be a cost associated with forming a dedicated testing team, the cost of not forming one can be even higher.  Not only can this approach save money associated with lost revenue when new software or tools are implemented, but it can save costs associated with worker turnover.  When a highly skilled worker leaves you not only lose a high-output worker but you have to pay the costs associated with hiring and training only to get a lower-skilled worker as a replacement.  The cost-benefit ratio on dedicated testing teams leans heavily in favor of the testing teams.

Like what you see?

Sign up to receive new posts in your inbox, every month.

I do not spam! Read my privacy policy for more info.