Successfully reported this slideshow.
Your SlideShare is downloading. ×

Using Selenium and Cucumber to test a Healthcare Information System

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 20 Ad

Using Selenium and Cucumber to test a Healthcare Information System

Download to read offline

My talk about the architecture we're building out at Healthland for test automation, using Selenium-Webdriver, Cucumber, Page Objects, and a bunch of Ruby code. Given March 28, 2011 at the Ruby Users of MN in Minneapolis and April 6, 2011 at Se Conf in San Francisco.

My talk about the architecture we're building out at Healthland for test automation, using Selenium-Webdriver, Cucumber, Page Objects, and a bunch of Ruby code. Given March 28, 2011 at the Ruby Users of MN in Minneapolis and April 6, 2011 at Se Conf in San Francisco.

Advertisement
Advertisement

More Related Content

Viewers also liked (20)

Similar to Using Selenium and Cucumber to test a Healthcare Information System (20)

Advertisement

Recently uploaded (20)

Using Selenium and Cucumber to test a Healthcare Information System

  1. 1. Using Selenium & Cucumber toTest an HIS<br />Andy Tinkham<br />Selenium Conference, San Francisco<br />April 2011<br />
  2. 2. Background Information<br />Healthland<br />Web-based HIS (Clinicals, Financials)<br />Geared to rural hospitals (<50 beds)<br />.NET-based backend<br />UI is native HTML/CSS/JavaScript in browser (no Flash or non-standard elements)<br />Me<br />16 years of testing experience (almost all automated)<br />Started using Selenium in 2007<br />
  3. 3. Goals of Current Automation Effort<br />Run on all our supported platforms & browsers<br />Rapid deployment in new environment<br />Keep up with developers<br />Avoid vendor & script lock-in<br />Maintain test clarity<br />
  4. 4. Platform & Browser Support<br />Use Selenium 2<br />Develop tests on multiple platforms & browsers from start<br />
  5. 5. Rapid deployment<br />Minimize locations of change from version to version<br />No hard-coded data in scripts<br />Robust locators<br />
  6. 6. Keep up with developers<br />Plan test scenarios as part of feature planning<br />Minimize change locations<br />Business-focused tests & code<br />Use Cucumber so that more people can create tests<br />
  7. 7. Avoid Vendor lock-in<br />Open source testing tools<br />Encapsulate tool interface to facilitate swapping in other tools as needed<br />
  8. 8. Avoid Script lock-in<br />Use random data<br />Future behavior manager<br />Future long-scale random test driver<br />
  9. 9. Maintain clarity<br />Cucumber tests defined in plain text<br />Tests specify only relevant details<br />Test specifies verifications that are relevant to the point of the test<br />Future potential tie-in to test case manager<br />
  10. 10. Architecture<br />
  11. 11. Test Cases<br />Cucumber features<br />Created jointly with QA, Dev, BAs, and Product Managers<br />Created as part of initial story creation<br />Just enough source code to translate plain text into calls into Conceptual Layer<br />Specifies only required tasks and data<br />Random test driver<br />
  12. 12. Example Cucumber test<br />Feature: Allergy Notification<br /> In order to avoid causing an allergic reaction in a patient while providing treatment<br /> As a patient care provider<br /> I want to be notified of a patient's allergic status<br />Scenario: No allergy on file<br /> Given I have a patient with no allergy information<br /> When I visit a page with the allergy warning<br /> Then I should see that the patient has no allergy information on file<br />
  13. 13. Conceptual Layer<br />Provides methods that correspond to actual user tasks and goals<br />Ignores actual implementation<br />Gets additional required data not provided by test case<br />
  14. 14. Implementation-Focused Layer<br />Contains all interactions with actual web pages<br />Contains all calls to tool interface<br />Uses Page Objects and Control Objects<br />Uses ruby modules to handle repeated components bigger than a control<br />
  15. 15. Page Objects<br />Each page of the application is encapsulated by a single class<br />The class provides public methods that correspond to the things a user can do on that page<br />No details of page implementation available outside of class<br />
  16. 16. Control Objects<br />Each control type is wrapped in its own class<br />Allows for verification at control level<br />Removes need to remember how to interact with controls<br />
  17. 17. Support Layer<br />Contains code that is not specific to any user action<br />Data classes (Patient, Allergy)<br />Builders (create new patients, get existing patients)<br />
  18. 18. Challenges so far<br />Ramp up of staff unfamiliar with tools<br />Cross-platform database access<br />Using non-ASCII characters in test data<br />Firefox/Selenium/FortiClient interaction<br />
  19. 19. Future Directions<br />Behavior manager<br />Adding basic performance tests<br />Basic fuzz testing<br />Automated usability testing<br />Tab order<br />Keyboard navigation<br />Text rendering<br />On-site deployment tests<br />Random test runner/High volume automation<br />Parallel execution<br />
  20. 20. Questions?<br />Andy Tinkham<br />andy.tinkham@healthland.com<br />andytinkham in IRC #selenium and #ruby.mn channel<br />

×