Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Current »

Primary mentor

Unlicensed user

Backup mentor

TBD

Assigned to

TBD

Abstract

Currently, prerelease testing for OpenMRS is conducted by requesting users to install a beta version of the application and test it by using it how they would normally use OpenMRS. We would like to make testing a clearer and easier process, which will hopefully encourage more people to conduct testing and make OpenMRS better. We propose an add-on module for OpenMRS that will guide users through different test scripts and collect data about the results.

Project Champion / Domain Expert

  • Michael Downey

Objectives

  1. Specify a machine-readable format for tests that can be retrieved by the module from the Internet. This test script should include things like:
    1. Name and unique ID of the test
    2. The version or version of OpenMRS for which the test applies.
    3. High-level summary of the test's goal from the perspective of the user. (What is the user trying to accomplish?)
    4. Multiple sub-tasks to accomplish the goal. Each task should specify what the module is recording for that task (e.g., time to complete the task, number of clicks, etc.).
    5. A start date, after which the user may interact and "take" the test.
    6. An expiration date, after which the test results are no longer desired.
  2. The module should present only active tests, and provide the user a choice of which test to take.
  3. The user should be explained the goals of the test, and be informed what kind of data will be collected. At any point, they should have the opportunity to withdraw from the test, at which time any stored results will be deleted.
  4. Once the test is complete, the module should provide a summary of data that has been collected and will be sent back to OpenMRS. Personal information about patients in the system, or anything that could be used to identify them, should never be collected.
  5. Users should be able to optionally provide contact information in case developers have questions about the test results before sending them.
  6. A secure backend system to receive the test results will exist on an OpenMRS project server. This system should also display de-identified aggregate statistics about all results recorded for each test. Those reports should be available to anyone.
  • What might be tested?
    • System performance when doing certain queries and tasks.
    • Usability of certain core aspects and usage patterns of OpenMRS.
    • Things we haven't yet thought about. (In other words, we should be able to develop new tests in the future using this system.)

Extra Credit

  1. The system administrator should be able to specify whether data is sent automatically & directly to OpenMRS, or will be collected locally. (The administrator could then choose to manually send the data in bulk.)
  2. Allow users to download raw test data (anonymized without personal information of who submitted test results) for each test.
  3. Implement a simple administration tool for the "backend" web interface that can authenticate against OpenMRS ID's of people running the tests.

Resources

Related OpenMRS Tickets:

Tools that may be similar:

  • No labels