System Testing Roadblock: Test Scripts

When it comes to conversion projects many organizations have failed to prepare themselves properly before the vendor project manager engages. The typical scenario I’ve seen is the vendor project manager kicks off the project, gives a laundry list of required ‘homework’ for the organization to complete, provides high-level guidance on other tasks without detailed instruction and then exits for a few weeks leaving their clients a little shell shocked. The organization then has the hard realization that they’re already out of time and resources to get all the work done and starts looking for short-cuts to complete tasks. One of these short cuts is always regarding test scripts and it typically comes in two flavors: “Does the vendor have test scripts that we can have?” or “Can I get test scripts from other clients that I can use?”. On the surface these both sound great, but if the organization has a strong partner to guide on the topic and is willing to listen; they may realize that they’re missing out on a great opportunity by having their own team build the test scripts. Let me break this down further:

“Does the vendor have test scripts that we can have?”: Of course the vendor has test scripts but many times are unwilling to depart with them, however I’ve seen a few vendors who will offer them up. My question is why would you want them? Vendor test scripts are very generic scripts that only account for basic features and functionality in the system. They’re designed to provide their quality assurance team with consistent and reliable results for managing releases. They’re not designed to capture unique scenarios that every client has in their configurations. Furthermore, why do you want to test all of the same scripts that the vendor has already completed? In theory this would only provide you the same results that the vendor has found and are working to remedy.

“Can we get test scripts from other clients?”: Many of my clients are happy to share their test scripts with others but you may be inheriting more work than you bargained for by going this route. You’ll need to review each script, understand it and modify it for your unique set of configurations. You also need to shore up the list for anything that is missing and throw out ones that do not apply to you. In my experience when lists of processes are provided that are generic to organizations the feedback has been that the list was overwhelming to review and would have been easier to start from scratch. If you apply this logic to test scripts I would assume you would have the same reaction.

In conclusion my vote is always to have organizations build their own testing scenarios and scripts to capture the unique processes, procedures, products, interfaces, etc. and make sure the software is working for them. To do a solid job of this you need to start early before the vendor engages because waiting until kick off your teams will struggle to keep up. The spill-over benefits in developing your own scripts are vast but the top of the list is: More employees that understand the new system and will be subject matter experts for years to come, stronger front-line employees who have depth of knowledge and consistent procedures, and accountable business partners that understand their procedures and the functionality of the platform.