Testing FAQs

We anticipate migrating student payments such as bursaries from payroll into an Accounts Payable Process, and will ensure appropriate testing for this process. Sam McKenney is our Process Outcome Designer representing Student Lifecycle within the Great Service Programme and is actively engaged with other Student Lifecycle workstreams across the university and relevant stakeholder groups to identify where the new system can deliver further improvements to student experience and student facing services and systems.

The implementation of a new system is a complex process. It is important to rigorously test each element of the new system throughout the project lifecycle to ensure that it meets business requirements and is fit for purpose. 
 
User Acceptance Testing has now started with colleagues from the Great Service programme team and subject matter experts from the Finance and People teams. It will be extended to a wider group of testers from mid-April. 

We are ensuring that we have representation from a range of different people from across the organisation to validate that Atlas meets business requirements. Those involved in testing will have roles and access set up based on what they do in their day job. 

Those involved in testing, will have roles and access set up based on what they do in their day job. Therefore, the processes they run and the scenarios that they test should align to their day-to-day roles. However, testers will also have the opportunity to discuss this with the programme team to ensure the processes with the most relevant scenarios are tested.

User Acceptance Testing (UAT) is where representatives from across the university test the Oracle Fusion system, known as Atlas, to confirm it works for the university’s real processes and daily operations and identify any issues before go live so they can be resolved.

Cycle 1 testing has now started with colleagues from the Great Service programme team and subject matter experts from the Finance and People teams. User Acceptance Testing will be extended to a wider group of testers from mid-April for cycle 2.

You will be added to the Great Service – UAT Jira project as part of the tester onboarding process. 

You will be sent the UAT environment URL on the first day of testing.

In cycle 2, we aim to align access closely with your production role and approval flows.

Our Process Outcome Designers will review the test suite for each area and allocate test cases based on your functional area, expertise and availability.

Yes, multiple people can run the same test case even if it is formally assigned to someone else. Each execution is recorded separately in Jira (who ran it, when, the outcome and comments). The latest result issued for summary reporting, but earlier runs remain visible in history and are not overwritten.

Many test scenarios deliberately include multiple roles, for cycle 2 we expect to use real approvers and properly mapped approval flows wherever possible.

Cycle 1 focuses on high‑priority, top‑level flows to confirm that the core configuration works (e.g. “raise a requisition for an academic role”). Not every variant can be tested in this cycle. More complex variations (e.g. multiple headcount campaigns, detailed accounting combinations) will be expanded and exercised more fully in cycle 2 and through additional scenarios, where needed.​

New scenarios should be meaningfully different (e.g. another process variant or risk area), not just the same test with slightly different data. Process Outcome Designers will review any proposals to ensure they are not duplicate or redundant before they are added to Jira.​

You will be given direct links to the Jira test executions for your area and you can use filters to see tests assigned to you.

It is expected that some scripts will have errors or gaps. If it is a minor wording or navigation issue and you know the answer, fix it. If you need help: speak to the relevant Process Outcome Designer or functional consultant (Namos lead).

If a step fails, mark the step Failed in Jira and use Create Defect from the test run to log the issue. Include steps to reproduce, expected vs actual results, key data and screenshots. The overall test case will show as Failed and the defect will appear in the triage dashboard.

Yes. Functional and technical teams need screenshots to understand what you saw and which transaction was affected (IDs, navigation path, error messages). 

You can propose a severity when you raise the defect. Final severity and priority are confirmed in the daily defect triage calls by the Functional leads, Test Manager and Release Manager.​

If you see a DM3 prefix in your email address, this is to prevent the test system sending out emails to people during testing. It is deliberately configured this way. 

The plan is to have regular releases into UAT (initially twice a week) plus a hotfix process for Severity 1/showstopper issues. The cadence may be adjusted depending on defect volume and risk.

Defects are fixed and verified first in a separate UAT support instance by functional consultants and the development team.

All testers are expected to complete:

• User Acceptance Testing introduction and ways of working
• Introduction to Atlas navigation
• Introduction to Jira (our testing tool)

Nominated testers will receive an email that will let you know which test cases you have been nominated for, and therefore which training modules you should book. If you are still unsure, please ask your Change Manager.

Yes recordings, slide decks and guides (including ClickLearn materials) will be available on our Sharepoint.