1871 Hackers - March Meetup

Architecting test automation using Selenium

David Adams, QA Manager

Kapow Events

dadams@kapowevents.comwww.linkedin.com/in/dadamschi

about: David Adams

QA Manager @ Kapow Events

Currently architecting Selenium framework in Ruby

Built Selenium framework in Java

Architected automation framework in C#

Taught Selenium/Automation class for ForteKnowledge

Automating since 2009

Soft Elements of a Framework

Vision

Buy-in

People

Code base

Vision

Crucial

Provides a path for buy-in and development

No cocktail napkins

Buy-in

Top-level champion

Software development process

Output is a robust code base

Secure and repeat functional regression

testing; NOT load testing

Goal is NOT to replace people

People

Full-time resources are critical (at least 1)

Software development pipeline

Context switching is deadly

Credibility can get hurt

Automation gets shelved

Code base

Keep language to dev language (if possible)

Configuration management

Use same resources as development (libraries,

et. al.)

Hard Elements of a Framework

Test driver

Browser Driver

PageObjects

SeleniumGrid

Reporting

Parallelism

Test driver

RSpec, TestNG, Cucumber

Creates a structure for running tests

Provides a list or groups of tests

Creates Before*, After* dynamic calls

Browser driver

Selenium, WATIR

Provides browser commands (open, close/quit,

back, go to URL, etc)

Examines viewport for VISIBLE elements

If you can’t see it, you can’t act on it

PageObjects

Automation development concept

Everything is an object

Each screen or component is a PageObject

Instantiated to organize code in OOP model

Allows for discrete elements on pages

Allows for inheritance of

footer/header/elements

Create a BasePage

Provides page-level methods

Creates page segmentation (footer, header,

content)

SeleniumGrid

Hub/node model for execution of same tests

across different browsers and OSs

Need to maintain your own VMs (or

SauceLabs)

Need to maintain batch scripts on VMs

Reporting

Publicly accessible report of each run

Each test is a story, explain what happened

Each step is reported with inputs, click text; not

just pass/fail of the entire test

Parallelism

THIS saves time

Concerns:o data collision

o reporting

o development

Test Cases

Procedural

Every evaluation is a test

Evaluate in test, not in PageObject

Do NOT ask a test to do only one thing

Use PageObjects to make code read-able

Configuration Management

This is code!

Branch features for development

Allows for team scaling

Gotchas

Elements expire

Record/playback doesn’t work

DON’T USE XPATH

Browser updates cause Se to stop working