It seems that every discipline has its share of jargon.
You see it when accountants throw around terms like “EBITDA”, engineers speak of “TQM”, and I.T. staff reference “API” or “DMZ”.
These are the words and phrases used by specialists as they discuss their work. The beauty of this insider jargon is that it allows greater efficiency in communication, but it comes with the trade-off that it creates an ingroup and an outgroup who struggle to understand each other. And those in the ingroup are rarely aware of how it limits communication with those on the outside.
So, with that in mind, let’s consider six terms that are often used with Epicor projects. I’ve sequenced these common Epicor project terms, so they are linked together logically.
Test Scenario
When we implement new versions of Epicor, there is always a set of tests done to validate that the application is correctly supporting business functions.
A Test Scenario is the set of instructions, steps, and expected results used to do that. A “test scenario” might include who will do the testing, the objective of the testing, the sequence of steps to follow, the data entered the application, and the results that should be expected.
This information should always be available in printed form so that it can be reviewed and used by those doing the actual testing.
So, when you hear the term “test scenario” it is important to ask several questions. What is being tested? Who is doing the testing? What is not being tested? How will we know the test is comprehensive? What sequence will the testing be done in?
With test scenarios, there are several ways they can be applied, and it starts with our next term.
Unit Testing
In an Epicor project, there are two general types of application testing. The first is “Unit Testing” which is focused on validating stand-alone functionality that accomplishes a single task.
It answers business questions like “Can I enter a new vendor in Epicor and include all necessary information without issues?” or “Can I create a new Customer Payment Terms record?”.
So, we see that Unit Testing is always focused on a simple process that is relatively self-contained. It is simpler and usually easier to do but because it is so focused, there are usually dozens of unit tests required in a project.
But unit tests are not enough to accomplish the goal of thoroughly testing the Epicor application.
Cross-functional / Integration Testing
The second type of application testing, seen in Epicor project is “cross-functional” or “Integration testing”. While “unit testing” is focused on simpler processes, this type of testing is more complex.
It will involve testing transactions that process through Epicor from start to end. This could include accounting transactions, customer order transactions, manufacturing transactions, purchasing transactions or payroll transactions. Each of these involves multiple steps involving multiple departments to work well.
A common example of “cross-Functional testing” is testing all business processes required to move from a Quote to Cash Received from the customer. Within these two endpoints there are many distinct business processes involving multiple business areas (finance, order entry, engineering, customer service, purchasing, production, receiving and shipping).
This type of testing ensures that multiple business processes are supported completely by Epicor and that each business area in the organization can complete their work, validate the results, and manage exceptions that occur.
Together, “unit testing” and “Integration testing” provide the most thorough validation of the system. Which leads to our next term which describes how these tests are created and monitored.
Subject Matter Expert
A Subject Matter Expert (SME) is a person who is the most knowledgeable about a particular business process. They might be the Purchasing SME and understand each of the steps and requirements for successfully purchasing materials in the organization. That person would be able to describe the details and process for Vendors, Purchase Orders, Lead Times, Inspections, and Receiving of purchased goods. They literally are the expert on this area of the business and often have years of experience to back up their knowledge.
And SMEs are critical to the success of any testing done on a project because they know the business processes very well and can quickly spot gaps where the Epicor application may not be working well.
Typically, SMEs are responsible for specifying the requirements for how application software should function to best support the organization’s needs. And SME’s either build or review “test scenarios”.
This ensures there are no unexpected gaps between organizational business processes and the way Epicor operates. Ideally the “test scenarios” are designed so that application testers simply work through the steps, gather feedback and in the process, validate the needed functionality in the application. The Testers shouldn’t need to be experts on Epicor or all the business processes. Their skill should be in following the steps and verifying results.
When it comes to “cross-functional” testing, multiple SMEs are often outside their area of expertise. So they will collaborate with other SMEs to design an integration testing process that includes the best scenarios to support company needs.
All this testing and effort is usually grouped into specific timeframes in the Epicor project. One of those is User Acceptance Testing.
User Acceptance Testing
User Acceptance Testing (UAT) is the phase in a project where the application users work as a team, to verify that Epicor changes support all their business processes. Typically, the UAT is several weeks in length. During this time, selected application users will use multiple test scenarios (usually created by SME’s) to verify that all business processes are supported by Epicor. This will include both changes made and other areas that might be impacted. Both unit and cross-functional testing will be used.
All the results will be logged, and any exceptions will be documented and reviewed. The logged exceptions will become a list of issues that must be resolved before the organization can continue using the Epicor application.
The list of issues is then prioritized, and work is assigned to resolve them. They fall into these categories:
1. Modifications to Business Processes to better use Epicor capabilities
2. Modifications to Epicor to better adapt it to business needs
3. Some combination of #1 and #2
The purpose of the UAT is to fully test the changed functionality of Epicor to verify it meets the requirements for supporting the business in its new form.
This leads to a common question about the differences between User Acceptance Testing and the term “Conference Room Pilot”. Both terms are often confused.
Conference Room Pilot
A “conference room pilot” (CRP) is focused on testing the functionality of Epicor with the intention to identify the differences between it and the needs of the organization.
This means that it can be done at two points.
One point is before the system is chosen and when the organization is still in the procurement steps of purchasing an ERP.
The second point is at the final point of implementation when the focus is to confirm that the needed business process functionality of the organization is fully supported by the data, configuration and customizations made to Epicor.
If the answer is “yes” then the system is moved to Production status. In this situation, the CRP is the final “gate” before the Epicor application is used for company operations.
The CRP does share similarities with a UAT. Both look at Epicor from end-to-end, both include demonstrations of functionality, and both often include non-functional testing (such as performance).
But they differ in that a Conference Room Pilot is measuring where Epicor meets the business needs and where the gaps are, while User Acceptance Testing is confirming any changes made are working as specified.
When upgrading Epicor from one software release version to another there is usually several User Acceptance Tests that verify that the Epicor application has no errors. Then as a final step, there is a Conference Room Pilot to confirm that Epicor supports the full business functionality needed.
