You receive a patch (with release notes) to fix a couple of bugs in your ERP. Do you really need to test, or can you just install the patch? If you install without testing, then you introduce the risk of having unintended results/consequences. Does that risk outweigh the time savings of not testing?
IT is responsible for understanding how the system is intended to be used and will do some of the testing but not all of it. IT performs testing such as unit, integration, and system testing. The business is responsible for deciding what/how to use the system. Since the business owns the system, they have testing responsibilities too and are responsible for user acceptance testing (UAT).
3 Key Components Of Testing
Bigstock
The testing effort involved will vary depending on the type and size of the change (e.g., patch/bug fix versus major upgrade/release), but the testing process is typically pretty consistent. There are three (3) key components:
1. It starts with having a test environment separate from the production environment. Individuals can enter different practice workflows without affecting production. Not only can the test environment be used for testing, but it can also be used for training purposes if it’s not cost-effective to have a separate training environment.
2. Creating comprehensive test documents (test plans and scripts). Test for items such as required fields, valid values, and date ranges. Also doing regression testing and stress testing as well as testing system performance and interfaces. The business should specifically test different scenarios from “cradle to grave,” common processes making typical user mistakes, security profiles (including those who shouldn’t have access), reports, etc. Yes, the business should have written UAT test plans/scripts so that they know what they did (and didn’t) test.- Tip #1 – create and use a meaningful naming convention for the test plans/scripts. It will make it easier to identify the purpose of each document without trying to figure it out by reading the entire document.
- Tip #2 – create a description for each test plan/script including creation date, security role, and any special data requirements needed to perform the test.
3. You need to have sufficient data (corresponding to the test plans/scripts) in the test environment to test properly. You can create data manually or use an automated test data generation tool to create test data. Another option is to copy production and obfuscate (aka obscure or scramble) any sensitive data.
Final Thoughts
Bigstock
Issues discovered during testing should be logged on an issues list, tracked, and remediated. Once the business has completed user acceptance testing (UAT), they should formally sign off that they approve. “Show stopper” issues are to be remediated prior to UAT signoff. Then the change goes through change management, and IT loads the change into the production environment during the next scheduled maintenance window (unless it’s an emergency).
When you have the three components, then you can continue building on them. With each change, you add/clone more test plans/scripts to the testing documents library. Over time, you’ll have an expansive testing documents library. So, the next time you have a single patch to install, does the risk of not taking the time to test really outweigh the possibility and inconvenience that a potential outage would cause?
For more information on the value of testing, follow me on LinkedIn!
