UAT Procedure (clients report feedback via doc) – Draft

1. Purpose

The purpose of the document is to provide all needed information before the User Acceptance Testing (UAT) phase that includes readiness of build, test ware and instructions on how to work during the UAT phase.

2. Environment list

3. Browsers/Devices

4. Requirements references

5. Testing documentation

6. Known Defects

This section describes all defects which were found during the QA phase.
IMPORTANT: Please use this information to avoid duplicates while creating defects within the UAT phase.

<link to Existing Defects in Jira> – here you can find all open /in progress /resolved defects during the QA phase of the project.

<UAT Defects Board> – here you can find all issues found by the client team during UAT.

7. Types of tickets will be used

• Bug – an issue that shows a difference between the site and designs. Sometimes it can be irregular behavior.

• Task as a Change Request (appropriate "CR" label should be added to the ticket) – an issue that comes from Bug or recommendation. Need discussion with the client and approval as well (see <link to Change Request Log>). Type of issue to implement or update already implemented functionality or to develop the new one.

8. Process Flow

This section describes recommendations to organize the UAT phase that can help to avoid misunderstanding and improve efficiency in communication and problem solving.

8.1 UAT Timeframe

The UAT will last from dd/mm/yyyy till dd/mm/yyyy. During this time all the reported bugs and issues will be investigated by the Development team and qualified as Bugs or Change Requests. The bugs will be fixed in the order of their priorities. If the team will not have time to fix all bugs by the end of the UAT phase, the lower priority bugs will be transferred to the post-launch warranty phase.

8.2 UAT Entry Criteria

1. UAT environment is up and running.

2. Resources are sufficient and available to support UAT.

3. Roles and responsibilities are identified.

4. The UAT procedure is defined, the communication flow is agreed.

5. UAT Procedure page is available (link to be provided via e-mail).

6. Reporting-related specifics are agreed.

7. UAT exit criteria are revised/defined.

8. The component testing for the planned devices and browsers has been completed.

9. The regression testing for the planned devices and browsers has been completed.

10. All bugs with priority blocker and critical have been fixed and closed.

8.3 UAT Exit Criteria

1. All planned UAT test cases have been executed and passed.

2. All bugs with priority blocker and critical have been resolved and re-tested.

3. Any remaining priority bugs have been placed in the development schedule.

4. Any CR’s/overlooked requirements have been negotiated and a plan is in place for addressing them.

5. Successful executive go/no-go decision for launch.

6. Planned reporting and analysis have been done.

UAT should start only when:

• Project Development phase with all planned Development activities is finished for all Site Components.

• UAT Entry Criteria are met.

otherwise timeline needs to be revised.

Note: To get enough time for the bug-fix during the UAT phase it is strongly recommended to report found Defects for the site Components/Features right after it was found/discovered, to not get lots of JIRA defects reported during the last UAT days. If the development team will get all found defects reported in JIRA only during the last UAT days, there will be no possibility to fix them and retest till the Release Date.

8.4 Communications during UAT

UAT Sync-up meetings will be scheduled according to the UAT Timeframe.

All defects/issues found by the client will be shared via spreadsheet using prepared template (<link_to_spreadsheet_tempwwlate>).
After some investigation and agreement those defects/issues should be reported to JIRA (by QA).

Click Create Issue, do so through the <link to the project in JIRA> and follow the instruction below:

NOTE THAT

• Point Preconditions is optional and filled when the additional configuration is required to reproduce the bug. (Ex. Product with a specific variation (or allocation) is configured. Specific promotion is configured);

• Point Additional information is optional and filled only in case of some additional info is required to reproduce the bug OR in case of any additional places where the issue can be reproduced.

9. Ticket Flow

Development team will work with UAT issues according to the priority of the issue (from highest to lowest), so please pay attention to the Defects priority section below when selecting issues priority.

Initially clients report and send feedback via spreadsheet using a prepared template (<link_to_spreadsheet_template>)

After some investigation items from a spreadsheet can be:

1. Raised as bugs in JIRA (if the issue is clear enough):

a) QA creates a ticket in JIRA and assigns it to the responsible BE or FE developer and marks the appropriate item in the client’s spreadsheet as In Progress;;

b) after fixing the defect, Developer assigns it to QA for verification in “Ready for Testing“ status:

– QA approves that fix is acceptable, moves the ticket to “QA Approved“ status and marks the appropriate item in the client’s spreadsheet as Fixed;

– client verifies the issue in the spreadsheet:

* if it is fixed – mark the item in the spreadsheet as Done, then QA moves the appropriate ticket to “Done“ status in JIRA;

* if it is not fixed – mark the item in the spreadsheet as Reopen, then QA moves the appropriate ticket to “Opened“/“Reopened“ status in Jira and backs it to the developer;

2. Returned to the client with a comment (it can be: Done, Cannot reproduce, Won’t Do, Duplicate, etc).

In this case the client can:

a) Close item in the spreadsheet (mark as Done) if it is clear per comment → then QA moves the appropriate ticket to “Done“ status in JIRA;

b) Reopen item in the spreadsheet (mark as Open) if the issue is still valid → then QA creates a ticket in JIRA and assigns it to the responsible BE or FE developer (see actions described in #1).

3. Defined as CR (change request):

a) QA sends the list of CR items to the PM

b) PM discusses with the client

c) Approved CRs are created as tasks in JIRA (with “CR“ label) and processed according to the workflow (see actions described in #1)

10. Defects priority

Priority shows the degree of importance for the business to resolve the issue. In other words, the priority is driven by business value and indicates how soon the Issue should be fixed.