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.

1. Using Selenium & Cucumber toTest an HIS Andy Tinkham Selenium Conference, San Francisco April 2011

2. Background Information Healthland Web-based HIS (Clinicals, Financials) Geared to rural hospitals (<50 beds) .NET-based backend UI is native HTML/CSS/JavaScript in browser (no Flash or non-standard elements) Me 16 years of testing experience (almost all automated) Started using Selenium in 2007

3. Goals of Current Automation Effort Run on all our supported platforms & browsers Rapid deployment in new environment Keep up with developers Avoid vendor & script lock-in Maintain test clarity

4. Platform & Browser Support Use Selenium 2 Develop tests on multiple platforms & browsers from start

5. Rapid deployment Minimize locations of change from version to version No hard-coded data in scripts Robust locators

6. Keep 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. Avoid Vendor lock-in Open source testing tools Encapsulate tool interface to facilitate swapping in other tools as needed

8. Avoid Script lock-in Use random data Future behavior manager Future long-scale random test driver

9. Maintain 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

10. Architecture

11. Test Cases Cucumber features Created jointly with QA, Dev, BAs, and Product Managers Created as part of initial story creation Just enough source code to translate plain text into calls into Conceptual Layer Specifies only required tasks and data Random test driver

12. Example 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 Scenario: No allergy on file Given I have a patient with no allergy information When I visit a page with the allergy warning Then I should see that the patient has no allergy information on file

13. Conceptual Layer Provides methods that correspond to actual user tasks and goals Ignores actual implementation Gets additional required data not provided by test case

14. Implementation-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

15. Page 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

16. Control 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

17. Support Layer Contains code that is not specific to any user action Data classes (Patient, Allergy) Builders (create new patients, get existing patients)

18. Challenges so far Ramp up of staff unfamiliar with tools Cross-platform database access Using non-ASCII characters in test data Firefox/Selenium/FortiClient interaction

19. Future Directions Behavior manager Adding basic performance tests Basic fuzz testing Automated usability testing Tab order Keyboard navigation Text rendering On-site deployment tests Random test runner/High volume automation Parallel execution

20. Questions? Andy Tinkham andy.tinkham@healthland.com andytinkham in IRC #selenium and #ruby.mn channel