Using Design Patterns to Improve Automated Testing
Test automation architect Greg Sypolt of Gannett | USA Today Network fell into a testing career by accident. As an on-call software engineer who spent many late nights early in his career discovering that many bugs were caused by a lack of test coverage, he developed a passion for optimizing software and building quality into every stage of the continuous integration pipeline.
At the upcoming SauceCon conference, Greg will present on, “Using Design Patterns to Improve Automated Testing.” Attendees will learn how to transform their new or existing automated tests to speed development and reduce maintenance impact.
A self-proclaimed technology geek, Greg is passionate about a few things: DIY projects (he recently finished his basement single-handedly), John Denver songs (one in particular, see below), outdoor sports and speeding up development with design patterns. In Greg’s view, a design pattern is a general reusable solution to reduce commonly occurring problems in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template on how to solve a problem that can be used in many different situations.
At Gannett | USA Today Network, Greg is responsible for leading the test automation architecture team to build and maintain testing solutions, evaluate test coverage, and champion continuous integration across 40+ Gannett products. The test automation organization at Gannett | USA Today Network has built a platform that enables teams to move at their desired pace through a balance of autonomy and collaboration. Their goal is to ensure every team is successful when using the self-service model. The vision is clear for test automation: they believe it starts with everyone on the team owning quality. Making this shift requires daily collaboration and planning to build quality into every stage of the pipeline.
Greg grew up in a small town in West Virginia (Take Me Home, Country Roads!) and now calls Northern Virginia home. He is a husband, father of three kids and an avid do-it-yourselfer. Greg enjoys presenting at conferences and blogging about automated testing strategies, testing frameworks, standards and continuous integration.
Join Greg and other presenters at SauceCon, the first-ever Sauce Labs user conference. SauceCon is a three-day event filled with training, workshops, best practices, and visionary content from the leading minds in automated testing. For more on upcoming SauceCon presentations or to register, visit the SauceCon website.
About the Author / Rebecca Cramer
Rebecca Cramer is a writer and communications strategist specializing in technology. With more than 20 years of experience across disciplines including marketing, internal and executive communications at companies such as Dell and Quest Software, Rebecca is passionate about creating and sharing good content of all kinds. In her spare time, she enjoys spending time at the beach and hiking in her native Southern California.
Many business leaders are planning to make DevOps the cornerstone of their IT transformation strategy. But, as surprising as it might sound, skepticism abounds regarding how major vendors address the DevOps transformation challenges—they confuse DevOps with continuous delivery (CD) infrastructure.
“We wanted DevOps and we got after a nine-month-long implementation a continuous delivery platform which speeds up IT operations without significant business value. How differently can you help?” the senior business executive of a major financial institution in New York sarcastically asked me during a conversation three months ago.
The business executive is right: DevOps isn’t a technology as I’ve been implementing it, it’s primarily an accelerated application delivery approach implemented in the form of a technology-enabled application delivery operational model. Adam Jacob, CTO of Chef, substantiates that fact in “The Secret of DevOps: It’s Always Been About People, not Technology,” when he says, “DevOps is about bringing together all the people you need to build and run your business effectively, and empowering them to move as quickly as possible towards their goals.”
Agile Admin’s Ernest Mueller in, “DevOps: It’s not Chef and Puppet,” confirms Adam’s point: “Chef and Puppet are individual tools that you can use to implement specific parts of an overall DevOps strategy if you want to use them—but that’s it. They are fine tools, but do not solve DevOps for you.”
How can we implement DevOps in line with business leader expectations? Three Amazon Web Services (AWS) Design Patterns I developed can help to get the best of DevOps on AWS cloud: Software Organization Factory, Digital Organization Factory and CD Infrastructure Factory. This article discusses the Software Organization Factory.
The Foundation of DevOps Value: Consequences to IT Service Delivery
Before delving into these AWS design patterns, a quick reminder of what DevOps is, its value propositions and, more importantly, what changes are needed in how IT services are delivered.
The Ignored DevOps Business Logic We All Must Consider
The combined effect of cloud adoption and the rising digital economy is changing competitive environments; it forces business leaders to focus on innovation and market responsiveness as the competitive differentiators.
The fact of the matter is, by facilitating access to technology, cloud accelerates entrance of several thousands of tech startups that take advantage of the recent technology innovations to substitute traditional products and services into digital. This creates a context where new entrants increasingly compete with established brands, forcing business leaders to seek value paradigms other than IT efficiency.
The business executive argues, “In these new markets, our concern is to increase customer value by delivering the right services to the right segments at the right moment. You guys need to change the IT paradigm; IT alone does not create that kind of value.”
Then, what should be changed in today’s IT approach?
The Two Dimensions of Modern IT: The Operational Model and the Continuous Delivery Infrastructure
The new IT paradigm advocated in my recent book, “Rethink Your IT with DevOps: The Complete Guide to Aligning Your IT to DevOps,” is the idea that business value results from two dimensions: organizational agility and technology efficiency. In other words, it defines modern IT as a two-dimension asset including the operational model and the continuous delivery infrastructure.
The timely delivery of innovation transcends IT issues; it not only cuts across your sales, marketing, post sales, application development and IT operations, but also demands concrete answers as to how to accelerate business prioritization, decision-making and problem solving. The operational model is where business and IT people, processes, practices and tools are combined to create agile and cross-functional environments. The following exhibit shows a typical DevOps operational model:
Typical DevOps Operational Model
Organizational flexibility for the sake of flexibility doesn’t make sense unless technology is leveraged to speed processes. This is where CD infrastructures come into play; throughout the delivery process, they build on IDEs to accelerate coding and testing, on versioning tools to convert software version into releases, on continuous integration (CI) tools to build releases and on delivery pipelines to ensure continuous delivery.
So, what is DevOps?
DevOps is a Technology-Enabled Application Delivery Model
DevOps is a combination of value, principles, processes and practices shared not only by developers and IT operations but also by the business. The goal is to help the organization deliver the right service to the right market segments at the right moment.
DevOps from the Business Perspective
As I’ve been implementing it, it’s a cross-functional application delivery model involving the business and IT and enabled by continuous delivery infrastructures.
By enabling and automating agile practices, the continuous delivery infrastructure makes the operational model agile and provides the business with the flexibility and velocity needed to meet competitive challenges.
Design Patterns as DevOps Implementation Engineering Framework
As suggested by the business executive, today’s DevOps implementations struggle to deliver the promised business benefits. The reason is, the operational model dimension is ignored in favor of tools and infrastructure.
Another reason is, DevOps is young and is still at the early stage of the technology maturity model; the expertise and engineering methodologies to implement it as what it is—a technology-enabled application delivery model—are lacking. That’s where DevOps transformation design patterns help.
What are DevOps Transformation Design Patterns?
In this article, the term DevOps transformation design patterns refers to general reusable architectures addressing specific DevOps strategy. They’re not necessarily implementable solutions, their primary goal is twofold:
Offer a neutral language for designing and implementing technology-enabled operational models
Offer an engineering approach that reduces design and implementation duration and effort
They’re formalized architecture design and implementation best practices for DevOps and platform-as-a-service (PaaS) services.
Design Pattern as DevOps Implementation Engineering Methodology
To meet its goals—technology-enabled application delivery model—the design pattern is structured around four items including purpose, principles, general solution and implementation techniques.
Purpose: Clarifies the purpose of the design pattern along with the DevOps strategy to address.
Principles: Are best practices formulated as rules and beliefs supposed to guarantee expected DevOps strategy benefits? They’re the determinants of the solutions to implement the DevOps strategy.
General solution: Are blueprints resulting from the application of principles? They summarize the functional and technical architecture of the DevOps platform to implement.
Implementation techniques: What are recommended technical approaches, solutions and tools to implement the general solutions?
Why AWS? Why would it be the catalyst for DevOps value?
AWS-ome Design Patterns That Will Change DevOps Implementation
AWS offers such a rich, varied and easy-to-implement services portfolio that it would be unfortunate not to take advantage of it to modernize IT. The rationale underpinning the value businesses can derive from their DevOps transformation experience with AWS is summarized in the following figure:
Rationale of the DevOps Design Pattern
It’s the belief that:
Certain principles determine the AWS services needed to deliver the application delivery model (ADM) architecture that guarantees value.
The implementation of the ADM using these AWS services results in AWS-based DevOps platforms that tangibly deliver expected benefits.
The Four DevOps Principles that Yield AWS Value
Let’s explore the principles I’ve been using to make CIOs happy with their AWS cloud:
Think holistic, not only IT: Reminds that transformation isn’t only about IT but the entire organization’s value stream from marketing and sales to development and IT operations.
Think cross-functional, not only IT: Reminds that the bottom line is to set up a cross-functional application development environments to accelerate business prioritization, problem-solving and decision-making, and meet time-to-value objectives. They’ll be the core value propositions of the DevOps platform.
Make it agile, flexible, and speedy: Reminds that agility, flexibility and speed are the catalysts for competitiveness and business value. They’ll be part of the DevOps platform.
Think PaaS: Reminds that AWS provides varied services for implementing state-of-the-art CD infrastructure.
Let’s illustrate three AWSome design patterns that’ll change DevOps experience with AWS!
Implement a Startup Mindset with the Software Organization Factory
The purpose is to implement DevOps strategies focused on time-to-market and time-to-value. It’s adapted for tech startups.
To implement the startup mindset, the DevOps four principles for AWS are implemented as follows:
Think holistic and cross-functional, not only IT: Relevant business and IT resources are put together in a single and dedicated service development team supported by appropriate Scrum and XP agile practices.
Make it agile, flexible and speedy: PaaS services building on agile practices and AWS infrastructure-as-code are provided to make application delivery processes agile, flexible and speedy.
Think PaaS: AWS infrastructure as code and DevOps tools are combined to implement a CD infrastructure in the form of a PaaS platform.
The DevOps platform resulting from the principles application is illustrated below:
Software Organization Factory
The “Startup Mindset” platform is structured around three components including the cloud-enabled operational model, PaaS and the CD infrastructure.
The operational model builds on a three-stage application delivery life cycle:
Plan & measure: It mobilizes business users, development, QA and operations staff on business prioritization issues using agile practices such as Scrum product backlog planning or XP’s user stories.
Develop & Test: It mobilizes business users, development, QA and operations staff across the development life cycle using agile techniques such as Scrum iterations, XP’s test-driven development (TDD) and behavior-driven development (BDD).
Release & Deploy: It leverages continuous integration practices to build and test releases prior to deploying to production.
Monitor & Improve: It’s outsourced to keep the service development team on its core business: developing software.
The CD infrastructure combines the followings services:
AWS CodePipeline and CodeDeploy to set up the delivery pipeline.
AWS infrastructure as code including CloudFormation, OpsWorks and Elastic Beanstalk to generate the CD infrastructure.
Summing It Up
The DevOps business benefits are real, yet, it’s young and is still at the early stage of the technology maturity model. The expertise and engineering methodologies needed to implement it as what it is—a technology-enabled application delivery environment—are lacking.
DevOps design patterns such as the software organization factory fill the gaps of today’s transformation practices:
They provide the architect team and the executive team a neutral language to discuss the business, technological and technical challenges and solutions.
By pointing out the agile practices to leverage, they simplify and accelerate the design and deployment of the operational model.
By pointing out the AWS services and features to leverage they facilitate the design and implementation of the CD infrastructure.
A self-proclaimed technology geek, Greg is passionate about a few things: DIY projects (he recently finished his basement single-handedly), John Denver songs (one in particular, see below), outdoor sports and speeding up development with design patterns. In Greg’s view, a design pattern is a general reusable solution to reduce commonly occurring problems in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template on how to solve a problem that can be used in many different situations.
Rebecca Cramer is a writer and communications strategist specializing in technology. With more than 20 years of experience across disciplines including marketing, internal and executive communications at companies such as Dell and Quest Software, Rebecca is passionate about creating and sharing good content of all kinds. In her spare time, she enjoys spending time at the beach and hiking in her native Southern California.
