Iteration 3 Test Specification

This wiki page covers the outline of how the system and components for SCOOP Iteration 3 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 3 Requirements.

Statement of Scope

The scope of iteration 3 is to add support in OSCAR for exporting template-based documents. This feature will be the target of testing activities outlined in this document.

Major Constraints

• Testing can only be performed in a non-production environment

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

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 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.

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
• Oscar F2
• Oscar NF1
• Oscar NF2
• Oscar NF3
• Oscar NF4
• Oscar NF5

Test Procedure