HI580 Unit 7 Test Plan Example

Deliver Twins, Register Both, Check the Mothers: A Unit 7 Test Plan With Three Levels and a Pass Condition for Every Script

[Student Name]

Purdue University Global

HI580: Information Systems Design and Implementation

Unit 7 Test Plan

[Instructor Name]

[Date]

Brackenridge Medical Center, its staff, scripts and every count are composite; the sources cited are real.

Strategy

Three levels of testing, each with an owner and a purpose:

1. Unit testing: individual build items, such as a flowsheet row, a category list or a board column. Owned by the build analysts. Finds a mislabeled field or a wrong default.

2. Integration testing: the three exchanges and the shared clock defined in the interface specification. Owned jointly by the interface analyst and the vendor. Finds a lost, duplicated or mismatched message.

3. User acceptance testing: complete clinical scenarios run by the unit's nurses, midwives and obstetricians on a test environment. Owned by the unit's clinical lead. Finds a workflow that is technically correct and clinically wrong.

The levels are kept separate because they catch different faults, and a defect found at acceptance that should have been caught in unit testing costs far more to fix.

Entry and Exit Criteria

Unit testing begins when the build is complete for a module and ends when every build item has passed or has a logged defect. Integration testing begins when unit testing has no open severity 1 or 2 defects and both vendors confirm their test interfaces are live; it ends when all exchange scripts pass, including failure scripts, and the clock check has run cleanly for five consecutive days. Acceptance testing begins only when integration testing has exited; it ends when all acceptance scripts pass or have defects accepted in writing by the clinical lead and the project sponsor, with no open severity 1 defects.

Traceability

Every script is mapped to the requirement numbers it tests. The traceability matrix lists all forty-one requirements down the side and scripts across the top. A requirement with no script appears as a blank row, and no requirement with a fit criterion may go untested. At the first review, two requirements were blank: REQ-30, unalterable archive, and REQ-38, downtime entry with original times. Scripts were written for both before testing began. Requirements guidance treats this kind of matrix as the main defense against requirements that are agreed in writing and then never verified (Wiegers & Beatty, 2013).

Two of forty-one requirements had no test at first review, and both were the kind that only matter on the worst day the unit will have.

Sample Scripts

UAT-14, twins. Steps: admit a mother with twins; monitor both fetal heart rates; deliver twin A, register; deliver twin B two minutes later, register. Pass condition: each newborn record shows the correct mother, the correct birth time to the second from the shared clock, and the correct birth order. Traces to REQ-19 and REQ-41.

INT-07, interpretation failure. Steps: disconnect the record interface; enter three interpretations at the bedside; reconnect after twenty minutes. Pass condition: the nurse's screen shows "not yet in record" during the outage; all three entries post in order with original times; none duplicated. Traces to REQ-11 and the interface specification's failure rules.

UAT-22, handoff segment. Steps: day nurse marks a tracing segment of concern; night nurse opens it at handoff. Pass condition: the night nurse reaches the segment in two clicks from the patient's chart. Traces to REQ-12.

UAT-31, downtime. Steps: simulate a network outage for one hour during active labor; nurse charts on downtime forms; enter after recovery. Pass condition: every entry carries its original time and the record shows the downtime period. Traces to REQ-38.

Defect Severity

Severity 1: patient safety or legal record integrity affected, for example a newborn linked to the wrong mother. Severity 2: a workflow cannot be completed without a workaround. Severity 3: a cosmetic or minor issue with an easy workaround. Severity 1 defects block go-live without exception.

Regression Testing

Any defect fix after integration testing triggers a rerun of the scripts traced to the same requirements, plus the four identity scripts, before the fix is accepted. This prevents a correction to one screen from quietly breaking newborn linking or the interpretation exchange, which share code paths in the surveillance system's build. Regression runs are logged in the same matrix as first runs.

Test Data

All testing uses synthetic patients created in the test environment. No real patient records are copied into testing, both to protect privacy and because real records rarely contain the edge cases, such as twins and mid-labor transfers, that the scripts must exercise.

Who Writes Acceptance Scripts

Acceptance scripts are drafted by labor nurses and midwives with an analyst, because they know which scenarios break things. Patient safety work on electronic records stresses testing realistic clinical scenarios before go-live, especially for identification and results (Sittig & Singh, 2012), and implementation reviews find that clinician involvement in testing improves both quality and acceptance (Kaplan & Harris-Salamone, 2009).

Appendix

The appendix holds forty-eight acceptance scripts, twenty-two integration scripts and the full traceability matrix.

References

Kaplan, B., & Harris-Salamone, K. D. (2009). Health IT success and failure: Recommendations from literature and an AMIA workshop. Journal of the American Medical Informatics Association, 16(3), 291-299. https://doi.org/10.1197/jamia.M2997

Sittig, D. F., & Singh, H. (2012). Electronic health records and national patient-safety goals. New England Journal of Medicine, 367(19), 1854-1860. https://doi.org/10.1056/NEJMsb1205420

Wiegers, K., & Beatty, J. (2013). Software requirements (3rd ed.). Microsoft Press.