Once we have built the software and integrated it as we would like it to operate into our system architecture, it's time to test it and make sure it works properly. The goal here should be to break the system. We want to conceptualize and test the system in various ways to ensure it’s ready before we go live. To begin, there are a few different components and iterations of the live testing cycle. The first of that is called unit testing.
When undergoing unit testing, the focus is primarily on making sure that the technology itself works. Through this process, we will evaluate every microcosm and functionality of the overall technology. We want to make sure that no codes have been broken through customizations, confirm configurations across the entire system, and ensure that data is flowing through the system correctly. Unit testing ultimately comes down to testing different elements of the system itself to confirm functioning prior to moving on to the rest of the live testing phases.
Once we can confirm that the system is, in fact, working correctly, then we move on to integration testing. This is where the individual pieces of the system's web are tested. We will explore how each integration of different systems works with the new software. This is typically done through end-to-end testing. Going back to the example of testing an order lifecycle from the moment the sale is closed to the manufacturing process entails multiple systems to talk to one another. In this scenario, the CRM would likely transmit data to the ERP system, and the ERP system would distribute relevant information to the HCM system for commissions and payroll and to the WMS system for manufacturing.
In integration live testing, we are testing end-to-end processes through the new system architecture. This exercise will highlight any areas that need attention and TLC before moving on to go live. The last thing we want to do is go live with a new system, only to have a broken integration somewhere within our system architecture, disrupting our operations as a whole. Once we have tested various scenarios, we can move on to user acceptance testing.
Business and user acceptance testing, oftentimes called conference room pilots, are less focused on technology and more focused on making sure that the business needs are being addressed. It also explores whether or not the business processes will work in a way that will tie in all three pillars of our transformation efforts: People, processes, and technology. Essentially, this element of live testing will be a business simulation to determine what it would look like to use this technology within a production setting. This is the final phase of testing to make sure all looks good and the kinks are worked out before going live.
