Many organizations today are moving towards automated testing for the right reasons, but unfortunately the vast majority experience a spectacular failure. Often at Meetups or talking to potential customers who have failed at one or more automation implementations, I continue to hear the puzzlement of why they failed. I often hear what great diligence they put into the planning and the talented people they hired to build the automation, so the questions begs why are they all failing?
After working with a number of clients to not only install an automated testing framework, but also implementing their agile process, I have consistently observed what I term a “killer dozen” automation implementation killers. Over the next few weeks I will discuss each of these issues in more detail.
2. www.AgileTestingFramework.com
About Tom Gilmore
Tom Gilmore (www.linkedin.com/in/gilmoretom) is a coach who
specializes in Agile/Automation/DevOps coaching. Tom is able to help
guide organizations through all aspects of their journey to Agile
development, automated testing or DevOps.
With over 20 years of experience in quality assurance, Agile development and automated testing. Tom is able
to help organizations focus on developing solutions to improve quality and decrease release time through
DevOps, Agile development and automated testing.
He has coached and trained a multitude of organizations. The short list includes, Forever Living, Evaluate to
Win, Able Engineering, Glynlyon, Choice Hotels International, Discount Tire, Concord Servicing, First
Solar, Edgenuity and Agworks. Tom enjoys his work, and does everything to ensure he shares his
knowledge with others who seek it, by founding groups such as the Phoenix Selenium Agile Group.
3. Preface
Many organizations today are moving towards automated testing
for the right reasons, but unfortunately the vast majority
experience a spectacular failure. Often at Meetups or talking to
potential customers who have failed at one or more automation
implementations, I continue to hear the puzzlement of why they
failed. I often hear what great diligence they put into the planning
and the talented people they hired to build the automation, so
the questions begs why are they all failing?
After working with a number of clients to not only install an
automated testing framework, but also implementing their Agile
or DevOps process, I have consistently observed what I term a
“killer dozen” automation implementation killers. In the following
slides I will discuss each of these issues in more detail.
www.AgileTestingFramework.com
4. Agenda
1. Unrealistic Planning and Expectations
2. Training
3. Standalone Teams
4. Starting Automation in the Wrong Place
5. Implementing in a Silo
6. Failure to Deal with Culture Issues
7. Choosing the Wrong Tool Set
8. Lack of Transparency
9. Not Truly Integrating with your Agile Practice
10. Failure to Take a Leap of Faith
11. Sorry, QA does not own Automation
12. DevOps/CI/CD
www.AgileTestingFramework.com
5. Unrealistic Planning and Expectations
• Unrealistic vision
• Lack of any baseline
• Leads to organizational loss of faith
• Use Agile practices
• Point test cases
• Break down components
• Once velocity is measured then add timelines
Unrealistic Planning and Expectations Blog
www.AgileTestingFramework.com
6. Training
• Traditional QA does not posses the required
skills
• Traditional recruiting practices will not find the
people with the needed skills
• A minimum skill set is required
Basic Programming Knowledge
Object Oriented Concepts
Development Tools
Unit Testing Basics
• You can train your resources, but understand it
takes time and money
Training Blog
www.AgileTestingFramework.com
7. Standalone Teams
• Agile/DevOps are about breaking down silos
• Agile states everyone is responsible for quality,
then why is their an automation team
responsible for all automated testing?
• Standalone teams will always be automating
after the fact
• Breaks the basic Agile tenant of having
releasable code after each iteration
• You won’t have self testing code, thus no CI/CD
Standalone Teams Blog
www.AgileTestingFramework.com
8. Starting Automation in the Wrong Place
• Don’t start with existing manual test cases
• Existing manual test cases are usually outdated
and not written in an easily automatable format
• Start with Smoke Tests (DevOps)
• Allows you to build out Page Objects
• High level smoke tests are a good place for new
automation engineers to get their feet wet
• Smoke tests have a high ROI if done right
• Follow TDD practices when deciding what to
automate next
Starting Automation in the Wrong Place Blog
www.AgileTestingFramework.com
9. Implementing in a Silo
• Investigation of tools needs to be handled in a
one team approach
• Consult with development, operation, agile
teams, agile leadership and other interested
parties.
• Automated tool has to fit into standardized tool
view
• Chosen automation tool must easily integrate
with CI/CD tool set
Implementing in a Silo Blog
www.AgileTestingFramework.com
10. Failure to Deal with Culture Issues
• Its all about culture
• New roles and responsibility for quality
• Automation success requires us to break down
the barriers between teams
• Understanding the truth about the skills needed
to automate testing
QA may not have the needed technical skills
Developers may not have the needed
testing/application knowledge
• Team members must work together to make
automated testing successful
Failure to Deal with Cultural Issues Blog
www.AgileTestingFramework.com
11. Choosing the Wrong Tool Set
• Comparing Selenium to commercial tools is like
comparing apples to oranges
• Commercial tool vendors do a masterful job of
selling gimmicks
• Understand open source tools have the concept
of plugins
• Does the tool easily integrate with the rest of
your CI/CD tool set?
• Know the right questions to ask
Choosing the Wrong Tool Set Blog
www.AgileTestingFramework.com
12. Lack of Transparency
• Explain to all parties, what's involved in the
implementation, what's being implemented
(order) and how much will be automated
• Initial implementation will decrease agile
velocity
• ROI in the long term
• Lack of transparency in terms of tracing the
automation back to business goals and features
• Need BDD/ATDD
• Go a step further with XBDD, Serenity or Allure
Lack of Transparency Blog
www.AgileTestingFramework.com
13. Not Truly Integrating with your Agile Practice
• True Agile requires you to automate during the
same iteration you code the app/feature
• If you don’t automate in the same iteration you
will never have CD
• Use BDD/ATDD along with Page Objects
• Automate in a TDD manner
• Automating outside the iteration results in
higher maintenance costs
Not Truly Integrating with your Agile Practice Blog
www.AgileTestingFramework.com
14. Failure to Take a Leap of Faith
• Building up and then killing the momentum
• Management going to their old playbook
• Promises, promises
• Brings frustration and kills morale
• Becomes seen as an acceptable practice
Failure to Take a Leap of Faith Blog
www.AgileTestingFramework.com
15. Sorry, QA does not own Automation
• Agile and DevOps
• Need to standardize tools throughout the
organization
• If your planning on moving to CI/CD or DevOps
QA can’t own automation
• Example – Pull Request Builds
• Think in terms of complete processes or the
one team approach
• Break down the traditional silos owning their
own tools
Sorry, QA does not own Automation Blog
www.AgileTestingFramework.com
16. DevOps/CI/CD
• Flipping the “Testing Pyramid” is required
• One team approach
• Have to standardize tools throughout the
organization
• Majority of testing must be automated (self testing
code)
• Automation tools must work with the CI/CD tools
• Smoke tests are treated almost like monitoring
• Remember, in DevOps we are also testing the
infrastructure code, in an automated TDD manner
DevOps/CI/CD Blog
www.AgileTestingFramework.com
18. Agile Coaching, Staffing and Training.
Learn more at www.torak.com
Learn more at www.AgileTestingFramework.com
19. This presentation was inspired by the work of many people and we have done our very best to attribute all
authors of texts and images, and recognize any copyrights. If you think that anything in this presentation should
be changed, added or removed, please contact us.
http://creativecommons.org/licenses/by-nc-nd/3.0/
www.AgileTestingFramework.com