Base User Acceptance Testing - A Unique Approach to Implementation Testing
The fourth stage in TML Business Services' Accela Implementation Methodology is Base User Acceptance Testing
Base User Acceptance Testing is just like it sounds, testing of the base configuration before reports are developed and interfaces created. Most vendors ask you to agree to the details listed in your configuration document before you've tested anything to validate the assumptions made during the analysis sessions. They also develop all of the supporting processes, reports and documentation before you begin validation testing. TML does not use this common approach because it is inneficient and leads to costly errors.
TML Business Services has purposely separated the testing of your new systems into two stages: Base User Acceptance Testing and User Acceptance Testing.
Base User Acceptance Testing is a combination of an introduction to the new procedures we developed together and the software system. It is a testing stage designed to validate the core functionality of your processes and software implementation. This allows users to validate the assumptions they made during the Analysis and Prototyping, and Build stages.
It allows your subject matter experts and management team to use the software system in a series of tests that use real-world scenarios to validate operational compatibility. This testing is conducted in a laboratory setting to minimize distraction and develop results in a controlled environment.
Here are some common activities performed during Base User Acceptance Testing:
- Running Test Scripts to Validate Processes - While your system is being prepared for testing, many agencies will develop test scripts to ensure the software performs as designed. TML can also develop these scripts for your agency, should you need us to. During the validation process, your staff uses these scripts to learn more about the software while validating its functionality.
- Knowledge Transfer and Training - When users understand how the system has been integrated with their business rules, they can better grasp how to leverage it. TML Business Services transfers knowledge to our clients who participate in testing by demonstrating answers to users' questions using scenarios that come from their daily activities. This increases the rate at which knowledge is retained and helps participants become comfortable with the new system.
The output that normally comes from these activities can include the following:
- Change Request Document - Used to request changes, to document in a single location all communication surrounding the change request, and to communicate the resolution of the request.
- Test Interrupt Reports - These are documents developed by TML Business Services that have been adapted from those used in regulated industries to work with information technology implementation. I have also expanded these documents to work with any testing process. They document systemic items that do not function as intended or that cause unintended results. Like the Change Request Document, this document allows for specific definition of the problem and tangible reporting of the solution.
As mentioned on the Build page, testing of any business process or software system often leads to change requirements being identified. This is a natural occurance that can have troublesome effects on a project if not provided for in the vendor's methodology.
TML Business Services is different.
My clients spend time testing in a controlled environment where I am available to answer questions and assist in problem resolution.
For a short time after these sessions users are allowed to continue testing. I have found that users discover enhancements, issues, and ideas when they are away from the structured testing and training environment. These discoveries are then communicated to the project team via proprietary change request documents developed by TML Business Services. The project team then determines the best actions to take and the staff to implement the changes.The team implements the changes and/or communicates the results to the person submitting the request per the project charter communication protocols.
Once this period is expired, and all issues have been resolved, the following items are completed in preparation for User Acceptance Testing.
- Software and communication interfaces
- Management and other system driven reports
- Data conversion and validation
- SOP Documentation
- Training documents
At the same time these systems are being developed, any physical facility reconfiguration is performed and training doucment is presented to the client for review and editing. This will lead us to our next step, User Acceptance Testing. If you want to learn more about TML's Accela Project Implementation Methodology, and how we can work together to help your Agency, call me today at (215) 280-9922. Or you can email using the information on my Contact TML page.
Engineering Department User
City of Madison, Wisconsin