Post on 20-Nov-2014
description
CODED UItest automation practices from the field
clemens.reijnen@sogeti.nl
www.clemensreijnen.nl
@clemensreijnen
Clemens Reijnen
www.youtube.com/clemensreijnen
www.slideshare.net/clemensreijnen
the field
complex user interfacesbig project structures
multiple environments
complex user interfacechallenges:
many controlschanging controls
complex flowmultiple screenschanging screens
…
practices:
edit the UIMapsearch and filter
reusable ’test’methods reusable test assertions
shared stepsloose coupling
low dependencies
complex user interface
UIM
apmultiple UIMap’s
a map per- screen
- scenario- part- team- …
UIM
apmultiple UIMap’spage object pattern
sear
chfilter, search and the tree
reus
eUIMap Helper Class
reus
etest all controls
shar
edreuse shared steps in Coded UI
UIM
ap m
ix different test projects for
tune your manual testsfor automation or remove them
cuite
Object Repository: Keeps UI Object definitions separate from automation code (no more UIMaps)
take aways:
• reuse steps and assertions• create helper classes• well defined uimap structure• use codeui builder• start from scratch or tune your manual tests• make clear test method names• separate the test intent from the test steps • no related tests• all test must leave the application in the same
state
complex user interface
big project structures challenges:
multiple teamschain of distributed projects
big teamsshort test timeframe
practices:
team collaborationbranch strategy code and test
versioning test caseno double tests
big project structures
colla
bora
te
work together__with work packages__on alm artifacts
bran
ch test same heartbeat as development
bran
chbuild
build
build
build
test
test
s
test
ste
sts
test
s
test
s
test
s
test
ste
sts
test
s
test
s
bran
chVisual Studio test projectswith Coded UI test case
bran
chUIMap per branch
UIMap’s don’t merge well
bran
chspecific test automation branch
bran
ch! well maintained regression set
bran
chMTM test plans with or without associated automation
bran
chMTM test plans with or without associated automation
test cases
test casestest cases
test cases
test cases
proj
ects
`
Team Project
Team Project
Team Project
Team Project
Team Project
Team Project
doub
le
doub
le
take a ways:
branch structure /multiple team projectsuse areas well
don’t make it too complex, some things can’t be done
test and developers have the same rhythm
big project structures
multiple environments challenges:
test for different environmentsno virtualized environments
short test cyclesless time for execution
practices:
execute with out SCVVMtest execution responsibility
execute from build on environments
multiple environments
infr
a
infr
a
infr
aconfigure for load or environments
exec
ute
build
take a ways:
multiple environments is possible without SCVVM
how are the environments usedwho executes the tests
multiple environments
1 Clean up of the Action log maybe re-execute, for more smooth Fast Forward.
2 Basic Coded UI. Only use the default generation, add your own assertion.
3 Advanced Coded UI. Customize the Coded UI and UIMap for optimization.
No investment in any kind of automation. Just click and test.
0
Test Automation Investment Levels
5 Execute them on multiple environments.
6 Execute them on virtualized environments.
7 …
Execute them on a single environment.4
Test Execution Investment Levels
keep it simpleDRY
start automating from the beginningdeveloper and test engineer in same room
don’t automate everythingknow what already have been verified
run them alwaysfail fast fail oftenlearn as a team
tools will help youcode rules for better testability
test automation in the same sprintstart from scratch or tune your manual
testsmake clear testmethode names
separate the test intent from the test steps no related tests
all test must leave the application in the same state before the test started
………
final notes
interesting read / watch
http://www.ie.sogeti.com/Product--Services/Software-Testing--QA-Services/Test-Automation/
http://www.thoughtworks.com/events/maintaining-automated-acceptance-tests
soon available
43