Some slides I put together for a presentation that I never gave, regarding how developers and QA/QE can work together on UI test automation via ATDD with Selenium and page object model.
API, integration • Ever developed for non‐web applications? (e.g. desktop, mobile, telecom, hardware) • Ever hear about hooks, back doors added to code or test harnesses built to facilitate (automated) testing? • Like UI/class/object modeling? • Do you prefer writing code for tests or UI/modeling?
tests? E.g. UI, API, unit, etc. • Like creating & modeling page objects? • Like working on test framework code (!tests)? • Which do of the above do you prefer?
my thoughts, not industry standards… • ATDD = doing TDD but via the UI and hence (user) acceptance testing. • ATDD = ignore back end stuff – indirect testing via front end • ATDD = treat sections/components of UI as a unit and test as a UI unit test via ATDD (localized UI test)
different components (i.e. units) of UI with ATDD test that covers interaction of them (an integration test but not end to end test yet) • Test complete implementation with final true ATDD (acceptance) tests of end to end system flow.
API tests followed by ATDD or skip either of the first two, up to team. • Instead of or while creating TDD based unit (or even API) tests, do same for ATDD tests. • ATDD tests are conceived from user stories (in Jira) and more importantly the visual mockups & wireframes.
page object model (POM) for the page. • Start small with sections of the page (i.e. units). • As you build out the units, think of how they interact with each other, and account for that in the modeling (and later testing) • Expand to inter‐page interactions
(a.k.a. locators, for Selenium) or sets of them • Break down or define the actions or behaviors that can be performed on the page (i.e. this is where the bit of BDD comes in) • Group/organize the actions & elements into logical groupings (i.e. units). • Sort of building a test harness
vs low level. High level ones call sets of low level ones, abstracting out the details from the caller/user. • Define actions based on behaviors of elements. It can be: “selected”, “clicked”, “type‐able”. E.g. selectItemName(), clickItem() • We also want to represent state like isItemSelected()
model, we also need helper methods to extract data off the page ( getTextOfItemName() ) • We usually type data in as sets of data and consolidate them (rather than be atomic) as methods named fillSomething() like fillPRA(), fillPersonalInfo()
& modeling to not hard code anything into POM classes, with element locator definitions as an exception. • That means no test “data” hard coded as constants/variable or within the methods. • Such test “data” to put in under test case base/parent classes and passed in as arguments/parameters
should take arguments/parameters to define what it should do. • POM class methods w/o arguments do some default action, but that action must not be use default “data”. If it works with data, that data must be passed in as argument whether default or not. Add a wrapper method in base/parent test case that calls POM method with argument for simplicity.
mentioned previously is the data driven testing aspect of POM and ATDD. • POM classes don’t do assertions. • POM classes that need to check/verify state simply check state and throw exception if not meet criteria. Test case can then assert and/or handle the exception.
(might) have better UI modeling & programming skills • Devs (might) have better XPath and CSS selectors skills • QEs and RQA have (more?) experience with testing & testing techniques & test automation
to have… • Devs code the page objects (locators & methods) • QA/QE can write the automated test cases that use the page objects • Or roles can be swapped too or mix & match • Test framework/infrastructure code can be either as well
tells me that… • You can start ATDD for POM and test cases as soon as the visual specifications are available. • The specs don’t have to be final. The coding of the POM and test cases can be revised midway. • Revising midway is a lot easier than implementing from scratch near the end of the project
with the POM. • Test cases can come later if need be. • POM should be done when the UI is done. i.e. done in tandem. • That means tests can be written when UI done w/o having to do all the POM work first when project complete
cases don’t have to work from the start. Just like with TDD, they’re expected to fail until UI (or component) is complete. • For POM, you don’t need to know the element locator values in advance. Fill in later. • For POM, just need to know how to model the methods via spec before implementation. • Use pseudo code as needed in the beginning
thing… • But implementing all the POM stuff before writing tests could leave unused code. Better to develop POM while/when writing tests. • Well, doing that may fail seeing bigger picture of test coverage areas to cover than doing POM 1st. • Unused methods (and via code coverage check of POM) = test coverage gaps you need to fill by writing tests that use them. That’s the answer.
sure to think about missing integration test coverage between POM methods (or units) • Think about any missing user stories, or use cases not covered as well.
developers than QA/QE to share the automation workload • Devs might do their part faster than QA/QE • Devs (and as result PM, PMO via project schedule) can see that automation work not easy to do & takes time (to do well) by actually participating in the test automation. • Devs can improve on automation codebase with their programming & development skills.
dav1d1uu
contour_gara
memory1994
kazumain
ikumatadokoro
bkuhlmann
hanetsuki
hanhan1978
kishida
quiver
sonatard
77web
ivargrimstad
sachag
robhawkes
jakevdp
cassininazir
keavy
lara
davidbonilla
marcelosomers
geeforr
tammyeverts
samlambert
