After having supported many customers for the past several years, I look back at some of the more critical issues and quickly recognize that most of these could have been resolved (or certainly avoided downtime) had the customer employed reasonable and simple testing.
The one recurring theme is the amount of implementation work that is performed without equal efforts applied to testing that work. One would expect that any configuration with impact on company reputation and revenue would be tested to its’ fullest potential before it is ever promoted to a production status. Schedules and deadlines do not always allow for intense sessions of testing and debugging, however, there are many important yet unrecognized advantages to the testing process.
Let’s first look at some of the obvious reasons why a company might opt NOT to implement a testing plan as part of their implementation:
- Maintaining a separate test system is expensive.
- Migrating or “promoting” work from the test to production system is time consuming and could be a bit overwhelming, particularly if the configuration is simple and on a tight schedule.
- Keeping the test and production systems “mirrored” could be difficult to maintain, especially if many resources are tied to the same project.
Perhaps these statements are good reasons to bypass an adequate testing phase but let’s consider the repercussions of such actions.
An EDI Analyst has been given the task of implementing a new Trading Partner and Transaction into their application system. The addition of this new partner will yield high profits for the company (and maybe positive internal exposure for the analyst).
The company’s IT management informs the analyst that a test system has been made available, where the analyst could build and test the processes necessary for this implementation without concerns for interfering with day-to-day operations. Instead, the analyst exudes his/her confidence in this seemingly repetitive task and decides that testing would delay completion by forcing him/her to coordinate with other production operations and personnel. The analyst proceeds by building the work directly into the production system.
Fast-forward a few weeks.
The analyst is now one day from the deadline and the work is about to go live! He/she places the finishing touches on the implementation and, the very next day, they “flip the switch” to start receiving the EDI information from the Trading Partner. Aghast, the process does not work. Reacting quickly, the analyst begins to search for the problem. After a few intense moments, he/she discovers that the problem is occurring in a part of the process deemed the “heart” of the application. Making any changes at this point would require that all other portions of the implementation would either need to be redone or, at minimum, re-evaluated and retested. Meanwhile, the partner relationship has moved forward; data is flowing in but can’t be processed. The partner activation is placed on hold, revenue is lost, and the partner relationship has been strained.
This describes a worst-case scenario but is not uncommon, particularly when little emphasis is placed on the testing process. Perhaps this situation could have been easily avoided?
Let’s look at some of the advantages of having a test system:
- Building/testing a process on a test system will identify immediate areas for concern and expose any mistakes made during the implementation.
- Having a test system can also serve as backup in the event configurations would need to be restored to the production system.
- Building a test system opens the opportunity for creative thinking as different methods for implementation can be tested without affecting production.
In our scenario, had the EDI Analyst decided to use a test system and prepared testing procedures, maybe he/she would not have found themselves in this awful predicament. Unfortunately all potential benefits (both company and personal) were lost; a lack of confidence sets in and unneeded stress ensues.
Often, we do not realize the importance of the testing phase of an implementation. From personal experience I have seen this make or break projects. The next project you are assigned to, do not underestimate the importance of developing and including a thorough testing process.