Shifting towards Omni Testing – Part 2

By Sérgio Freire

In Part 1 of this series, Sérgio introduced his idea of “Omni Testing” as a term that better expresses the concept of continually testing throughout the DevOps infinite loop of discovery and delivery. In this second and final part, he explains why he likes to use this term to describe the multitude of testing activities teams do to succeed with continuous delivery and deployment.

We all heard about Shift-Left Testing and Shift-Right Testing in recent years. Probably you may have got the idea that it was the thing, that single idea that was going to massively improve your testing. Due to this misconception, for example, Janet Gregory prefers to think about testing as something always happening and holistic (i.e. considering all parts of the whole and their interconnection).

Let’s be clear: you cannot shift something that is always there and happens all the time; however, what you’re focused on at a given moment in time can, and probably should, change. Within a team, testing happens continuously and in parallel, so different people may be performing quite different testing activities and from different angles.

If we have pure waterfall development in mind, testing happens as a phase after implementation. However, in real-life, testing is not constrained anymore. Of course, some teams perform more intensive testing before releasing; in that sense, people may refer to shift-left testing efforts as a way to clarify requirements altogether from the start and introduce more unit kind of tests. Similarly, with DevOps, you may “shift-right” testing efforts to production and use as a feedback loop to product development.

However, testing itself is not shifted-left nor right; testing efforts can shift though. Having “ Agile Testing Quadrants ” (by & ) and previous work from (i.e. testing matrix ), we can see that there are different types of tests, with different goals. As Lisa and Janet point in their book “ Agile Testing – A Practical Guide for Testers and Agile Teams “, risks are an inherent and important part of projects where testing is used as a mitigation strategy.

As you plan each epic, release, or iteration, work with your customer team to understand the business priorities and analyze risks. Use the quadrants to help identify all of the different types of testing that will be needed and when they should be performed.

Thus, the type and level of testing performed, where and how it is performed, are dynamic.

Testing is not a specific task assignable to one person and delimited in time; everyone is involved in testing, it happens in different ways, at the same time and continuously; and this leads us to Continuous Testing.

From Continuous Testing to Omni Testing

Continuous Testing has been around for some time; the “Continuous” wording is not new. Unfortunately, it is being pushed by some tool vendors and some people to sell it as a way to continuously run “automated tests”.

Well, first there aren’t automated tests in a strict sense; you have automated checks but testing frameworks having been calling them as such from the start. Second, “continuous” in testing is not related to automated scripts/checks being continuously run or not. Even if it was, it wouldn’t make sense, as in CI “automated tests” are triggered on code commits, pull-requests, merges or due to some predefined schedule.

So what does Continuous Testing mean? I advise you to start by this post from Lisa Crispin and complement it with this course from .

We know that automation plays a key role in DevOps and also, though to a minor scale, on Continuous Integration (CI) practices which are closely related to Continuous Testing.

The CI concept was depicted by and largely widespread with Extreme Programming as one of the 12 core XP practices (, , , et al).

During Continuous Integration, “automated tests” (i.e. automated checks to be more precise: code that runs and performs checks to validate expected behavior) are run. These will help assure, to a point, that code that has been integrated isn’t breaking anything and previous expectations are still met.

As teams grow and code is committed more often, CI provides the means for immediate feedback so the team knows right away when a possible “bug has been added”. It can quickly be fixed before anyone builds on top of it. These automated scripts perform unit and integration tests but can also cover other types of tests such as security tests and more.

As builds are continuously being started by the CI process, these kinds of tests are also constantly being run.

However, “Continuous Testing” is not limited to these “tests”. Lisa Crispin and Janet Gregory put it like this instead:

Collaborative testing practices that occur continuously, from inception to delivery and beyond, supporting frequent delivery of value for our customers. Testing activities focus on building quality into the product, using fast feedback loops to validate our understanding. The practices strengthen and support the idea of whole team responsibility for quality.

In my opinion, this is the real reason behind the “Continuous” wording before “Testing”.

Atom Symbol representing Omni Testing with a brain icon, bug icon, other testing tools

Well, at first sight, “Continuous ” makes sense whenever everything else is using the “Continuous” prefix. But you don’t hear about “Continuous Coding”, do you?

Thus, a better adjective should be used instead: I think Omni (Testing) may describe Testing in a more complete way. Do you agree?

Continuously evolve our way of understanding the world around us

We moved from testing in waterfall, to testing in Agile , to testing in a DevOps context. Testing, similarly to other processes, evolved along the way; its essence hasn’t.

We still use testing for the same reasons, because we aim to understand what we test and use that information to make decisions.

Whenever we go to a shop and buy something, whenever we download an app and try it out, whenever we meet or go out with someone: we’re trying to somehow understand what’s in front of us. We’re information seekers because ultimately we want to take actions leveraged on data, i.e. informed decisions.

In software development, which may also include hardware development, by the way, testing is done as a means to ensure that the deliverables produced on our products/solutions iterations have a certain level of quality. And this includes evaluating not only expected behavior but also that “customer” needs are covered in the best way, thus we look at certain quality attributes.

Testing is centered around humans and it requires them. However, machines, tools, algorithms, and AI can leverage the unique power we have within us to provide better testing. That’s around 3.5 billion years of continuous evolution and accumulated learning about life on Earth.

I know what you may be thinking: maybe there is no Agile Life, no Continuous Life, and we also don’t call it Omni Life right? Well, true; similarly to what happened with life, testing evolved, it’s widespread, it lives from the outskirts of software development. But, life is restricted in many ways: to certain conditions, to our planet (as far as we know).

Testing, on the other hand, is a broader concept; no limits attached… and being Omni is part of its real essence.

Sérgio Freire’s background is in electronics and Telecommunications. Throughout the years, he has worked with teams in developing real-time software, web and mobile applications and complex hardware systems. He has worked and interacted with teams in waterfall and Agile contexts. As Head of Solution Architecture for Xray, he works closely with many different teams worldwide to help them achieve high-quality, testable products. Follow Sérgio on and .

Shifting Towards Omni Testing – Part 1

By Sérgio Freire

Testing, as we foreseek, is something not limited to time, not limited to space, not limited to a specific team member, not limited to a given type, technique or approach; it is a process we use to understand something, to obtain more information about it so that we can take actions on it.

Testing is not just about continuously “running” (checks); testing is always there, it is part of the whole (e.g. product development), it encompasses different kinds of activities and involves everyone.

That’s why Omni Testing can, perhaps, be a better way of describing Testing as we aim it to be.

Testing is universal. It’s one thing every single human has performed in their life.

For many of us working in software or hardware product development, testing is even more “natural.” However, we sometimes misinterpret it or see it just from a narrow perspective.

Lately, we have been hearing about Continuous Testing, Agile Testing, and DevTestOps/DevTestSecOps. Before that, Shift-Left and Shift-Right Testing and “Test Automation” were also around.

This tells us that Testing is:

broad
important
always present
intermingled with what we do
used interchangeably, in different contexts

Because of all of this, I think that Testing is a process unbound, in time, location, people and context; yet, it always has a purpose – actionable information. No matter if you’re using it to verify if you retained knowledge after attending a course, to evaluate if you like some food or a perfume, or to understand how a product works and if it meets some customer needs. Even before “software was invented, testing was already part of our lives and helping us shape our decisions.

Omni Testing

Why Omni? Is it a “new thing” or a “new kind” of testing?

What types of tests and approaches does it embrace? Who is involved in it?

“Omni” comes from the Latin word omnis and means “all,” “the whole of, “all things,” “everything.”

More and more, teams everywhere are aiming to have a holistic approach to testing. We’re aiming to have on-going conversations, on-going experiments and investigations, on-going checks, on-going information, and on-going feedback. The whole team is involved in testing and has quality in mind, from the start. For that, the team starts by assessing all risks, performs all sorts of tests, using all sorts of techniques and approaches.

Mind map of omni testing showing people, machines, multifaceted, active, embracing modern approaches — Omni Testing mind map

(Software) Testing is multi-faceted; it can be used in so many different ways, although in Omni Testing we try to perform it in a way where:

it produces relevant information ASAP (i.e. accordingly with the agreed test strategy and the overall agreed meaning of quality)
it focuses on what matters first
it is efficient and quickly adapts

Thus, it is not dependent/limited to:

specific roles
specific assets
specific test levels, types, techniques and approaches
specific methodologies
specific phases
specific tools

Defining Testing, again

Defining “testing” although may seem simple at first sight, it isn’t. Why? Because it is a broad concept and sometimes used incorrectly or in a very restricted sense.

Recently, I had an opportunity of attending a workshop on exploratory testing with at .

To the question “why do we perform testing?” the group came to these results.

Spend time/resourcesUnderstanding the systemUncover gapsProvide valuable info to team membersGive everyone feedbackFinding risksMake the end user happyTranslate information to othersReady to ship?

Probably, others would come to different conclusions. For some, testing is just about checking and “finding bugs.” However, it’s much more than that.

I do agree with that pictures such as the following one won’t help, as they depict “test” as a phase (which besides not being true is also not very agile).

DevOps infinite loop of plan, code, build, test, release, dep;oy, operate, monitor, plan...

There’s an in-depth from , where he goes over the definition from Cem Kaner ( The Ongoing Revolution in Software Testing, 2007 ):

Testing is an empirical, technical investigation conducted to provide quality-related information about a software product to a stakeholder.

In testing, as Alan Richardson correctly points, we build models and we compare them with reality. has a short, yet clear video on which may be useful to you in this context.

When focusing on software testing, you’ll probably find some terms: “Traditional”, Waterfall, Agile, Continuous and Modern Testing (you may want to look at and “ Modern Testing Principles “; there’s a course on MoT).

Let’s look at this from James Bach & Michael Bolton:

“Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes: questioning, study, modeling, observation and inference, output checking, etc.”

I would rephrase this slightly, adding my perspective.

Testing is a targeted process of challenging something (e.g. a product) and our understanding about it , using a set of activities leveraged by specific human skills.

Where,

“targeted process” – a set of activities, having a common goal (i.e. quality attributes in mind), that will produce a result
“challenging” – includes trial/experimentation, checking, …
“activities” – build models, create test ideas, execute actions in the SUT, investigation, ask questions, provide feedback, …
“human skills” – creativity, curiosity, perseverance, analytical thinking, communication, courage, continuous learning mindset, …

Testing is by nature; we try things and test ideas, we explore to seek understanding, to obtain information as states in his adapted model of James Bach’s . We also use other approaches, such as script-based tests (i.e. checks) which sometimes are automated to verify “compliance” with predefined rules. We use all the outputs we collect as data that we process. This data becomes information, which is then used to improve our learning of the system/product and provide feedback to “stakeholders” (e.g. business, product team).

Whenever testing something we have in mind certain quality attributes (e.g. correctness, usability, scalability) – “requirements” we demand or expect from it.

To perform it, we test at different levels and use a bunch of different techniques that help us shape what we call “tests”.

We test everything, software, hardware, specifications, established ideas, documents, and specifications.

Thus, testing is a complete, omni process that uses best-of-breed human skills to answer tailored questions to clarify our understanding about something and that can help shape it before, during and after it is built.

That being said, how does it relate with Shift-Left/Shift-Right and Continuous Testing? We’ll dive further into this topic on the next blog post of this series related to Omni Testing.

Check next week for Part 2 of this series about Omni Testing!

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 .

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.

Anticipating Problems with Infrastructure as Code in DevOps

By Nilanjan Bhattacharya

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.

Notes

Thedescription of the core of DevOps is from Wikipedia: https://en.wikipedia.org/wiki/DevOps
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.

Webinar panel discussion, 11 September, 1:00 PM Eastern

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!

Measuring Our Continuous Delivery Progress

by Rob Hornby

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.

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 Deployments Throughout the Year — Total deployment throughout the year

Continuous Delivery patterns (Lead Time: Blue, Interval Time: Red) - so much to read into these graphs. — Continuous 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.

Reference:

For more information, we recommend reading Measuring Continuous Delivery by Steve Smith ().

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.

What is continuous testing?

By Lisa Crispin

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!

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!

Continuous Testing in DevOps: A gamification approach

By Jorge Luis Castro Toribio

A continual problem that we must deal with when we run automated tests in our DevOps pipeline is maintenance. I could spend hours sharing posts and blogs about this matter, telling stories about how it affected our team’s capacity and time to market, and giving you several examples of what teams have done to sort this problem out. In fact, all the effort that we invest in maintenance is not visible to the business stakeholders’ eyes. Maintenance consumes our team capacity, but it does not add value to our clients directly.

Test automation challenges at scale

In one of my jobs wefaced this problem on a large scale. We had more an average of more than 1000automated tests running at each code check in, plus one big run at midnightthat we called full regression. Our suites where organized in those levels:

L1: Unit testing – Development Stage
L2: Integration Testing – Commit Stage
L3: UI Functional Test MVP Suite – QA Stage
L4: Regression suites – Full package – UAT Stage

Those testing levelswere our creation, but we used the great lessons shared in this book https://www.amazon.com/Practical-Approach-Large-Scale-Agile-Development/dp/0321821726 that I recommend for any team looking to buildtheir testing strategy.

After each run, we noticed that 80% of UI and regression automated tests failed due fake failures. After reading my numbers, you can say if you automated crap, you will get crap results and that is correct — but please remember that we were building our automated test suites, with a continuous testing approach and DevOps mindset and pipelines, so we were trying to fail fast, learn and improve. First, we decided to analyze our test results and data, so we collected all the information that we got from our test runs and analyzed, we discovered that our tests failed because of those main reasons:

Changes inUI components.
Badcoding.
Exceptionsand errors handling
Time outseverywhere
Data

A new experiment

We had to make a decision. We had invested lot of efforts in testing automation, and we were the product team with more automated tests compare to the rest of product teams globally in the company. This brought us attention from lots of managers, who were keeping their eyes on our DevOps and test automation activities. In addition, we were participating in a DevOps competition which involved all the IT teams of the corporation. So, we decided to invest time to get the failed tests in good shape and have them passing in the pipeline. We called this mindset “Keep them green and running”. We communicated this effort to all the product teams. We asked the Product Owners to consider maintenance time as part of their team capacity, include tasks for this purpose, and keep it part of their definitions of “ready” and “done”.

Unfortunately, we did notachieve the goals we had hoped for. We still had the same test results, withmore than 80% of tests failing. In almost every case, they were fake failuresthat meant that the tests were stopped long before their last steps. To sum up,our rest results were not accurate at all and did not bring confidence to ourteams — which is something critical in testing automation.

Thinking outside the box

We needed to try something different. After some discussion, research, investigation and thinking out of the box, we decided to use gamification to keep our tests in a good shape, running and be green. We named the game “Game of Testing” and we established some critical points about it:

Maturitylevels: The gamers can be developers, testers or anybody who owned an automatedtest running in the pipeline, they were maturing in the game, from a beginnerlevel to a master level.
Visibility:We shared the game boards including ranking, test results and so, on using bigmonitors in the office, allowing everyone to be aware of the gamers andresults.
Weight:This is a very complicated and mathematical part, we needed to stablishformulas and weights for a point system for the game, so we could evaluate thetest results, data per gamer and teams, and gave points and make them get newlevels.
Recognition:We tried to recognize all the gamers taking part. For the best gamers, weshared the results with local and global senior managers, so their achievementscould be known and recognized. Thishelped encourage more team members to participate.

The game was quitesimple:

Gamers: All the team members who owned an automated test running in the pipeline.
Point system: A gamer won point s for test running in green and negative points if the test failed for fake results. Later we added negative points of breaking builds.
Rules: You needed to keep all your test and team tests running in the pipeline in a good shape for each run. So, you had to invest efforts on “maintenance” and continuous improvement if you want to rock in the game.

The Game of Testing

This approach helps usa lot to decrease false positive runs and keep the tests up and running in thepipeline. We decreased the number of 80% of failed tests to only 20% inapproximately three months and our numbers have continued decreasing. Furthermore, people had fun while playing thegame and they internalized that quality can be fun and not boring like usualmaintenance was.

While we got several criticisms about our failing tests at the beginning of our efforts to improve them, and people lost trust on our quality assurance process, we didn’t give up trying to fix the problems. In fact, it motivated our team to think out of the box and turn this problem into a useful and fun project. We spent several hours investigating continuous testing, scripting, and related topics. Besides that, we wanted to do something different, something motivates other team members to join.

Gamification can provide that motivation. You may not achieve desired results immediately, but if you prepare your environment and involve everyone in trying potential solutions, the game will give you results for sure. If you address the test issues you can get them pass or fail, but if you involve and motivate people to work on problems together, you always win and have fun. I recommend you try gamification to sort your problems out, you may be surprised at the results!

Jorge Luis Castro Toribio

Jorge is an agilist who feels passion for Testing Automation, Agile, DevOps and business agility. He enjoys research and learning about business agility and working with cutting-edge technologies. He has been learning continuously for more than 12 years and is still learning new ways to foster business agility and team greatness. He has worked in several roles (developer, tester, manager, agile coach) which helps him to see the big picture and operational and team members dynamics happening inside organizations. This experience lets him help teams design, build and implement digital, DevOps and agile transformation strategies. He encourages focus on: People, Productivity, Continuous improvement, Innovation and having fun to enjoy success in our agile journeys.

You can find Jorge on and .