Delivering new PLM solutions implies series of solution testing, verification and validation, covering functional and non-functional requirements, from storyboard-based test cases to detailed methods, technical interfaces, data migration, upgrade and other deployment scripts. When it comes to functional testing, typical activities range from unit level testing to wider system integration and user acceptance testing (UAT).
User acceptance is a critical part of solution testing; UAT cycles are the ultimate formal sign-off of the solution, but testing starts in early iterations as the solution is being designed, built and commissioned. Enterprise platform deployments are not following software development cycles as they are not “built” as they get implemented. PLM, ERP, MES, CRM and other platforms are commercial off-the-shelf (COTS) solutions, configured, customized and integrated with the wider enterprise process landscape. Their implementations consist of tailoring use cases to support process adaptation and respond to data continuity requirements through interfaces with other platforms.
In this post, I elaborate on how UAT cycles are typically run when implementing PLM capabilities and platforms, and what it takes to ensure successful business sign-off of new business solutions.
The time always comes when PLM processes and platforms must be tested and validated by business end-users before implementation teams can carry on with deployment, cutover and other data migration rollout activities. UAT cycles are typically the final checks before a given project phase or sprint is to go-live. They include formal functional tests with representative data sets, validating ready-to-deploy methods and training material.
UATs are about “acceptance”, rather than only “testing”; this is because it should not be the first-time that end-users perform “hands-on” testing the solution. UAT cycles require end-users to formally sign-off the solution.
Implementing enterprise changes, extensions or improvements, from new processes, new automation to new platform capabilities, new interfaces, new standards, etc. requires business (i.e., user) testing.
- Testing starts with basic unit testing.
- Testing extends to system, interface, upgrade, non-functional, data migration testing…
- Testing covers to “system integration” testing, when all elements come together.
- Testing includes functional testing for approval, answering the question: “does the solution satisfy the business requirements?”
Points 1-4 above are all involving implementation teams, while points 3-4 definitely require the involvement of key-users who represent the voice of the customer.
Pre-UAT checklist
A typical UAT checklist is to cover the following questions:
- Have the relevant key-users been involved in discovery and early testing cycles?
- Have they been part of the “learning journey” and consulted on key decisions?
- What was their actual contribution in understanding and tailoring the solution, and are they supporting it?
- Have business leads been supportive and engaged in the decision-making process through formal governance?
- Is the business value of the solution understood and accepted?
- How have unit tests been conducted and what were the outcome?
- What will be tested during system integration testing, what will be the testing sequence, and how will be responsible for what?
- Are storyboards and use cases covered in the test cases, including elements which have been configured or customized?
- How many UAT cycles will be executed and how are they structured?
- Which end-users will be involved in signing off the solution during UAT and how much formal testing is required?
- What regression testing was previously performed and by whom?
- How will issues and resolution plans be managed?
- How will risks be managed and derived into mitigation actions?
Preparing for UAT cycles
Getting ready for formal UAT require extensive communication, planning and alignment across business leads, change leads, key-users, delivery teams and associated parties. Based on scope, relevant business functions must be involved in the process and play an active role is getting ready for it. This might include the involvement of suppliers, customers, procurement, also HR and other support teams.
UAT preparation typically includes:
- Release of final test cases and initial testing results, covering the relevant initial requirements (linked to business justification for reference).
- Communication plan and existing testing logs, known limitations and boundaries, aligning to solution design and functional requirement specifications.
- UAT schedules, critical success factors, acceptance criteria, outcome expectations and booking process.
- Test data readiness, including representative migrated data.
- UAT readiness countdown process (covering people, process, tool, data, etc.)
Running UAT cycles
UAT execution must be formal, yet friendly. Issues must be openly reported, whatever they are; some are bound to be discovered late despite early testing and initial preparation. It is important to triage issues on a daily or weekly basis and prioritize them as they are reported. Defining and implementing resolution actions will require an associated communication plan to formally closure tracking.
Not every issue might be a showstopper to signing off the UAT cycles; non-blocking might require a deviation plan and be addressed accordingly in due time, or possibly be handed over to the maintenance team once the new solution is deployed and transitioned to operations for continuous improvement. It is important to continuous balance the need for speedy delivery and the quality of the solution to be deployed.
What are your thoughts?
This post was originally published on Momentum-PLM on 30 March 2021.
Disclaimer: articles and thoughts published on v+d do not necessarily represent the views of the company, but solely the views or interpretations of the author(s); reviews, insights and mentions of publications, products, or services do neither constitute endorsement, nor recommendations for purchase or adoption.
About the Author
