We recently completed two weeks of system testing, with key users from three continents assembled in a room filled with folding tables and chairs, a flip chart, and a makeshift screen for the overhead projector. Most had little exposure to the system prior to the start of testing, so the principal consultant began each section of the testing with a brief demo. They were then turned loose to test various scenarios. We prefer scenarios because there are a lot of ways to navigate through Workday, and the users learn more about the system by exploring and experimenting than they ever would from following a detailed, step-by-step script. But we needed to provide some structure, so during the first week we told them to “follow the Happy Path.”
The Happy Path is when everything works as you might expect it to. You get to a function in the natural way, as someone with the appropriate access rights, and you enter a sensible, correct transaction that is accepted by the system. On the Happy Path, you are testing the system to be sure that all functional requirements have been accommodated, and the business processes are correct, complete, and working as expected. The Happy Path is where the users will spend most of their time when the system is in production, and following it gives them a high degree of comfort with the software, their roles, and the results they see. It’s also a good way for them to learn the system well enough to train their colleagues, once the system is live. Then we began week two by telling them to “follow the Trail of Tears.”
The Trail of Tears, also called negative testing, is where we ensure that people can’t see data or functions they aren’t supposed to see. It’s where we enter false data to ensure the system edits objects correctly, and try to do things out of order, to be sure the system enforces the process rules. On the Trail of Tears, you are testing the system to be sure that all of the non-functional requirements, from security to error handling, have been accommodated. The Trail of Tears is where the users may find themselves unexpectedly, and they need to have confidence that the system will keep them from falling off a cliff, or making an unrecoverable error. Following it gives them confidence in themselves, and further improves their ability to resolve problems in production, as the key users and mentors to their colleagues.
Done correctly, system testing is a major step in ensuring that the user community will have the ability to use the system in production, and support others. It gives the user base a good feeling about the changes to come, or it gives them the chance to articulate their concerns. But maybe more importantly, it gets buy-in from the ones who had been sitting on the fence. We had a couple of folks come in with serious doubts, who left after two weeks with Kool-Aid on their breath and smiles on their faces. And all of those little issues that they identified (and we fixed) during testing are just icing on the cake.