Once you have completed your software development, our basic test cases and relevant advanced test cases and penny testing you may proceed to conduct final UAT with your stakeholders. We will provide them with access to BankTech if required so that they can explore the developed functionality and confirm that it meets their requirements before approving go-live with your production volumes.
In simple terms, acceptance criteria are a list of things that are going to get evaluated before accepting the product. Ideally, acceptance criteria should elaborate on the UAT test cases defined and provide unambiguous definitions of done so that developers and the project team have clearly defined stage gates or deciding whether or not to go live. These do not have to be exhaustive if defined well.
I can register DebiCheck mandates
I can authenticate DebiCheck mandates
I can amend and cancel DebiCheck mandates
I can create a collection, edit and approve it
I can unapprove, recall and delete collections if I need to
My collections get submitted and processed (confirmed by penny testing)
I don't need to spend more than 2 hours a day doing all of these things
I can reasonably expect to process 10,000 payments a month this way
The project team should at minimum test the following:
Core workflow permutations
User experience objectives
Any contractual obligations
Small volume batches
Large volume batches
Any new functionality
An appointed Product Owner or Business Analyst with technical expertise is the ideal delegated authority to approve UAT as they will have the necessary high-level business and low-level technical understanding to ensure that objectives are met. Additional sign-offs are recommended from design teams, business owners, stakeholders and ideally end-users to improve impartiality and learning feedback.
The short answer is you should test as often as you reasonably can. Each project's size and complexity will be different, so you will need to choose a time interval that gives you sufficient time to make a meaningful increment with your progress and have enough confidence in it's capability to warrant performing the test cases. In general, we suggest you do this every two weeks for best results.
For some projects, you may only need one UAT session. This is typical for smaller Agile projects or larger waterfall style development projects where requirements are well known in advance and the project team can reasonably be expected to pass UAT on the first attempt. However, more testing is always better, so ultimately testing frequency depends on where your development team feel comfortable.
Failing UAT testing should not be seen as a project failure. Testing is a learning opportunity to increase the quality of the product and ensure it meets the objectives of the end-user and the business. Frequent and detailed testing allows for progress measurement, effort prioritisation, delivery date estimation and feedback to be gathered. Therefore, teams should take an iterative approach to testing while developing.
Not only will failed UAT communicate to your stakeholders that you are taking testing seriously and gather valuable information to improve the ultimate product delivered, but it will instill the necessary confidence in your solution to behave as expected. Regularly demonstrating and testing your software with stakeholders will also help everyone stay aligned and improve the overall level of satisfaction.