Skip to content

Access Record HTML view Manual Testing

Michael Measures edited this page May 26, 2017 · 1 revision

The following areas need testing manually as they are not covered by the automated test suite

HTML Format and Content

  • date order in html tables, the date order should be decending
  • date format should be dd-mmm-yyyy (12-Oct-2015)
  • Date range - If a date range is supplied the response should include the relavant data for that date range. Dates should be inclusive so some edge cases should be tested which should include use of the different possible date formates (yyyy, yyyy-mm, yyyy-mm-dd, yyyy-mm-ddThh:mm:ss).
  • Unusual section mapping - if a provider system has a section different to the GP Connect sections, such as Hospital medications in emis, we need to check that these are correctly included in the HTML.
  • Additional Warnings, any additional warning information such as that for sensitive data should be included in the HTML.
  • Section not supported - If a suppliers system does not support a GP Connect section then the default HTML banner should be included in the response HTML in place of the table element, for example emis does not support administration items.
  • General html format, for example are banners inside a table where they should not be. Are the headers and banners in the correct format as per the spec. For example if there is no patient data for the section the no data banner should appear instead of the table and not in the table.

FHIR resource testing

  • Value set mapping, value set case sensitivity - need to test all possible options in the providers system.
  • Genders (Patients, Contacts, Practitioner)
  • Marital Status (Patients, Contacts, Practitioner)
  • Relationship (Contacts)
  • If provider has additional information such as practitioner, organization, device, location associated with section then this must be reflected in response, but as optional it can not be tested with automation.
  • Check that FHIR resource contains all available information from the provider system, for example patient contains telephone, address, gender, links to practitioners or organizations

Other aspects to test

  • Patient in transit, how is it handled.
  • Patients flag as sensitive should not return any information within the HTML or Patient Fhir Resource which may allow for identification of contact information or address.
  • Audit of request and response, payload, requests url and all headers including additional headers
Clone this wiki locally