Difference between revisions of "Manual Tests"

From OpenEMR Project Wiki
Line 4: Line 4:


Note that unit tests are being introduced in the code base to cover the more fine-grained functionality.
Note that unit tests are being introduced in the code base to cover the more fine-grained functionality.
== Test Development ==
The tests will be built up in the following fork (for now): https://github.com/MatthewVita/openemr. There is a top-level "/Tests/Manual_Tests" folder that contains folders for each test suite. Individual test cases are to be placed in these folders (or sub-folders, when needed). For example:
* /Tests/Manual_Tests/Electronic_Medical_Records/Medications/1_Add_Medications_Test_Case.md
* /Tests/Manual_Tests/Electronic_Medical_Records/Medications/2_Edit_Medications_Test_Case.md
* /Tests/Manual_Tests/Electronic_Medical_Records/Medications/3_Remove_Medications_Test_Case.md
* /Tests/Manual_Tests/Electronic_Medical_Records/Medications/4_Prescribe_Medications_Test_Case.md
The tests are written in markdown format. It turns out that bulleted lists in markdown tables are not supported (http://stackoverflow.com/questions/19950648/how-to-write-lists-inside-a-markdown-table), so plain old HTML tables are leveraged instead (markdown can handle basic HTML).
Use the following WYSIWYG HTML editor (http://bestonlinehtmleditor.com/) and Markdown check (https://stackedit.io/editor) tools like so: https://raw.githubusercontent.com/openemr/openemr/tree/master/Test/Manual_Tests/test-writing-tools.gif


== Philosophy & Approach ==
== Philosophy & Approach ==

Revision as of 02:30, 1 August 2016

Objective

In order to verify that code changes pass certification tests, contributors must execute the relevant test cases via the test mapping document. This document is currently being built up (http://open-emr.org/wiki/index.php/Manual_Tests) and will live in openemr/Tests/certification_tests.md.

Note that unit tests are being introduced in the code base to cover the more fine-grained functionality.

Philosophy & Approach

  • Keep tests elegant and within appropriate boundaries.
  • Test cases should cover realistic happy paths and negative paths.
  • Tests cases are to be ran serially inside of a suite (open for feedback).
  • 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.

Test Execution

Let's keep this _dead simple_. When the manual tests are ran before each release, the following table (which is mocked up for now) will represent testers, assigned test suites, and execution status. If a suite has a FAILED status, tester is responsible for submitting a bug and keeping an eye out for a fix so the suite can be re-ran.

Tester Suite Status
John Doe Facility Registration IN PROGRESS
Sue Bob Patient Demographics PASSED
Sue Bob Patient Scheduling FAILED
and... so... on...

Links/Resources