Capital One has a highly integrated environment, which creates many dependencies for its agile teams. Because these dependencies are often not completed until late in their sprints, Capital One faced prolonged integration and regression testing phases, and did not realize the expected improvements in quality or time to market. As technology leaders pushed for continuous delivery, testing needed to “shift left” and execute test in real time concurrently with development. Adam Auerbach shares Capital One’s experience implementing continuous testing. He explains the core principles of continuous testing, service virtualization, and the continuous integration/continuous delivery pipeline—and why testers need to understand and leverage these important concepts. Adam believes that testers need to learn basic development skills, including Ruby and Java, so they can take advantage of advanced automation practices. Because continuous testing is not easy and many companies have large populations of manual testers, Adam will provide a learning map to help you plan your personal and team’s transition.
Building Real-Time Data Pipelines: Stream & Batch Processing workshop Slide
Putting Quality First through Continuous Testing
1. Presented by Adam Auerbach
Putting Quality first through Continuous
Testing
2. 2
About Me
Senior Director of Technology at Capital One
• Tweet me @Bugman31 | Adam.Auerbach@capitalone.com
Responsible for Capital One’s Advanced Testing and Release Services Teams,
which include:
• Performance Testing
• Service Virtualization
• Automated Testing
• Release Management
• Test Data
• Quality Engineering Community of Practice
Before joining Capital One in 2013 Mr. Auerbach was with Chase and other
Financial and Insurance companies, in various leadership positions, with a
focus on Quality and Agile practices.
4. 4
Three years ago, we had a robust Hybrid Automation
Framework
QTP
Adaptor
EnterpriseTestAutomationPlatform
QTP Automation Components
…
VB Script
Adaptor
Services Automation Components
…
Mainframe Automation Components
…
SQL DB
SQL
Interface
XML
Interface
eTAFReusableComponents
DOC
Interface
. . .
Doc
temp
TE
Adaptor
eTAFAutomationDriver
QC
Interface
Main Frame Apps
Auto
Reports
eTAF Automation framework Artifacts
Version
Control
Web Services
Excel
files
Web App 1 Web App 2 MF App
XML
files
QC/ALM
Selenium Automation Components
…
Selenium
Adaptor
Web Apps
Not$Complete$
Complete$
6. 6
At the same time, we transitioned from Waterfall to Agile
7. 7
Early on, we tried to reuse what worked well in Waterfall
Design
Build
Test
Design
Build
Test
Sprint 1
Sprint 2
Hardening Test
Defect
Fix
Plan
Design
Build
System Test
Integration Test
Regression Test
Security Test
Performance Test
Deploy
8. 8
We adopted Agile with the hopes of delivering high quality
features to production, early and often.
16. 16
Real Time Automation
16
ACCEPTANCE TEST-DRIVEN DEVELOPMENT
• Team Focused
• Stress on Acceptance Criteria
• Add a Test
• Run all Tests
• Write Code
• Refactor Until Added Test Passes
TEST-DRIVEN DEVELOPMENT (TDD)
• Developer Focused
• Closer to Unit Level
• Add a Test
• Run all Tests
• Write Code
• Refactor Until Added Test Passes
BEHAVIOR-DRIVEN DEVELOPMENT (BDD)
• Team Focused
• Stress on Stories
• Add a Test
• Run all Tests
• Write Code
• Refactor Until Added Test Passes
17. 17
Everything tied into the Pipeline
17
• Unit Testing (TDD) – Tests written by
developers, which run as part of all code
builds
• Automation / ATDD – Tests written by the
team, either before or along side of
development. They run as part of the build
pipeline
• Continuous Performance Testing – Tests
to validate the system performs as
expected during peak loads, periods of
extended load, etc.
17
25. 25
Some lessons learned about adopting Continuous Testing
• Reuse proven Frameworks
• Scaled Agile
• Continuous Delivery
• ATDD
• Open Source
• Evangelists at every level and discipline
• Be ready for the need to educate everyone on everything
• Leverage dedicated resources who support and nurture the community
• Be prepared for additional costs
26. 26
What does this mean for me?
Developer
• Accountable for writing
“automatable” code
• Responsible for passing tests
(all tests)
• Become fungible in all aspects
of testing
Tester
• Must learn a programing
language
• Understand how to use CI tools
• Be able to apply enablers based
on current constraints
Everyone
• Work in Pairs or at least communicate like a pair.
• Take accountability for “Done” being working code and passing tests
• No more “throwing it over the fence”