Iteration 10 Test Specification

This wiki page covers the outline of how the system and components for SCOOP Iteration 10 will be tested.

Introduction

See the SCOOP Overview for an introduction to the project. Further matierial can be found on the project website.

Specifically this iteration is focused on enhancing an EMR (OSCAR) to better support interaction with an EMR adapter.

Goals and Objectives

Overall project goals are outlined clearly on the project website.

Objectives for this iteration are detailed in the Iteration 10 Requirements.

Statement of Scope

The scope of Iteration 10 is to implement the queries defined in IT6, as well as test the deployment plan created in IT7 for live production.

Test Plan

Testing is outlined in accordance with the requirements. Testing is oriented by two different kinds of analysis:

• Validation - "Are we building the right system? Validation is concerned with checking that the system will meet the customer’s actual needs."
• Verification - "Are we building the system right? Verification is concerned with whether the system is well-engineered, error-free, and so on. Verification will help to determine whether the software is of high quality, but it will not ensure that the system is useful."

See this article for more explanation.

Software to be Tested

• OSCAR EMR
• hQuery Gateway
• hQuery Composer

Testing Strategy

Verification

• Oscar F1

  1. Automated Acceptance Test Framework (Selenium). Need to populate a test database - then export the e2e record for a specifed patient. The presence of an e2e file in a known location indicated the functional requirement is met. File should be removed at the end of the test. Test database should be purged at the end of the test.

• Oscar F2

  1. Automated Acceptance Test Framework (Selenium). Need to populate a test database - then export the e2e record for all patients. The presence of the correct number of e2e files in a known location indicates the functional requirement is met. Files should be removed at the end of the test. Test database should be purged at the end of the test.

• Oscar F3

  1. Automated Acceptance Test Framework (Selenium). Need to populate a test database - then export the e2e record through the scheduler. The presence of the correct number of updated e2e files in a known location indicates the functional requirement is met. Files should be removed at the end of the test. Test database should be purged at the end of the test.

• Oscar NF1

  1. Automated Unit Testing Framework (JUnit) / Automated Mocking Framework (Mockito)
     • Ensure xml schema validation via boolean assertion
     • Ensure schematron validation via boolean assertion
  2. Manual Test Scenarios
     • Ensure more complex conformance conditions

• Oscar NF2

  • If NF1 is verified, meaning that E2E is fully-supported, then NF2 must be true as well. Meaning the document contains the minimum data in order to be considered xml valid.

• Oscar NF3

  1. Automated Unit Testing Framework (JUnit) / Automated Mocking Framework (Mockito). This is more of a constraint on Oscar F2(export all patients). Can use the unit testing framework to time the export - the have a boolean assertion to ensure it is less than the time limit.
     • Dependency on having sufficient number of test patients.

• Oscar NF4

  1. Manual Test Scenario.

• Oscar NF5

  1. Manual Test Scenario. Could implement a template for the OntarioMD data portability spec - then compare the output from this feature to the output from the existing feature in Oscar.

• hQuery NF1

  1. Automated Unit Testing Framework (Minitest)
     • Ensure all unit tests pass
  2. Manual Test Scenarios
     • Manually load in an E2E document and verify that it works

• hQuery NF2

  • Automated Unit Testing Framework (Minitest) * Ensure all unit tests pass on Ruby 1.9.3 platform

Validation

This is somewhat subjective. High-level ideas for validation could include user acceptance testing with scenarios created for this purpose.

For non-functional requirements, perhaps validation could be performed via code walk-throughs.

• Oscar F1

  1. Manual Test Scenario.

• Oscar F2

  1. Manual Test Scenario.

• Oscar F3

  1. Manual Test Scenario.

• Oscar NF1

  1. Manual Test Scenario. Select the E2E template when exporting patients.

• Oscar NF2

  1. Manual Test Scenario. Select all relevant sections in the form.

• Oscar NF3

  1. Manual Test Scenario.

• Oscar NF4

  1. Manual Test Scenario.

• Oscar NF5

  1. Manual Test Scenario.

• hQuery NF1

  1. Manual Test Scenario. Issue a rest call containing an E2E document to gateway.

• hQuery NF2

  1. Manual Test Scenario. Run unit tests while on Ruby 1.9.3.

Test Procedure

• Given an OSCAR EMR with the test data and patients loaded, the user will manually export individual patient summary documents for all patients as a batch.
• Scheduler testing will be done by initializing the scheduled job and allowing the process to export individual patient summary documents for recently updated patients as a batch.
• Using the Map and Reduce functions specified on Iteration 10 Architecture, issue and execute the query on both hQuery endpoints.
• Given a known input with the test patient data, the test passes if and only if the query results match what was expected.
• Any unit tests available should be run and none of them should fail.