160 likes | 270 Views
Connectathon Test Development 201. Connectathon Test - Recap. Focus is on exchange of data between partners and the expected outcome (vs. testing against tools in pre-connectathon phase) Three types of connectathon tests: No –Peer test Peer to Peer test Group test.
E N D
Connectathon Test - Recap Focus is on exchange of data between partners and the expected outcome (vs. testing against tools in pre-connectathon phase) Three types of connectathon tests: • No –Peer test • Peer to Peer test • Group test
Connectathon test types - more • No peer test • No test partner needed • One instance of test required • Eg Calibrate a monitor • Eg Submit a sample • Peer-to-peer test • Test between 2 (ideal) or 3 partners • exercise the exchange between them • “Three instance rule” • Group (full workflow) • Full set of actors • Run on Wed pm and Thurs under supervision of monitor • Not applicable to most profiles; no “pass” or “fail”
Typical Actor Diagram …for an “Content-type IHE Profile Content Creator Content Consumer
Pattern for “Content Profile” connectathon tests • A no-peer “Publish” test • The Content Creator uploads a sample of their content into gazelle ‘samples’ page (egEDR_Publish_Referral) • A no-peer “Scrutinize” test • The monitor examines the content (schematron or visual inspection (egEDR_Scrutinize_Referral) • A peer-to-peer “Process” test • The Content Consumer grabs sample from gazelle and ‘processes’ into its system; monitor examines result at the Consumer (egEDR_Process_Referral) • both Creator & Consumer get credit
Typical Actor/Transaction Diagram …for an “Integration-type IHE Profile
“Integration Profile” connectathon tests • Each test is a subset of the interactions in the entire profile • Exercise transactions between two or three actors • May need a tool (eg to create a patient) or a pre-requisite test (eg store the image to archive so it can be query/retrieved)
Link between Connectathon Registration and test design • Tests are assigned to a vendor’s test system based on Profile / Actor / Options selected during registration
Considerations in test design At the profile level: • Actor/Transaction Coverage • Are all transactions between actors exercised? (R/O) • You will make each test either Required or Optional based on Profile/Actor/Option combo (aka Role) • Options Coverage • Less important: we do not report results at the option level
More considerations in test design At the test level - granularity: • # of participants in test • # of steps / complexity of interaction • Evaluation criteria • Which actor can show evidence of ‘success’ • What monitor should look for (captued logs, GUI results, ‘see it live’…) • Not too much field-by-field examination • Enough to show “interoperability”
Gazelle-specific test design considerations • Remember this? Tests are assigned to a vendor’s test system based on Profile / Actor / Options selected during registration • …and whether a given test has been identified as “Required” for that profile/actor/option (aka Role) Also – gazelle’s “test engine” affects how test steps are specified.
Structure of a Connectathon Test • Overview containing 3 sections • Special Instructions • Description • Evaluation • Actors involved in the test (aka Roles) • Test Steps