PageObject checklist

How to define automation plan as checklist using PageObject pattern

Automation QA

Skype: pashidlos

Email: pashidlos@gmail.com

Agenda

  • Intro
  • Problems
  • Root cause analyse
  • PageObject pattern
  • PageObject checklist
  • Example
  • Pitfalls

Problems

  • Time consuming test cycle - no one waits results

  • Unstable tests - no one trusts results

  • Test coverage is not clear - no one understands results

Root cause analyse

  • Not defined automation plan

  • Writing tests according test cases

  • Lack of experience

Where is the plan?

When we build product we follow SDC

Why we don’t do this with tests?

What should I automate next?

If plan is not clear and you do not follow defined algorithm for separating tests into suites - expect duplicated testes in one hand and not covered parts in another

Test case

Action

Expected result

Result

PreConditions

Action 1

Result 1

passed

Test Case Description

Action 2

Result 2

passed

Action 3

Result 3

failed

Action 4

Result 4

blocked

PostConditions

Action 5

Result 5

blocked

Why test case is not what we should use for writing test?

First of all - they are made for human and autotest can’t use whole power of sophisticated test case

And as the result we have long (sometimes unstable because of that), dependant tests with blank spaces that could not be automated

But what is more important - failed test is not the answer what is broken

Each time you need investigate what went wrong and what spep failed

Checklist

Actions

Expected result

Result

Action 1

Result 1

passed

Action 2

Result 2

failed

Action 3

Result 3

passed

Action 4

Result 4

passed

In opposite to test case we have check list

It’s concept more suitable to test - atomic check - clear answer if function is working

Pros

Cons

  • Less text
  • Easier to maintain
  • Hard to use without system knowledge?
  • Impossible to use unstructured checklist

Less text means less time needed for maintenance

As a cons we have one:

So the structure of checklist is the secret key to success with this pattern

And it was always near

PageObject pattern

Let’s talk about PageObject pattern

Before using PageObkect pattern it was almost impossible to support tests

Each test contained not unique elements and it was almost imposible to understand what is going on in test

In some time, smart people decided that it’s easier to write and maintain code if you work with some kind of Objects

Great example of this for automation testing - is PageObject pattern

They said that let’s pretend that our site is a combination of pages

Each page contains own elements and own actions to deal with this elements

BasePage

LoginPage

BaseCheckoutPage

BaseCreditCardPage

PayPalCheckoutPage

VisaCheckoutPage

MasterCardCheckoutPage

And more over to avoid code duplication we will build a hierarchy of classes

If you have footer and header - describe them in BasePage and all your child classes will have them as well

If you have two logically similar pages - move general logic into parent class and describe only unique logic in descendant classes

So when you invoke a page methods - you see all functionality and all elements available there

Why not to use the same approach in writing our plan?

PageObject

Checklist

Again

Let’s pretend that our site is a combination of pages

And we can describe functionality on each of them

And we can describe each action that functionality can do

In other words we try to transform shapeless program into finite-state machine

And by testing all of them we can fulfill one of the code coverage criteria - path coverage

PageObject Checklist

  • Define “pages”
  • Define elements
  • Define actions

PageObject Checklist

  • Static content
    • View
  • Clickable elements
    • Click
  • Forms
    • Submit
    • View data in form
    • Validation

  • Header
  • Body
  • Footer
  • Sale banner
  • Top level navigation
  • Logo
  • Search
  • Mini Cart
  • Categories navigation

PageObject Checklist

  • Header
    • Sales banner
      • Can open sales page
    • Top level navigation
      • Can open Contact us page
      • Can open Sign In page
    • Logo
      • Can open Home page
    • Catagories
      • Can open Woman
      • Can open Dress
      • Can open T-shirts
  • Header
    • Can search by
      • Product name
      • Brand
    • Mini Cart tests
      • Can see product details
      • Can delete product
      • Can open Product page
      • Can open Cart page
      • Can open Checkout page

PageObject Checklist

This is the way how you can visualize checklist

We can group some tests in functionalities - for example Navigation

We can highlight majority of each test by color

You will start writing tests according priority

PageObject Checklist

PageObject Checklist

Why you need it:

  • Plan
  • Logical structure
  • Reveal gaps in your tests

Benefits:

  • You could count coverage

Pitfalls

  • Hard to work with huge checklist

  • Who will be responsible for synchronisation with tests?

Thank you for attention!

Page object checklist - Google Slides