Difference between revisions of "Manual Tests"

From OpenEMR Project Wiki
Line 23: Line 23:
== Philosophy & Approach ==
== Philosophy & Approach ==


- Keep tests elegant and within appropriate boundaries.
* Keep tests elegant and within appropriate boundaries.
- Test cases should cover realistic happy paths and negative paths.
* Test cases should cover realistic happy paths and negative paths.
- It is acceptable to have the tester query the database when the UI can't satisfy an assertion.
* It is acceptable to have the tester query the database when the UI can't satisfy an assertion.
- Each test case is simply a markdown table with columns "Step Number", "Description", and "Expectation".
* Each test case is simply a markdown table with columns "Step Number", "Description", and "Expectation".
- Assume that the tester that runs the test is familiar with the system and terms.
* Assume that the tester that runs the test is familiar with the system and terms.

Revision as of 02:09, 30 June 2016

Objective

High-quality manual test cases need to be built up and maintained moving forward. A group of testers can run through them before releases are shipped and developers can also use them as a point of reference/sanity check when doing the big codebase refactor project.

Test Suites

  • Facility Registration
  • Patient Demographics
  • Patient Scheduling
  • Electronic Medical Records
  • Prescriptions
  • Medical Billing
  • Clinical Decision Rules
  • Patient Portal
  • Reports
  • Multilanguage Support
  • Security

Test Development

The tests will be built up in the following fork (for now): https://github.com/MatthewVita/openemr. There is a top-level "Manual_Tests" folder that contains folders for each test suite. Individual test cases are to be placed in these folders (e.x.: /openemr/Manual_Tests/Electronic_Medical_Records/Medications_Test_Case.md).

Philosophy & Approach

  • Keep tests elegant and within appropriate boundaries.
  • Test cases should cover realistic happy paths and negative paths.
  • It is acceptable to have the tester query the database when the UI can't satisfy an assertion.
  • Each test case is simply a markdown table with columns "Step Number", "Description", and "Expectation".
  • Assume that the tester that runs the test is familiar with the system and terms.