Using Selenium and Cucumber to test a healthcare information system
summary
Migrates from vendor tools to Selenium 2 and Cucumber to get true cross‑browser support (Firefox, IE, Safari, Chrome, iPad), aims to spin up a new environment in 10 minutes, removes hard‑coded data by using random‑data builders that pick matching patients/users from the DB, and keeps Selenium calls confined to page‑object + control‑object layers. Built a cucumber→conceptual→implementation stack, plus plans for a behavior manager and random test runner; code runs across the app but few feature scenarios exist yet, and blockers include SQL character encoding and a VPN port conflict with WebDriver.
AI-written summary · about
chapters (14)
- 0:00Intro
- 1:41Goals of Current Automation Effort Run on all our supported platforms & browsers Rapid deployment in new environment Keep up with developers Avold vendor & script lock-in Maintain test clarity
- 4:30Rapid deployment Minimize locations of change from version to version No hard-coded data in scripts Robust locators
- 5:26Keep up with developers Plan test scenarios as part of feature planning Minimize change locations Business-focused tests & code Use Cucumber so that more people can create tests
- 7:24Avoid Vendor lock-in Open source testing tools Encapsulate tool interface to facilitate swapping in other tools as needed
- 12:02Maintain clarity Cucumber tests defined in plain text Tests specify only relevant details Test specifies verifications that are relevant to the point of the test Future potential tie-in to test case manager
- 17:51Example Cucumber test Feature: Allergy Notification In order to avoid causing an allergic reaction in a patient while providing treatment As a patient care provider I want to be notified of a patient's allergic status
- 18:48Conceptual Layer Provides methods that correspond to actual user tasks and goals Ignores actual implementation Gets additional required data not provided by test case
- 19:33Implementation-Focused Layer Contains all interactions with actual web pages Contains all calls to tool interface Uses Page Objects and Control Objects Uses ruby modules to handle repeated components bigger than a control
- 20:19Page Objects Each page of the application is encapsulated by a single class The class provides public methods that correspond to the things a user can do on that page No details of page implementation available outside of class
- 24:30Control Objects Each control type is wrapped in its own class Allows for verification at control level Removes need to remember how to interact with controls
- 25:15Support Layer Contains code that is not specific to any user action Data classes (Patient, Allergy) Builders (create new patients, get existing patients)
- 25:47Challenges so far Ramp up of staff unfamiliar with tools Cross-platform database access Using non-ASCII characters in test data Firefox/Selenium/FortiClient interaction
- 27:08Future Directions Behavior manager Adding basic performance tests Basic fuzz testing Automated usability testing
related talks
32mAll about web application testing
29mState of Web Integration Testing
37mSelenium In the Enterprise: What went right, what went wrong (so far)
34mUsing Selenium to Improve a Team's Development Cycle
28mFrom Resistance to Results: Navigating a Test Automation Tool Shift
33mStabilizing a Selenium build
23mLife After Selenium
32mHolistic cross browser testing with Selenium