-
Notifications
You must be signed in to change notification settings - Fork 5
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
- 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.
- 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
- 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
Test Suit Setup & Configuration
Tests / Scenarios
- Spine Integration and Cross Organisation Tests
- Access Record Consumer Tests
- Access Record Consumer Tests 0.5.3
- Access Record Consumer Tests 0.7.2
- Access Record Consumer Tests 0.7.3
- Foundations Consumer Tests
- Appointments Consumer Tests
- Appointments Consumer Tests 1.2.7 Emergency Changes Only
- Appointments Consumer Tests
- Structured Record Consumer Tests
- Structured Record Consumer Tests 1.2.4
- Structured Record Consumer Tests 1.2.5
- Structured Record Consumer Tests 1.2.6
- Structured Record Consumer Tests 1.3.0
- Send Document Tests 1.3.0
- Access Record HTML view Manual Testing
- Appointments API (including Foundation) - Manual Testing
- HTML Provider Content
- FHIR GP Connect Profiles
- FHIR Base
- SSP
- JWT
- HTTP
- Security
- test
Test Data Pack
- Test Data Approach
- Base Test Data Set
- Simple Patient Records
- Rich Test Data Set
- ITK Test Harness Triggers
New Consumer SCAL Tests/Scenarios