What is User Acceptance Testing?

User Acceptance Testing (UAT) is a means in which you determine if the the changes being made fulfill the requested changes or updates. Enterprise Services (ES) does significant testing for each change in attempts to ensure that the modifications being made do not impact the operation of the application, but we doesn’t use a vast majority of the applications we create. We are unable to determine if the changes truly address your need for the modification or if the application is functioning correctly.

Enterprise Services testing involves:

• Does the application crash?

• Do all the functions accept the correct inputs and give the correct outputs?

These test ensure that the applications or changes made to it technically work, but if it isn’t meeting your needs, or changes the way you work, is the change successful?

UAT is a process of verifying that a solution works for the user.

UAT is the usage of the software by people from the intended audience and recording and correcting of any defects which are discovered. It’s the closest thing to a “real world” test available. It gives you the chance to interact with the software and find out if everything works as it should if features have been overlooked, miscommunicated, not communicated, and so on.

Why is it important?

The software that is deployed to production is yours to use and as close to bug free as possible. We cannot do that without your help! Your testing and approval of changes lets us know that we have completed the request.

What is my role?

As the application owner, your role is to coordinate testing. Testing may be simple or complex based on the application and changes that are being made. You may need to have coordinate with others to ensure all of the business cases that are impacted by the change are tested sufficiently.

What do I test?

This varies based on the changes being made. There will be changes that impact how an application functions, and there will be changes that will have almost no perceptible changes. The developer will provide you a summary of the change and what will be impacted. The summary may not be comprehensive, but we will attempt to help inform what needs to be tested. What will be identified are the roles of users who need to be involved in the testing and some of the larger processes, as we understand them, to be tested.

What do I do?

After you have completed testing you should be ready to submit an approval or rejection of the change. To complete this part of the process, please follow the steps below.

• In your web browser, go to “https://jira.cnu.edu”.

• Confirm your preferred language.

• If desired, upload an avatar (this step is not required).

• You are now ready to view tasks requiring your approval, click “Explore the current projects”.

• Click on your application’s name, you may have multiple projects.

• Click on the name of card identifier to see the preview (in this example, GRF-61 is the card identifier).

• The preview on the right hand of the screen shows the basics of the modification needing review.

• Click on the card identifier in the right hand preview (in this example, GRF-61 is the card identifier).

• The changes should be explained in the Description section of the card. Any testing that needs to be done will be noted as a comment in the card.

• After reviewing the contents of the card, under the “Approvals” section, find the “End User Approved” section. In this section you can click the green checkmark. 

• When approving the change, a comment is necessary in “Approval Comment” field. This is to ensure that approval is well documented.

• Your approval is noted in the “Comments” section of the card details

• On the “Kanban board”, the approval is reflected by the card moving from the “Review” column to the “Ready for Release” column.

Rejecting a change

• Click on your application’s name, you may have multiple projects.

• Click on the name of card identifier to see the preview (in this example, GRF-61 is the card identifier).

• The preview on the right hand of the screen shows the basics of the modification needing review.

• Click on the card identifier in the right hand preview (in this example, GRF-61 is the card identifier).

• After reviewing the contents of the card, under the “Approvals” section, find the “End User Approved” section. In this section you can click the red exclamation point. 

• If you need to reject the change, you must provide a comment in the “Approval Comment” field. This should outline the reasons for rejecting the change. Please include as much detail as you can, as this is what the developer will try to remedy.

• This comment should be written in such a way that it will help the developer understand what changes need to be made so the change can be approved.

• On the “Kanban board”, the rejection is reflected by the card moving from the “Review” column to the “In Progress” column.

• I’m not seeing the right projects

• Submit a helpdesk ticket at http://help.cnu.edu to have your account permissions checked.

• I’m not seeing the change I was notified about

• Submit a helpdesk ticket at http://help.cnu.edu to have the project configuration checked.

• I am seeing a lot of changes in the review column, do I have to review them all?

• Changes that need to be peer reviewed by the Enterprise Services developers are in the review column as well as the changes that need to be reviewed by you. You 

Change history