Skip to content

User Acceptance Tests (UAT)

Jump to bottom
Kutila G edited this page Sep 23, 2013 · 21 revisions

These test cases cover the basic usage scenarios of the PODD HTML interface.

  1. Create a new Project

    • Pre-Conditions: A User with "Project Creator" Role is logged in
    • Steps:
      • From the "Project Listing" page, click on the "Create Project" button. "Add new Project" page is displayed.
      • In "Add new Project" page, fill in mandatory fields (using test data) and click the "Submit" button
      • The "View Project" page for the newly created Project is displayed. It contains the data filled in for the Project.
    • Post-Conditions: A new Project is created. The User who performed the creation is given "Principal Investigator" and "Project Administrator" roles.

  2. Create a new Project: Variations

    • User does not have "Project Creator" Role. "Create Project" button is not visible.
    • When one or more mandatory fields are left blank, "Submit" results in a list of error messages (in red text) being displayed on the top of the project.
    • Add multiple values for the "Notes" and "ANZSRC FOR Code" fields using the (+) button shown above them. These are displayed in the "View Project" page.

  3. Upload a new Project

    • Pre-Conditions: A User with "Project Creator" Role is logged in
    • Steps:
      • From the "Project Listing" page, click on the "Upload Project as RDF" button. "Upload new Project" page is displayed.
      • In "Upload new Project" page, using the File Chooser, select a valid RDF file containing a Project structure.
      • Click the "Upload" button.
      • Page is refreshed to show: "Project successfully uploaded" message, IRIs of the newly created project, and the buttons "View Project" and "Edit Participants".
    • Post-Conditions: A new Project is available and can be viewed/updated. The User who performed the upload is given "Principal Investigator" and "Project Administrator" roles.

  4. Upload a new Project: Variations

    • Upload a non-RDF file. Upload fails and an error message is displayed on the page.
    • Upload an RDF file containing invalid PODD project. Upload fails and an error message is displayed on the page.

  5. Edit a Project:

    • Pre-Conditions: A valid project exists and a user with "Project Member", "Project Admin" or "Admin" Role is logged in.
    • Steps:
      • From the "View Project" page, click "Edit Object" button. "Edit Project Object" page is displayed.
      • Modify some of the fields displayed.
      • Click "Submit" button. "View Project" page is displayed with modified details.
    • Post-Conditions: Project details are modified.

  6. Edit a Project: Variations

    • Click "Edit Object" from a child object view page (e.g. "View Analysis"). Changes are made to this child object.
    • During modification, remove a mandatory field. Clicking "Submit" will fail with an error message displayed on the page.

  7. Create a refersTo link from a Project object to a pre-defined Platform

    • Pre-Conditions: A valid Project with an Analysis object exists and a user with "Project Member", "Project Admin" or "Admin" Role is logged in.
    • Steps:
      • Navigate to view an "Analysis" object of the Project.
      • Click "Edit Object" page. "Edit Analysis Object" page is displayed.
      • In the "Refers To Platform" text field, type "Ca". After a second or two, a list of system pre-configured Platforms matching the term appears.
      • From the list, select "CabScan" and press "Submit". "View Analysis" page is displayed.
      • The page now contains a "Refers To Platform: CabScan" attribute.
    • Post-Conditions: A refersTo link has been created from the test Project's Analysis object to the "CabScan" platform.

  8. Create a refersTo link from a Project object to a pre-defined Platform: Variations

    • In the "Refers To Platform" field, type "xy". No matches will appear for this.

  9. Add a Child Object to a Project

    • Pre-Conditions: A valid Project exists and a user with "Project Member", "Project Admin" or "Admin" Role is logged in.
    • Steps:
      • From the "View Project" page, click "Add Child Object" button. The "Add Child" Dialog is displayed.
      • From the drop down list on the "Add Child" Dialog, select a child object type, relationship combination.
      • Press "Continue" button. Add new [object type] page is displayed with empty text fields for attributes of the selected object type.
      • Fill mandatory fields and press "Submit". View page for the object type is displayed containing the filled in attributes. "Parent Details" section identifies the Project as being the parent and the relationship.
    • Post-Conditions: A new child object is added to the Project.

  10. Add a Child Object to a Project: Variations

    • Create a "Publication" object and try to add a child object to it. There should be no "Add Child Object" button.

  11. Add a new: Genotype

    • Pre-Conditions: A valid Project exists and a user with "Project Member", "Project Admin" or "Admin" Role is logged in.
    • Steps:
      • From the "View Project" page, click "Add Child Object" button. The "Add Child" Dialog is displayed.
      • From the drop down list on the "Add Child" Dialog, select Genotype (hasGenotype).
      • Press "Continue" button. "Add new Genotype" page is displayed with empty text fields for attributes.
      • Fill in values including the mandatory fields of Title, Wild Type and Genus & Species, and press "Submit". "View Genotype" page is displayed containing the filled in attributes. "Parent Details" section identifies the Project as being the parent and the relationship.
    • Post-Conditions: A new Genotype is added to the Project.

  12. Add a new: Data

    • Pre-Conditions: A valid Project with an Investigation object exists and a user with "Project Member", "Project Admin" or "Admin" Role is logged in.
    • Steps:
      • From the "View Investigation" page, click "Add Child Object" button. The "Add Child" Dialog is displayed.
      • From the drop down list on the "Add Child" Dialog, select Data (has Data).
      • Press "Continue" button. "Add new Data" page is displayed with empty text fields for attributes.
      • Fill in values including the mandatory title, and press "Submit". "View Data" page is displayed containing the filled in attributes. "Parent Details" section identifies the Project as being the parent and the relationship.
    • Post-Conditions: A new Data element is added to the Project.

  13. Add a new: Data Reference

    • Pre-Conditions: A valid Project exists and a user with "Project Member", "Project Admin" or "Admin" Role is logged in.
    • Steps:
      • From the "View Project" page, expand the "Attach Files" section.
      • TODO
    • Post-Conditions: A data reference is now connected to the project.

  14. List Projects: Public User

    • Pre-Conditions: The system has several Projects with at least one published Project.
    • Steps:
      • A public user (i.e. not logged in) views the "List Projects" page. Only Public access (i.e. Published) projects are displayed.

  15. List Projects: Project User

    • Pre-Conditions: The system has several Projects with at least one published Project.
    • Steps:
      • User views the "List Projects" page. Only Public access (i.e. Published) projects and projects in which the user has a Project Admin, Project Member or Project Observer role is displayed.

  16. List Projects: Repository Admin User

    • Pre-Conditions: The system has several Projects with at least one published Project.
    • Steps:
      • User views the "List Projects" page. All Projects are displayed.

  17. Delete a Project

    • Pre-Conditions: A valid Project exists and a user with "Project Admin" Role is logged in.
    • Steps:
      • From the "View Project" page, click the "Delete Project" button.
      • "Delete Object" Dialog appears requesting confirmation. Click "Confirm".
      • "List Projects" page is displayed. The deleted project is not in the list.
    • Post-Conditions: The project is deleted from the system.

  18. Delete a Project: Variations

    • A "Repository Admin" user is logged in. As above.
    • A "Project Member", "Project Observer" is logged in. The "Delete Project" button is not present.
    • A user is not logged in. Only public access projects are viewable and no modification buttons are present.

  19. Delete a Child Object

    • Pre-Conditions: A valid Project with at least one Child Object exists and a user with "Project Admin" Role is logged in.
    • Steps:
      • From the "View [Object]" page, click the "Delete" button.
      • "Delete Object" Dialog appears requesting confirmation. Click "Confirm".
      • The deleted object's parent "View" page is displayed. The deleted object is no longer available as a child object.
    • Post-Conditions: The child object is deleted from the project.

  20. Delete a Child Object: Variations

    • A "Repository Admin" user is logged in. As above.
    • A "Project Member" user is logged in. As above.
    • A "Project Observer" is logged in. The "Delete" button is not present.
    • A user is not logged in. Only public access projects are viewable and no modification buttons are present.

  21. Add a new User

    • Pre-Conditions: A user with "Repository Admin" Role is logged in.
    • Steps:
      • Select the "Administrator" Menu item to display the User Listing page.
      • Select the "Create User" link from the Administration Menu. "Create User" page is displayed.
      • Fill in the user details including mandatory fields and click "Create New User" button.
      • "User Details" page is shown with the newly added user's information.
    • Post-Conditions: A new User is added to the system. The user is given "Project Creator" Role by default.

  22. Add a new User: Variations

    • A Project User (i.e. Project Admin, Project Member, Project Observer) is logged in. The "Administrator" Menu item and "Administration Menu" are not visible.

  23. Set a User status to inactive

    • Pre-Conditions: A user with "Repository Admin" Role is logged in. Another non-admin User exists in the system with at least one Project Role.
    • Steps:
      • View "List Users" page.
      • Click the appropriate non-admin user to display the "User Details" page.
      • Click "Edit User" button to display the "Edit User Details" page.
      • Select the "Inactive" radio button under "Status" and click "Update Details".
      • "User Details" are displayed with the status set to "Inactive".
      • Logout from Admin account and login as the above inactivated user.
      • "List Projects" page is displayed, showing only public access projects.
      • Click "Settings" menu item. An error page is displayed.
    • Post-Conditions: Inactive user can login but has no privileges and behaves as a public access user.

  24. Set User Roles

    • Pre-Conditions: A user with "Repository Admin" Role is logged in. Another non-admin User exists in the system.
    • Steps:
      • View "List Users" page.
      • Click the appropriate non-admin user to display the "User Details" page.
      • Click "Manage Roles" button to display "Change User Roles" page.
      • Click "Add new Role". "Add Role" Dialog is displayed.
      • Select Administrator from the drop-down list on the Dialog and click "Continue" button.
      • The Dialog closes and the Roles Table is updated to include Administrator role with the description "Repository Wide Role".
      • Logout from Admin account and login as the modified user. The user should now have Repository Admin privileges.
      • Logout and again login as the original Admin User. Navigate to the "Manage Roles" page for the modified user.
      • From the Roles Table, click the "Delete" link in front of the "Administrator" Role. A confirmation Dialog is displayed.
      • Click "Confirm". The Dialog closes and the "Administrator" row disappears.
      • Login as the modified user again. The user should no longer have Repository Admin privileges.

  25. User change own password

    • Pre-Conditions: A user with "Repository Admin" Role is logged in. Another non-admin User exists in the system with at least one Project Role.
    • Steps:
      • Step 1
      • Step 2
    • Post-Conditions:

  26. User change other's password

    • Pre-Conditions: A user with "Repository Admin" Role is logged in. Another non-admin User exists in the system with at least one Project Role.
    • Steps:
      • Step 1
      • Step 2
    • Post-Conditions:

Clone this wiki locally