Page Object GenerationLose the maintenance, increase the productivity

The Problem Failures guide our work The product is ever-changing Developers do not communicate

changes proactively (or at all) 40% of our time is spent accounting for

these changes Who can analyze 300 test failures every

night?

What Changes? Html id (i.e. “Locator”) Element type Major navigation path

Each will break most automated tests

Html id

If the id changes (e.g. to signinField), the test will break

The element will no longer exist

Element Type

The link is changed from a Link to Button

WebDriver will still look for a link

Navigation Path Pages are added Popups are introduced Buttons and forms are split up across

pages UI Look and feel “reset” WebDriver scripts don’t stand a chance

—you just start over

The Change Cycle

Wish List for a Solution Build in a mechanism for change

communication Account for the changes AS THEY

HAPPEN, not reactively Tighter integration with development Pass rate needs to be 97% or better,

with all failures accounted for within 24 hours

Page Object Generation Generate the pages on every build Web Controls are mapped to specific

WebElement types If the type of an object changes in a way

that breaks automation, the whole build fails

Let’s See It!

What you get A page, containing every element in the

UI Each element is aware of its Tab Including every Rich WebElement A Fields object, usable by those writing

Test Scripts

The New Change Cycle

The New Change CycleDeveloper

Change

• Significant underlying type (Text Input to Radio Button)

• Insignificant underlying type (Button to Link)• id changes for localization

Regenerate Model

• Compiler flags type change—breakage• Compiler ignores type change (Both are IClickable)• Page auto-updates id change—no breakage

Test

• Tester doesn’t know—fixed before dev check-in• Tester doesn’t know—Framework “absorbs” the

change• Tester doesn’t know—id is s String, stored in one

place

When change happens Html id changes

Who cares? Generation process normalizes names Unit test enforces uniqueness

Element type changes Developer fixes prior to check-in

Navigation path changes More rare, but failures show up within 24 hours Without all the noise, issues are easier to spot,

analyze, and fix

Where do you go now? You have a model of your system Use it to “analyze itself” The all-table test Role-based security tests Algorithms to

Iterate through every page looking for standards compliance

500 errors Forms Security issues (code injection, XSS etc)

Bottom Line We found 7 major regressions in 2008, the

last year of the “old” platform 12 in 2009 with >500 test cases 20 in 2010 with >1100 test cases More than 50 in 2011 with 1700 test cases Customer reported defects did NOT go

down, because… Velocity increased so much, features were

added at a much faster clip

Questions?