ANDS AP24 BMRI Application - User Acceptance Testing (UAT) Strategy

1.         Background

Mental health and Neuroscience research programs associated with the University of Sydney headspace Services (youth mental health http://www.headspace.org.au), and the Healthy Brain Ageing programs are undertaken at the Brain and Mind Research Institute. Clients of the headspace program are offered the option of participating in research studies, such as those examining the diagnosis and treatment for major health problems like depression and psychosis. Subjects for the Healthy Brain Ageing program are recruited through clinician referrals and direct applications. 

A number of these research studies involve health condition improvement programs (cognitive training, exercise, art, etc.). Research subjects from both studies are routinely scanned in a 3T MRI scanner and undergo at least a standard battery of neuropsychological (e.g. Cambridge Neuropsychological Test Automated Battery - CANTAB), and electrophysiological  testing (e.g. Mismatch negativity,  Auditory discrimination task, Emotional discrimination task, etc.).  The data obtained from the brain scans and the neuropsychological and electrophysiological tests generates the research projects’ raw data. 

This raw data is enriched by contextual information critical for use and reuse.  Research subjects themselves are contextualised by clinical data of essential value to the researcher.  Although existing tools support characterisation, management and sharing of scans and test results, there remains an important and unmet need for tools enabling the application and management of persistent links relating research data, contextual data and clinical data (de-identified in the case of human subjects).

Integration of these managed data types which would enable new types of statistical analyses (e.g. correlation, regression analysis) to be run across the combined research scans and clinical records (such as the case of comparing a research brain scan and the results of a clinical cognitive test).

Integration would also be of direct value to clinicians caring for patients who are also research subjects.  Research findings would be returned to referring clinicians, providing additional diagnostic support.

2.            People involved in the testing

	Roles to be tested	System	Browser
·         Associate Professor Jim Lagopoulos ·         Dr Daniel Hermens ·         Justin Chang ·         John Twyman ·         Michael Homsey ·         Dr Will Ryder	project-administrator	DaRIS	Google Chrome 22.x,  IE 8.0, Firefox  12.x
·         Associate Professor Jim Lagopoulos ·         Dr Daniel Hermens ·         Justin Chang ·         John Twyman	subject-administrator	DaRIS	Google Chrome 22.x,  IE 8.0, Firefox  12.x
·         Associate Professor Jim Lagopoulos ·         Dr Daniel Hermens ·         Justin Chang ·         John Twyman	member	DaRIS

3                   Test Environment

3.1            People involved in the testing General Approach

The general approach for acceptance testing the ANDS AP24 BMRI Application is as follows:

•          Architecta (vendor) are responsible for programmer unit testing;
•          ICT project team are responsible for DaRIS for configuration testing;
•          BMRI researchers, ICT project team, ICT Capability Solutions team for end user functional testing;
•          Programmer unit testing will be hands-on and automated as per Architecta processes;
•          End user functional testing will be hands-on;
•          Test results will be documented by the respective teams;
•          Test results will be collated by ANDS Ap24 project team;
•          Testing sign-off is a responsibility of the Business Owners, Brain and Mind Research Institute (Michael Milne).

Business representatives who will participate in the UAT process will be required to prepare a set of test scenarios (to assist the business representatives a draft set of test scenarios has been written by the project team) that they will execute for each of the applications that they will test. These could be as simple as screen dumps of individual business processes or individual steps for each process requiring testing. These will be sent to the Test Manager prior to the UAT date for review and compilation.

There will be two test cycles for each project phase. The intention is that during the first cycle, all identified test scenarios will be executed. The second cycle allows for re-test of failed scenarios and some regression testing of the functions the new system changes will have an impact on.

UAT will require the identification and creation of test data. The project team and the business representatives prior to test execution will perform this task jointly.

The project team will provide user education to all participating testers prior to the commencement of the UAT. Such education is not a formal training session, but specifically designed for the execution of the UAT. It covers an overview of the new solution, usage of the new system, test methodology, incident management and technical support for UAT.

3.1.1          User Acceptance Test Environment

UAT will take place onsite at University of Sydney. The UAT Testing will be run on the Universities test bed against a full replica of the production database to ensure real world scenarios, data and compatibility.

3.2        Test Pre-Requisites

3.2.1          Login Accounts

The system administrator will be given full unrestricted access to the system to enable configuration of user roles during testing.

3.2.2          Data

Test data is as follows:

·         Youth Mental Health – DICOM T1 Weighted Structural Images (196 image series)

·         Youth Mental Health – NifTI T1 Weighted Structural *T1_n.nii

·         Youth Mental Health – NifTI T1 Weighted Structural *T1_n_r.nii

·         Youth Mental Health – NifTI T1 Weighted Structural *T1_n_r_brain.nii file

·         Youth Mental Health – DICOM Diffusion Tensor Images (4235 image series)

·         Youth Mental Health – NifTI Diffusion Tensor Images *DTI.nii

·         Youth Mental Health – NifTI Diffusion Tensor Images *DTI.nii_bvals

·         Youth Mental Health – NifTI Diffusion Tensor Images *DTI.nii_bvecs

·         Youth Mental Health – NifTI Diffusion Tensor Images *DTI_nodif.nii

·         Youth Mental Health – NifTI Diffusion Tensor Images *DTI_nodif_brain_mask.nii

·         Youth Mental Health – NifTI Diffusion Tensor Images *DTI_ecc.nii_ecclog

·         Youth Mental Health – NifTI Diffusion Tensor Images *DTI_ecc.nii

·         Youth Mental Health – NifTI Diffusion Tensor Images *DTI_ecc_tens_FA.nii

·         Youth Mental Health – NifTI Diffusion Tensor Images *DTI_ecc_tens_L1.nii

·         Youth Mental Health – NifTI Diffusion Tensor Images *DTI_ecc_tens_L2.nii

·         Youth Mental Health – NifTI Diffusion Tensor Images *DTI_ecc_tens_L3.nii

·         Youth Mental Health – NifTI Diffusion Tensor Images *DTI_ecc_tens_MD.nii

·         Youth Mental Health – NifTI Diffusion Tensor Images *DTI_ecc_tens_MO.nii

·         Youth Mental Health – NifTI Diffusion Tensor Images *DTI_ecc_tens_S0.nii

·         Youth Mental Health – NifTI Diffusion Tensor Images *DTI_ecc_tens_V1.nii

·         Youth Mental Health – NifTI Diffusion Tensor Images *DTI_ecc_tens_V2.nii

·         Youth Mental Health – NifTI Diffusion Tensor Images *DTI_ecc_tens_V3.ni

·         Youth Mental Health – DICOM T2 Weighted Functional MR Images (5460 image series)

·         Youth Mental Health – Folder of files *FMR.ica

3.2.3          Role permissions

project-administrator : user is allowed to administer the specific Project

subject-administrator : (pssd.project.subject.admin.<CID>) : user is allowed to administer Subjects in the specific project

member : user is a member (no admin and cannot see private meta-data on Subjects) of the specific Project

These roles are hierarchical; the project admin role contains the subject admin role contains the member role contains the guest role.

Prior to the execution of test cases, and on completion of development, a demonstration of the new application/system should be arranged. This meeting should be between the Developers, Project Manager, Test Team and User Acceptance Testers.

This education session should allow the testers to understand the application/system they are testing prior to the commencement of the actual Test Phase.

3.3        UAT Entry Criteria

UAT will commence if ALL the following criteria are met:

·          System Testing has been completed and ;

 No high severity or impact faults remain post system testing.

•  Any medium/low severity or impact faults have agreed actions which will be resolved in a manner which will not impact User Acceptance testing.
• Requirements/High Level Design or other relevant documents have been generated.
• Sign-off of this Test Strategy has been completed by Project Team and Business Representatives.
• Test Plan document which will include test cases has been completed, reviewed and signed off by the Project Manage.
• Test environment has been successfully setup.
• Any login accounts, required to complete User Acceptance testing, have been created
• All testing tools and resources have been made available to relevant parties prior to commencement.
• All training required has been provided to the Business Representatives team who will be testing new/modified systems.
• Data, required to complete User Acceptance testing, has been migrated into the Test Environment.
• Change Management methodologies in place and adhered to.
• Tracking method/software in place and working, to monitor fault/issue tracking and resolution.
• Access to development resources and personnel for issue resolution.
• Access to Business Representative when required
• Infrastructure support in place.

3.4        UAT Exit Criteria

• UAT will be signed off if ALL the following criteria are met:
• All UAT test cases are executed
• All incidents identified during execution are logged
• No Critical, High or Medium Severity errors remain open
• Outstanding Low Severity errors scheduled for resolution
• Business has provided a work around, for any outstanding issue(s) and has signed off on the release to UAT.
• Test Completion Report completed and distributed to all relevant team members.

3.5        Sign off Procedures

UAT Sign Off Procedures

Upon completion of the UAT by all participating business units, the business representative from each business unit is responsible for completing and signing (if all test exit criteria are met) the Test Completion Report). This is to signify that the solution has been verified with respect to the business processes of their business unit and the new solution has been accepted.

Upon signing off on the UAT by all business units, all Test Completion Reports will be submitted to the Project Manager and used as a basis for their final endorsement on the overall solution.  Also the tested components will be released to Production environment via the Change Management Process.

Posted by Neal Anderson May 14th, 2014