As for more complex projects 2 weeks of UAT is not enough, here is an example of how longer UAT can look like and what it should contain. Note that 6 weeks of UAT mentioned here must be planned at the beginning of the project and it is just an example of longer UAT for bigger projects. The basic expectations here are the same - the customer should still have an overall responsibility for UAT, but QA analyst can help if it is required. Note that customer with customer is still crucial, he must be aware of his responsibilities and understand that they must be prepared for UAT before he really starts with testing. Otherwise he will find out that even 6 weeks is still not enough time for completing UAT tests on time.

Prerequisites before going into UAT

• All unit testing during Feature Sprints has been properly done; the UAT is not a repetition of the unit tests. A UAT is an end-to-end test and customers should not find bugs that they should have uncovered during unit testing

• Customer accepted all user stories in the scope - it means he confirmed they were developed and tested in Feature Sprints

• All end-to-end tests scripts have been prepared

• All production level data is loaded in the UAT environment, including all company parameter tables

Types of issues that can be found during UAT:

• Data issues (master data or company parameter data)

• End-to-end issues (typically these are requirements issues)

• Regression issues

✅ All configuration bugs should have been found during the unit testing!

Tasks before UAT

These main tasks should be done after the last Feature Sprint and before UAT phase:

• Training and preparation - final preparation for UAT, training of UAT testers, checking that everything is ready

• System Integration testing - testing integration between Pfx sw and customer’s internal systems

Tasks during UAT

These main tasks should be done during UAT phase:

• End to End testing - based on business cases , should cover main functionality and integration, this should not be just repetition of testing during Feature Sprints

• Bug fixing and retesting - checking that all founded bugs were properly fixed

• Final regression testing - final check should be done during Code Freeze after bugs were fix and retested, most important tests should be repeated here

End of project in details

→ from Feature Sprints to Go-Live

The last Feature Sprint

• finish development of all user stories - mandatory for continuing to UAT

Pre - UAT

• 2 weeks

  • Preparation and UAT training week

    • testing of the latest user stories

    • accepting user stories in Jira - mandatory for continuing to UAT

    • finish preparation for UAT - mandatory for continuing to UAT

  • System Integration testing

    • final checking of all integrations

    • UAT testers are ready for testing

UAT (2 to 4 weeks)

• E2E testing (up to 2 weeks)

  • functional testing based on prepared UAT test cases

  • logging bugs to JIRA

  • fixing reported bugs

  • all prepared test cases should be tested during this part

  • testing from top priority and the longest tests to less important and less complex tests

• Bug retesting and bug fixing (up to 1 week)

• Final regression testing (up to 1 week)

  • Code freeze in this time

  • for checking all critical test cases again

UAT phase should end by final acceptance and official Go-Live

The following tasks should be done during 6 weeks of UAT for a 5 sprints project (see the table at the bottom of the page for different project sizes):

• Complete training for UAT (Kate’s team or project team?) - 1 w

  • finalize UAT test cases

  • show to UAT testers what is expected from them

  • demo for UAT testers on QA partition

  • show to UAT testers which test cases they will test

  • let UAT testers do first testing and help them with first questions or issues

  • choose test management tool and leader of UAT testing phase

  • make sure everything is ready for UAT - access to all tools and environments, login credentials for UAT testers

  • Pfx: finalize bug fixing from the last Feature Sprint

  • Complete initial data loads in QA & data verification

• Complete Integration testing 1 w

  • check that all integration works correctly on QA partition

  • let UAT testers do first testing and help them with first questions or issues - they should feel comfortable about what is expected from them at the end of this week

  • make sure UAT testers have final version of E2E test cases and they are ready for testing

  • log bugs for integration issues to JIRA

  • Pfx: fix integration issues

  • retest bug fixes and confirm the integration is working at the end of this week

• Complete E2E script testing 2 w

  • 1st w:

    • start testing based on E2E test cases

    • top priority and long test cases first

    • log bugs to JIRA every day

    • report progress to UAT test leader every day

    • Pfx: bug fixing if possible - deployment should not be done during UAT testing

  • 2nd w and all other weeks:

    • continue testing based on E2E test cases

    • all test cases should be finished this week

    • log bugs to JIRA every day

    • report progress to UAT test leader every day

    • Pfx: bug fixing if possible - deployment should not be done during UAT testing

• Complete Bug fixing (requirements or regression issues) - 1w

  • Pfx: finish bug fixing, deploy all changes to QA partition

  • prepare scope of final week - bugs for retests, test cases to be tested again

• Complete Bug testing - 1 w

  • final part of UAT

  • prepare scope for final regression

  • retest all reported bugs to verify they were fixed

  • retest selected UAT test cases to verify the application is working correctly on QA partition

  • log bugs to JIRA every day - there should not be any new issues this week, so just in case

  • report progress to UAT test leader every day

  • final regression testing after bugs were retested

Examples of project timelines and allocations