Updated: Jun 29, 2021
Testing is probably the most critical phase of your project, whether you are developing a custom solution or implementing a COTS (Commercial Off the Shelf) application. It’s when the design and build meet the real world of the end users conducting their testing. Any veteran of project management will be able to share some horror stories of a design and build gone great that went sideways the moment it was put in front of the users for testing. 99% of the time this happens? It’s due to not adhering to the requirements and ensuring that they are all met with your solution. Here are some tips to make sure that when you present your solution to your users that it’s going to be met with cheers and fanfare for meeting all their needs.
Map Requirements to Test Cases
This is a painstaking exercise but well worth it in the end. Clients can have hundreds of requirements for an enterprise solution so it’s important to take the time up front to review those requirements and ensure that each one is accounted for when planning out the testing. Being able to successfully demonstrate and have users test functionality that is directly mapped to requirements is the heart of successful testing and system adoption.
Validity of Requirements
Once users see their requirements in a tangible system, often they may change their minds on either the importance of the requirement or more likely the use case associated with the requirement. Having specific test cases and scenarios outlined to demonstrate requirements helps ensure adoption of not only the solution but the business process that the requirement(s) outline as well. It also can be a great source of collaboration between yourself and your customer in terms of finding the perfect fit of requirements and functionality (be sure to mind your change control process!).
Acceptance of Solution
As a project manager this is probably the biggest item on your radar when it comes to end user testing. Having requirements mapped to test cases to help visibly demonstrate their pre-conceived requirements is paramount to system acceptance. Contractually your project is likely bound by the list of requirements (typically stated in an RFP that is responded to) and having successfully demonstrated all of the customers requirements with your solution gives you an (almost) ironclad way to ensure that system acceptance is a go.