A place to share ideas, techniques, resources about all the testing activities needed to feel confident about delivering value to our customers frequently and sustainably.
Category: DevTestOps
Continuous Testing in a seasonal business
For many countries around the world, the heaviest retail season is already starting. In the U.S., Black Friday, the heaviest day for brick-and-mortar retail sales, and Cyber Monday, when online retailers get the most traffic, are almost upon us. The delivery teams responsible for the software that powers those retail engines must be busy.
Or… are they on a steady cadence, practicing continuous delivery, and not feeling stressed? Teams that continually release small changes to production should be able to do so in a sustainable way. Hmm.
Most business domains revolve around some kind of seasonal pressure. Some industries have a big trade fair, where everyone shows off their new product. All development is aimed at that big event. Tax preparation products will be used more heavily when people have to file their returns. Government regulations may change annually, requiring software updates to remain compliant.
How do teams achieve continuous delivery, including testing at all parts of the DevOps continuous loop, with seasonal spikes in demand? Please join me along with , ,
,
and
as we share our own experiences with these challenges in a webinar panel hosted by
, Thursday, 14 November. We hope you can join us live and bring your questions. Please
to attend or to get the link to the recording after the event.
Running API Smoke Tests in Your Continuous Deployment Pipeline
By Kristin Jackvony
Each year, more software companies switch to a microservices architecture using Application Programming Interfaces (APIs), because APIs make it easy for different teams on a project to access each other’s resources. APIs also enable software companies or individuals to get data from each other: for example, Twitter has an API that is used by many small businesses to retrieve tweets related to their business for display on the business’s webpage.
Another great feature of APIs is that they are smaller than a monolithic application, which means that they can be deployed frequently. At the company where I work, my team has eight different APIs, and we have eleven different environments that we deploy to. If we were relying solely on manual testing to verify that the APIs had been deployed correctly, we’d have to run eleven sets of tests for each API release. And if we were deploying more than one API at a time, which we often do because our APIs work together, we could be running 88 sets of tests. And if we deploy every two weeks, those 88 sets of tests will amount to a lot of tedious, repetitive testing!
We’ve solved this problem by setting up automated API smoke tests that run with every deployment, to every environment. In this article, I’ll describe how we decided what to test and how we set up our smoke tests. We used
Postman, Newman
,
Powershell
, and
Octopus
to set up our automated smoke tests, so I’ll be describing what we did with those tools. However, these strategies could be adopted to any continuous deployment (CD) pipeline.
Step One: Decide What to Test
The main purpose of smoke tests is to do some simple, high-level tests to ensure that the deployment was successful. This is not the place to test every single thing that your API can do. When we chose what to put in our smoke tests, here is what we considered:
We set up one “Happy Path” test for each endpoint- that is, one test that is expected to be successful. For example, a GET request for a resource with a specific ID would be expected to return that resource. You’ll want to test each endpoint once to verify that each one is working as expected.
If there were major variations in how a specific endpoint would be used, we added one or more tests to check those variations. For instance, we have a file retrieval API where a file can be retrieved by two different methods. The endpoint looks the same, but the bodies of the requests are different. So we added one test for each method.
For endpoints which required a certain level of security, we added a test to validate that a request without the appropriate authentication would NOT return information, and would instead return a 400-level error.
We did not add any other negative tests, such as a POST request with data outside the allowed parameters, because we didn’t feel that those were necessary to ensure that the API was working. We instead ran those tests as part of a nightly regression suite.
Step Two: Export Your Tests
We used Postman to create our API tests, so when the tests were created, we exported both the test collection and the test environment file into JSON files. For those who are not familiar with Postman, a test environment is a group of variables that can be referenced in a collection of tests.
Step Three: Write a Script to Run Your Tests
Postman has a command-line tool called Newman that can be used to run a test collection, so this is what we used to run our tests. We created a Powershell script that would run the Newman command.
Step Four: Create a Deployment Step to Call Your Script
Once the Powershell script was ready, we set up a deployment step in each Octopus API deployment project that would run the test script. If the script failed, the deployment would fail.
Step Five: Organize Your Variables
Variables are often a consideration when running smoke tests in different environments. For example, in your QA environment, your test user might have an ID of 340, but in your Staging environment, your test user might have an idea of 620. Another issue with variables is that sometimes for security purposes, you might not have access to passwords or keys in Production environments. This was the case for our team, but fortunately Octopus has the values we need to run our tests in Production, so we could solve the problem by having Octopus pass the values that we needed to our test script.
There were three different kinds of variables needed for our smoke test:
Type 1:
Variables that were unchanging for each test environment, such as “firstName”: “Prunella”. These variables could be put directly into the Postman environment, so nothing more needed to be done with them.
Type 2:
Variables that changed for each test environment, but did not need to be kept secure, such as “userId”: 340. These variables were added as Octopus variables in this fashion: “smoke.userId”, and the value of the variable was set for each environment; for example, QA was set to 340, Staging was set to 620, and Production was set to 450.
We then used the variables like this:v
When we called the Powershell script in Octopus, we sent the variables set in Octopus to the script.
In the Powershell script, we accepted the Octopus variables sent in and assigned them to Powershell variables.
When we used the Newman command in the Powershell script, we sent the variables in the script to the Postman environment.
Newman used the variables sent in the Powershell script, combined with the variables in the Postman environment to run the Postman collection.
With our API smoke tests running in Octopus for every API and in every environment, we can feel confident that any big problems with an API deployment will be detected right away. Furthermore, we can test in Production environments even when we don’t have access to sensitive API keys. Having automatic deployment smoke tests frees us up to do other types of testing, such as manual exploratory testing and security testing, as well as write more test automation for nightly regressions.
About Kristin:
Kristin Jackvony discovered her passion for software testing after working as a music educator for nearly two decades. She has been a QA engineer, manager, and lead for the last ten years and is currently working as a QA Lead at Paylocity. Find me on and .
DevOps, DevTestOps, Dev*Ops… what’s in a label?
by Lisa Crispin
The catalyst for this
community website
was a “DevTestOps Manifesto” dreamed up originally by a teammate and myself, then with input from the testing and DevOps community. After lots more discussions with practitioners, we realized that what we had were some
guiding principles
rather than a “manifesto”.
We also had a lot of discussions about the “DevTestOps” term. I liked it because when a lot of people see the word “DevOps”, they think of programmers/coders plus operations specialists, and don’t include testers or other specialists. Having “Test” in the label could help make testing and testers more visible. After all, testing is the heart of DevOps and continuous delivery. Others pointed out to me that using the term “DevTestOps” could also be construed as promoting silos again, which is the opposite of what agile development and DevOps are all about.
Who’s included in “Dev”?
Everyone who helps to create, deliver and maintain a software product is a developer, and that includes testers. The term DevOps came about 10 years ago because a lot of organizations said they had adopted “agile”, but they were still throwing code over the wall to operations teams to deploy it, nurture it in production, and carry the pager. After “DevOps” was established, we started hearing about “DevSecOps”, which has become an established term and specialty. I’ve seen other labels merged with Dev and Ops, like DevAIOps and DevUXOps.
The Whole Team Approach to building quality into software has to include operations folks, along with product people, designers, business stakeholders, sales and marketing, business analysts, database experts, data scientists… we are all in this together. It may be useful to insert another label between Dev and Ops, to highlight an activity which some people may not consider in terms of the practices needed to succeed with continuous integration and delivery, but “DevOps” is a fine, all-inclusive term.
Labels and goals
Personally, I wish we did not have to use any kind of labels like “agile” and “DevOps”. Our aim is to continually improve how we build software so that we can delight our customers while enjoying the process ourselves. But it seems that we humans love to label things.
Our goal here at TestingInDevOps.org is to get testing and QA professionals interested in learning about DevOps and continuous delivery, and provide resources to help them learn. Naturally, we welcome people in any specialty or role to learn how testing activities fit into and add value to DevOps culture and practices. We especially want to make testers visible in this DevOps and CD world. People with deep testing skills and experience help everyone on their teams learn testing skills and find ways to bake quality into their product during the whole continuous loop of discovering what customers want, building delivering those features.
Let’s find more great ways to deliver small, valuable changes to production frequently, at a sustainable pace that lets our teams enjoy the journey!
State of DevTestOps survey
by Lisa Crispin
Yes, the State of DevOps survey is the gold standard for truly scientific and valuable surveys, and you should both fill it out every year and read the reports and the book
Accelerate
! And, there are lots of testing-related surveys out there. They all provide interesting information that help us think about our profession and where we need to grow. Why yet another testing-related and DevOps-related survey? Because we have so much more to learn!
It’s the 2nd year of the
survey. I was happy to help with it again, because last year’s survey provided some valuable and thought-provoking
. It generated some interesting conversations and led to productive panel discussions for our Testing in DevOps community here as well as other webinars (see the
webinars and videos page
here for links to those).
Testers need to learn about DevOps and continuous delivery, and engage with people in other roles in their organizations to help their own teams shorten cycle times and improve their ability to build quality in. DevOps needs testers –
testing is the heart of DevOps
. Getting some insights as to how teams are progressing in DevOps practices and culture, as well as how they have incorporated testing activities and testers, is vital so that we can find more ways to add value as testers/testing coaches/testing consultants.
Whether your team has started to embrace DevOps and continuous delivery or not, please take eight minutes (or less!) to fill out the
, and share your team’s experiences with what many people now refer to as shifting testing to the right – testing activities during the release process and in production. You don’t have to give your email or any other personal information.
I am going to share five handy tips for testers in today’s DevOps world from my experience in this post.
Learn Continuous Testing
The first and foremost thing to learn about is: what is
continuous testing
? How do DevOps processes impact the tester’s approach for transitioning from traditional waterfall to agile testing? Before starting with continuous testing, for each sprint, we were testing incrementally and then did the regression testing before deployed to production. Up to now, our sprint cycles for some projects have been weekly or bi-weekly. But this cycle becomes too long to roll out a feature or customer request in a timely way. So, we have adopted DevOps in our process.
Testing over the whole lifecycle by shifting left and shift right, i.e. testing continuously from beginning to end.
Learn about DevOps jargon.
I recommend taking a look at
Lisa Crispin’s course
in Test Automation U to learn basic concepts and terminology around continuous delivery and DevOps. That will help you communicate and collaborate with everyone involved in delivering your product, including operations and infrastructure specialists.
A Culture Shift from an Independent Team to Whole Team Approach
In a waterfall methodology, testing is confined to an independent verification and validation team. In agile development, it becomes a collaborative effort.
People come with baggage: preconceived notions, past experiences, prejudices. The primary responsibility is educating the team about DevOps culture.
In DevOps culture, the focus is on the product, not building fiefdoms and amassing political power. The DevOps slogan is, “Everyone involved with delivering software is responsible for delivering high-quality software.” In short, the delivery becomes a shared responsibility.
Build A Successful Test Strategy
Building the right test strategy is critical in continuous testing. When we have 500 automated tests, we can’t execute all the 500 tests for each change committed in the pipeline. It will take too much execution time. So, we have analyzed and prioritized the test cases by their core functionality as well as using input from the customer support and business teams. In the end, we have come up with 100 automated regression tests which are enough to give us confidence that the latest change hasn’t broken existing features.
Don’t Just Make The Tests Pass, Focus on Efficiency
When we started with DevOps, in our continuous pipeline, our automation tests failed in between or at the last step of the pipeline. We analyzed the test results and the error logs. Most of the errors were due to timeouts or because of the new feature or enhancement changes. We have updated our scripts periodically to take care of this. After deployment, when we cross verified the product/project using manual exploratory testing, we saw a few more failures. Then we did a brainstorming session with our entire product team to make our automated tests more efficient. For this, we have created/updated the automation scripts in the preproduction phase to save time and resources.
Choose Your Tests Wisely
This is related to the points discussed in the previous paragraph. When we started doing the deployment through the DevOps practices, as testers, we need to choose our tests wisely to add those to the pipeline. Along with the regression test suites, 24/7 monitoring should be added. This helps us to understand how the product is to be used by the customers. For choosing the tests, we use input from the user behaviors that we learn from our monitoring tools, as well as discussions with the business stakeholders.
I hope the information from this experience helps you to enhance your testing!
I hold a Certified Software Test Manager and Six Sigma Green Belt. I have a passion for testing and learning, as well as implementing and mentoring the latest automation tools. I spent the last 16+ years working in IT, with a focus on software quality assurance and software testing. I am Testing Guild 2018 conference speaker and a frequent blogger. I manage a fast-growing, dynamic team bringing you
https://www.qatouch.com
. Twitter: . Linkedin: . Blog :
www.bhavaniraj.com
There are different interpretations of theterm, ‘DevOps’. However, most peoplewill endorse the idea – ‘DevOps also focuses on the organization change tosupport great collaboration between the many functions involved’.
Despite the focus on collaboration andorganization change, a critical part of DevOps is the enabling technology. There are different aspects of thetechnology. Continuous deliveryautomates the entire process of delivery, including building the software,validating the build and progressing through other steps in the form of apipeline. A much more elaborate part ofthe technology is Infrastructure as code (IaC). Infrastructure as code was pioneered by Amazon Web Services (AWS). Thereare newer entrants such as Microsoft Azure and Google Cloud.
The main concept of an IaC service, likeAWS, is to access infrastructure such as servers, databases and networks, asvirtual resources. It’s critical to beable to create and access the infrastructure
programmatically
. You can then treat the scripts which interactwith the infrastructure as software and use software development principles, todevelop and manage your code/infrastructure, such as source code control andcontinuous delivery (of infrastructure). IaC provides the ability to scale up and scale down components at will,greatly increasing the economy while meeting customer/market demands.
DevOps isoften introduced with examples from Netflix and Facebook. However, the software industry is vast. It includes both software product companieslike Netflix, but also includes enterprise software development in banks,telecom, government. It also includesservice providers. Given the universalavailability of cloud-based infrastructure and the accessibility due to lowcost and the pay-as-you-go model, the size of teams adopting IaC can varywidely. The two-person team creating amobile app, or the government department creating a health portal, is verydifferent from a team in Netflix. Thechallenge for
all
teams is preventing problems when deploying IaC as part ofDevOps.
How can you anticipate problems?
One way to anticipate problems is to askquestions.
A database as a service, like AWS RDS, isvery appealing both from a technical and business point of view. However, what happens when there is downtime,even for a few seconds, due to routine maintenance? For non-critical applications it may notmatter (you may still want to find out if the application is affected). For critical applications, you may want tocreate a highly available solution.
If you are working on an existingapplication, how do you replace the single instance of the database with ahighly available solution? Are there anymaintenance windows? What is the natureof the business? Is the business seasonal?
Here are some questions we might ask:
For a database as a service, what happens whenthere is downtime, due to maintenance?
Does the business have a maintenance window forreplacing the database?
What is the nature of the business? Can they afford downtime?
Is the business seasonal? Are there peak times when they can’t afforddowntime?
You could generalize the first question as,‘For
any
cloud-based service, what happens when there is downtime?’ You could also ask, ‘For
any
cloud-based service,what happens when you need to upgrade the version?’
Here is a question for
you
to practice (my response given below):
What happens when you need to upgrade thelanguage version (e.g., node.js) of a function as a service?
As an aside: Is this a problem with a cloud-basedservice/Infrastructure as code? Wouldthis have not been a problem if you controlled the server/environment, i.e., with physical servers?
How do you ask questions?
You want to ask questions which are
open ended
. You could ask, ‘What cancause the storage to become full on an EC2 instance?’ or ‘What could cause theinstance to become unresponsive?’ Theanswer will depend on your application and specific circumstances. (You will probably set up alerts for diskutilization reaching a threshold. However, alerts don’t replace the thinkingabout what might go wrong.)
You want to take asking open endedquestions a step further. What you arereally doing is looking for
questionsthat you hadn’t thought about
.
The idea of asking questions might seemvery unstructured. You can
structure
your thinking by using anapproach to generate ideas. One suchapproach is using the mnemonic, SFDiPOT, to structure your questions. SFDiPOTstands for structure, functions, data, interfaces, platform, operations,time. You could use S-structure to thinkabout the different components of the system such as the database, lambdas and instances and how they mightpose a risk. In the case of IaC, itisn’t a physical product, but an entire platform.
You can use another mnemonic CIDTESTD(Customers, Information, Developer relations, Test Team, Equipment & Tools,Schedules, Test Items, Deliverables) to generate ideas. If you are working with an enterpriseapplication like Adobe AEM, do your DevOps engineers have enough knowledge ofthe product? If not, does that representa risk? (We used the letter T, which stands for (Test) Team, to think aboutrisks related to the nature of the team).
When you ask questions, you want to holdyourself and your team
accountable
andincorporate feedback. Retrospectives andpost-mortems can identify questions that weren’t asked. You
also
want to identify how you could have generated ideas which would have led tothose questions.
Here is what I would ask when thinkingabout upgrades to the environment (e.g. node.js) for a function as a service,like AWS Lambda:
When we look at the Lambda code a few years fromnow, will it make sense to a new person/team?
Do we have automated tests for the larger functions?
Are there functions used for infrastructure, asopposed to, being used by the application?
Do we have any automated tests for the Lambdafunctions?
Are there differences in the quality of codewritten by the infrastructure team as opposed to the application team?
Will we be able to roll back the functions afterupgrade, in case there are problems?
Is there a development environment for theLambda functions, i.e., does the dev environment include the Lambda functionsespecially the ones used for Infrastructure?
Will the development and production environmentsbe kept in sync (for the next few years)?
Can we track differences in the development andproduction environment?
Here are a few more general questions youcould think about when working with infrastructure as code:
What can cause a component to not respond?
When can an instance not respond?
When can a component run out of capacity, e.g.,storage?
Can you upgrade a component to a highercapacity?
Are higher capacity components always availablein the region that you are working?
Does the region that you are working in, impactyour available options? Does that impactyour choices for increasing capacity in the future?
Beyond questions
There are other activities which cangenerate ideas on risk, for example, stress testing a component or creating arealistic customer environment, including real time data. These activities can also be used to generatequestions. Asking questions is part ofthe much broader activity of
critical thinking
.
For a start, I recommend beginning with asking questions in a work situation(see example on functions as a service above). You should accompany that by using retrospectives to evaluate questionsthat weren’t asked and identifying the ideas or activities which could have ledto those questions.
The idea of asking questions related to IaCcan form a foundation for thinking about your model for anticipatingproblems/risk in DevOps. It may alsolead the team to make inroads into critical thinking.
SFDiPOT and CIDTESTD are part of the Heuristic Test StrategyModel created by James Bach (
)
The idea ofusing questions to identify risk has been used earlier, e.g., ‘a test case is aquestion that you ask of the program’, in ‘What is a Good Test Case?, StareastConference, May 2003,
Nilanjan Bhattacharya
Nilanjan works as a DevOps Delivery coordinator for AC3 in Sydney. AC3 is a multi-cloud service provider and Australia’s leading AWS Premier Consulting Partner and AWS Managed Services Provider.
Nilanjan has a background in software testing and project management. He has worked with a variety of software teams, including software product teams. His experience in analyzing customer support issues and working with successful software products with a multi-year lifecycle, provides a unique perspective on software quality and defects.
We’re adding webinars to our Testing in DevOps community learning opportunities! Our first one is a panel discussion with awesome leading practitioners , , , and I will also join! Many thanks to
for hosting the webinar (they host this site as well).
So what will we talk about? As many of our guest posts here have pointed out, DevOps is about
the whole team
– including operations specialists – working together to deliver value to customers frequently, without drama or stress. It’s that continual loop: together we identify the most valuable capability to delivery next.
In the webinar, we’ll talk about how we build and test it, test and build it, together. We have created a pipeline to deploy it to production, together. We’ll probably get into topics such as monitoring and observability to learn how customers use the product and respond to problems, and get ideas for the next valuable feature slice to build. We will answer your questions!
For more details and to register, please go to my
(I am too lazy to copy it all over here!)
We welcome your questions in advance, just tweet them to @! Or, simply ask on the day in the Zoom chat. We look forward to an insightful and fun discussion!
The different pages of this website have links to so many helpful articles, podcasts, videos, webinars, books and more. Here are three that you might want to prioritize to read or listen to first, to build your understanding of devOps, continuous delivery, testing in production, and what makes software delivery teams successful.
Charity Majors on testing in production
Does the phrase “testing in production” scare you? Historically, it was an irresponsible practice – throw our changes into production and let the customers tell us what’s wrong. Today, it is a leading practice. In her recent article “
I test in prod
“, says it’s a superpower!
Most interesting man in the world
Charity points out that we test in production all the time. The key is to do it safely. It takes an investment in tooling and training. This is especially important with the complicated distributed apps we support today. We need to test more than the code – we need to test the whole system, including the environment, the infrastructure, and the customers.
There’s so much to learn in this one article, from Charity’s experiences and insights. She breaks down the three aspects needed to start testing in production in a useful and beneficial way: technical, cultural and managerial. Plus, she works in so many classic memes to hilarious effect! Give it a read and start overcoming the fear of what will happen with each new change released to production.
Theresa Neate: Stop the whisper campaign that devOps means no testers needed!
We’ve been fortunate to have a
guest post
here from , one of the leading testing practitioner who is also a leader in devOps practices. She gives us a preview of her
TestBash Australia
talk in this
Ministry of Testing podcast
with Michael Lang.
Theresa starts with one of the best explanations of devOps and continuous delivery that I have heard. If you are not yet familiar with these terms, listen to the first few minutes of this podcast.
One of the most important messages Theresa delivers here is that we need to stop the “whisper campaign” that devOps means “no testers needed” and “no testers welcome here”. We know we testers can add huge value by participating in devOps practices and helping our teams succeed with continuous delivery. it’s up to us to use our natural curiosity, learn important new skills, and show what we can do.
Photo from Christina Morillo on Pexels.com
This podcast is less than 30 minutes long, and it’s going to be the best half hour you’ve invested in your career in awhile.
I wish I could go to TestBash Australia and participate in Theresa’s workshop “Hands-on Intro to AWS and a Taste of DevOps, for Testers”!
Accelerate: State of DevOps 2019
This led by is building on 6 years of data from a wide group of respondents. The executive summary alone is a gold mine of information about what practices and capabilities correlate with team success.
From the
The report includes insights into testing practices. For example, though previous years found that test automation has a significant impact on continuous delivery (CD), this year they found that automated testing positively impacts continuous integration (CI).
The ability to reproduce and fix failures, gather feedback from tests, improve test quality and iterate test runs quickly also ties into automated testing.
The report also focuses on disaster recovery testing. One finding is that organizations who do disaster recovery testing and create and implement action items based on what they learn from it are more likely to be in the elite performing group.
The report delves into the “Four Key Metrics” of software development and delivery, one of which is culture – too often overlooked by organizations. To improve, organizations need to start with the foundations, and adopt a continuous improvement mindset.
Read the report and help your own team be one of the many teams who are continuing to improve their ability to deploy small changes to production frequently, while enjoying their work.
We’ve embarked on work to move off our legacy monolithic Oracle Commerce platform and are creating a
microservice
-based architecture hosted in . As part of this we have created a Platform (
John Lewis
Digital Platform, JLDP) which enables teams to get started quickly through providing key capabilities that are needed by all teams e.g. Google Cloud environment, code repository, path to production, telemetry. We call this our “
”. We started out on this journey as it was observed that we were not delivering business value quickly enough and technology was believed to be a key impediment to doing this.
One of the key initiatives we undertook as part of building the platform was being able to measure the progress of teams working on the platform through their approach to
Continuous Delivery
. Previously we had lacked this information and could not make data-driven decisions about our service/application health. We wanted to avoid this and build it in to the platform from the start.
We started capturing much of the data through spreadsheets based on data visible in Google’s logs. We’ve iterated on this and have developed an application which we call the “Service Catalogue”, that brings together the various metrics we’ve collected on health of a Service (one or more microservices to achieve a particular outcome), along with key information on each service/application e.g. Search.
Lead Time to Value
Our initial focus was to show that access to the Platform was no longer a constraint in getting a service live to customer. We wanted to capture some information that proved this was no longer the constraint. We were able to quickly show our
service creation lead time
took hours not months as it had been previously.
We then looked at capturing the lead time of the first service deployment to production, we called this our
onboarding lead time
. For the platform this evidenced that teams had managed to navigate our paved road and deployed at least a “hello world” to production. This confirmation also reduced the platforms reactive work load and was a key message to teams when onboarding them, get to production early.
The final addition was to measure of
lead time to first value
. This was our final measure of success and confirmed the team had made their service live to customers.
JLDP v2 Services – Lead to value
Deployment Indicators
Once a team had deployed and were live to customer, we wanted to continue to understand their continuous delivery on the platform. We set out to capture more information:
deployment intervals
,
deployment lead time
and
deployment throughput.
We have again used systems data to capture this information, looking at git commit history through to container deployment to derive the data. We are looking to observe teams’ approach to agile principles and lean methodology through their continuous delivery practice.
The
deployment interval
captured is the time between deployments to our production cluster. We want to see a low interval and consistency which suggests a team is then deploying frequently and continuing to work on the Service.
The
deployment lead time
is then how quickly a code change gets through the pipeline to production. This tells us how long it takes a team to get a change live and again looks for consistency and a short time from commit to production. This tells us that teams can get change through to production quickly through their pipeline and their ways of working.
The
deployment lead time
is then how quickly a code change gets through the pipeline to production. This tells us how long it takes a team to get a change live and again looks for consistency and a short time from commit to production. This tells us that teams can get change through to production quickly through their pipeline and their ways of working.
Delivery Indicators (Interval Time, Lead Time)
Deployment throughput
then helps us confirm overall deployment volumes across the platform helping us to evidence our overall deployment trends within teams and services. We have the data for this but have yet to fully integrate this in to our Service Catalogue, though we can present it on a on-demand basis.
Live to Customer — Monthly Service Deployments
What did we learn?
These data points were then critical for our initial conversations with teams which we called platform research. We used the data to talk to teams that were taking time to get to their first customer and understand what might be constraints in either the platform or the wider delivery process. We are also trying to build a product not just a platform and so the capabilities we had will be informed through the customers (service teams) running on our platform.
We learnt quickly that we’d started to unblock some key constraints.
The access to the platform has reduced the provision of infrastructure to teams from months to hours.
Our overall deployment throughput was increasing substantially from 10’s of deployments a years to 1000’s.
Total deployment throughout the yearContinuous Delivery patterns (Lead Time: Blue, Interval Time: Red) – so much to read in these graphs
Through further ongoing research we learnt that there were common service constraints
Teams were struggling with the security process which was designed for large waterfall projects and hadn’t caught up with a more agile, microservice-based architecture.
Teams had too much work in progress. We had teams which were requesting multiple services without getting their first service live to customer.
Teams had external dependencies, usually around integrations outside the platform ingesting data from other external systems.
Teams were attempting to get to feature parity before going live to customer.
Teams were still attempting to undertake end-to-end functional or performance testing with external dependencies.
Change freeze still plays a part in reducing consistency and increasing batch size.
These were all things we could now start initiatives on to improve lead time. For example, we have created a Platform Security team to help engagement with teams in to our current security process with a goal of changing and developing a pattern more consistent with our delivery approach.
It also helped us inform the direction for the platform. We increment the version of our platform quarterly (although deploy daily). Each increment we aim to delivery new capabilities such as improved service creation, monitoring and logging capabilities and resilience, all focused on building a product that helps the teams running on our platform go faster or improves their stability.
What Next?
So far we have focused on measuring our continuous delivery indicators to show throughput to production. Operability is the next key focus. Teams are now starting to support their services, and the traditional operational structures which supported many of the operability aspects are now transferring their knowledge on processes to teams.
Continue to develop the platform with operability as a focal point. We have already provided teams with indicators of health e.g.
based on Operability patterns outlined in .
We want to combine this with alerting focused around and
.
We will look to expand our Service Catalogue to include
deployment stability indicators. Deployment Failure Rate
(number of failed production deployments and duration between),
Recovery time from failure
(time taken to recover the service after a failure).
The aim is to combine our continuous delivery and operability metrics together in one place. The future will then be tying this data together with business data to truly show how deployment frequency relates to value. The platform and being able to evolve it as a product will continue based on our ability to evidence and communicate the value it can add.
Rob Hornby is a Product Engineer working for John Lewis based in London. He has undertaken a number of roles, over the last 20 years, within Testing, Release, Platform and Environments.
Rob is a keen believer in being able to treat all things as Products and be able to evidence the value generated by that team. Ideally everything would be delivered by small teams, delivering continuously and iterating on value. However not all teams start at this point, not all teams are the same or born equal. This is where the challenge and enjoyment comes from.
Outside of work, Rob is a keen runner, father of an amazing young girl, Sofia and works on a number of local community events.
Even when I worked on waterfall teams, we tested early and often. We got ourselves invited to analysis and requirements meetings. We tested requirements docs. We asked questions. We tested as the developers delivered code, even before “code freeze”. We also worked closely with customer support to learn about how customers used the features after they were delivered. (I realize not all teams using a phased-and-gated approach do all that, but that approach should not stop teams from using good practices!)
Extreme Programming (XP) made so much sense to me because it embraced testing and quality as the responsibility of the entire delivery team. In agile development, we focus on building quality in, we test ideas, we automate regression tests, we explore delivered code, we test in production. These same practices apply to teams who use the “DevOps” label as well.
That’s why Dan Ashby’s
post in 2019 on “continuous testing”
resonated so much with me. His visual model captures what is in my brain when I see the term “continuous testing”. With his permission, I often use this model to help others understand the concept:
Dan Ashby’s Continuous Testing Model
But there are different definitions!
WAT!?
Recently, someone posted a link to a short Twitter thread from earlier this year where continuous testing was defined quite differently. Basically, this alternative definition is only about running automated tests in the continuous integration, delivery, deployment pipelines. I started asking around to see how other people define “continuous testing”, and some people shared that definition –
only the automated suites in CI/CD.
A book on “continuous testing” which I had not gotten around to reading also has this definition, and it references the Wikipedia page which says the same thing.
Automated tests in CI are not new!
Continuous integration has been around for decades. My waterfall team back in the early 90s did CI, complete with automated regression tests and automated deployments (to 20+ Unix environments!) We didn’t call the automated regression tests “continuous testing”. We called them automated regression tests. It puzzles me that people would apply the term “continuous testing” to these automated test suites, which teams have been using since long before the term “continuous delivery” appeared.
Going to the source
I learned about continuous delivery by reading the terrific
book
of the same name by Jez Humble and David Farley. If you read it, you will find it is a book about testing. It goes into much detail about many different kinds of testing activities – not only automated regression tests!
So I went to Jez’s website to see how he
defines “continuous testing”
. Please click that link and read it for yourself. To quote Jez,
Our goal is to run many different types of tests—both manual and automated—continually throughout the delivery process.
That is followed by a picture of Brian Marick’s agile testing quadrants, illustrating a range of tests that are business-facing, technology-facing, that guide development and that critique the product. In Jez’s quadrants model, the tests that critique the product include manual tests.
Jez goes on to explain the concept of the deployment pipeline and the importance of getting quick feedback from automated acceptance tests that are in the pipeline. But he does not limit “continuous testing” to only those tests.
Here’s the latest version of the agile testing quadrants model that
Janet Gregory
and I use. We’ve added examples of testing activities we can do today thanks to newer technology and tools, such as monitoring and observability. Those are also part of continuous testing.
Agile Testing Quadrants from
Agile Testing Condensed: A Brief Introduction
by Janet Gregory and Lisa Crispin
Does the terminology matter?
I don’t like to be too pedantic about terms, but we need to be able to communicate with each other. If my idea of continuous delivery was limited to only the pipeline and did not include the concept of breaking features into small slices and deploying small changes frequently, that would not match what most practitioners I know consider to be “continuous delivery”. It would be hard to have a conversation about it with two very different definitions.
Many people use the term “automated regression checks” rather than “automation regression tests” because these tests are checking that requirements are met and that established behavior continues to work as expected. They reserve the term “testing” for activities that are done by humans. Janet suggested that maybe we can refer to the automated regression test suites in CI / CD pipelines as “continuous checking”, and reserve the term “continuous testing” to include those checks PLUS all the testing activities that happen around Dan’s infinite testing loop.
How can we resolve this terminology dilemma? Feel free to comment here. There’s also a discussion topic for this on the
Ministry of Testing Club
.
Meanwhile, I shall see if there are even more definitions of continuous testing I hadn’t heard yet!
