UAT Procedure (clients report feedback via JIRA) – 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 need 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 should be reported to the JIRA.

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.

IMPORTANT: Defects that do not follow the template can be re-assigned back to their reporter in case of an unclear description. We encourage the UAT team to support any Bug report with a screenshot/attachment for better understanding.

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.

After some investigation and testing ticket can be:
1. assigned to the Developer for fixing (it means that the ticket is clear enough, so the dev team can work on it).
     2. assigned back to the reporter:
          a) Resolve ticket with specific status using comments (it can be: Done, Cannot reproduce, Won’t Do, Duplicate, etc). In this case the reporter can:

– Close (move the ticket to Done status) if it is clear per comment;

– Reopen (move the ticket to Open status) if the ticket is still valid.

3. after fixing the defect, Developer will assign the defect to QA for verification. There are two possible ways:
          a) QA will approve that fix is acceptable and assign the defect to the reporter for final verification (see actions described in #2);
          b) QA will reject the fix and will change the issue status to Reopened and assign it back to Developer.
     4. all fixes will be verified on the UAT environment by QA and assigned to the Reporter from the Client side with Ready for Testing status.

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.