Showing posts with label andsValue. Show all posts
Showing posts with label andsValue. Show all posts

Tuesday, 13 May 2014

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

Monday, 11 February 2013


Key success factors

 

One of the main problems in Brain and Mind Research Institute is that there is no such a tool the can efficiently and effectively collaborate the data captured from multiple test.  The researchers need to put the data and the images together manually in order to perform analysis.  Another is the pre – processing of the MRI images. In order to read the image, research needs to pre – process the raw image from the scanner. Professor Jim Lagopoulos spends hours and hours a week just on helping the pre- processing because he is the only person who has the expertise to do it quickly.

These manual processes consume significant time and effort, replacing these by an automated process will be a huge success in the research area.

The system will improve the process efficiency by replacing the manual pre – processing to an automated pre- processing based on the researcher’s requirement.  Moreover, system integrates multiple sources of records and presents the summery of linked records according to user’s query, giving the user an overall view of related records. This automated functionality is previously not existed in this research filed of BMRI the University of Sydney.

The new process and functionality that will be brought by the application is highly welcomed by the researchers in BMRI, users keen to have an application that

-          Can integrate, manage and store a diverse range of clinical research data.

-          Can run MRI Scan pre-process through the process

-          Can ingest existing research data

-          Can enable users to manage access to research data.

-          Can allow user to define and queries on research data.

-          Can provide RIF-CS 1.3, Service, Party, Input Collection and Output Collection records to Research Data Australia.


In the mean while the system shall also:

-          Meets ICT’s security standards.

-          Meets minimum accessibility requirements.

The users will perform and approve completion of the User Acceptance Testing (UAT) that will prior to the application moving into a production environment. The users will be sourced from both project team members and where possible users that are not part of the team except for UAT purposes.

Key Technologies & Key Features


 
 
The Univerisity of Sydney has chosen Daris as the solution software. The sofware sits on MediaFlux's server and provides functions required by University of Sydney researchers.
 
The key functions required that Daris will be able to produces are:
 
  • Storage of MRI data
  • Storage of Neuropsychological data
  • Enable uses to manage access to specific data sets
  • Enable users to describe research data collections
  • Enable users to query the systems research data collection
  • Enable users to download research data
  • Enable the visualisation of research data
  • Make available RIF-CS 1.4 metadata available for harvesting via OAI-PMH.
  • Enable the creation of output collections
 
The solution components are broken down into the following:
  • Access control for authentication and authorization purposes.
  •  
  • Admin functionality is controlled by roles based permissions. Functional permissions management is a permissions controlled function that allows users to grant and revoke data access and to manage user roles.
  • Other function is to implement business functions. For example building form that allows users to add and update Nuerophsycohological data.
  •  
  • Reporting is a permissions controlled function that packages, compresses and makes datasets available for download by authenticated users.
  •  
  • File system storage  will store the pre-processed data and its extended information like index.
  • Relational database will be use for system management configuration or user management information only.
  • Email Connector is the components that send appropriate emails to application users.
  •  
  • The OAI harvester makes RIF-CS 1.4 compliant metadata records .xml files public available for harvest Research Data Australia is a RIF-CS 1.4 .xml harvester.
  •  
  • WASM connector is to integrate with the University of Sydney authentication system
 
 
The BMRI solution consists of the components listed below and its integration purpose:
  • WASM provides authentication of users and provides basic user information for tracking relations between parties (users) and collections (datasets). Actual relation ship types are tracked through the BMRI Application.
  • Research Data Australia connects to the BMRI JOAI harvester via OAI-PMH protocol to ingest updated information from the BMRI harvest point.