DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • DevOps Chats
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Communities
    • AWS Community Hub
    • CloudBees
    • IT as Code
    • Rocket on DevOps.com
    • Traceable on DevOps.com
    • Quali on DevOps.com
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Digital Anarchist
  • Media Kit
  • About
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DevSecOps
  • Leadership Suite
  • Practices
  • ROELBOB
  • Low-Code/No-Code
  • IT as Code
  • More
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps

Home » Blogs » Continuous Testing » Agile and DevOps Success Needs Continuous Testing

Agile and DevOps Success Needs Continuous Testing

Agile and DevOps Success Needs Continuous Testing

By: David Eastman on September 5, 2019 4 Comments

One of the central ways to progress an agile transformation is to introduce continuous testing. With all such changes, it is cultural as much as technical. The expected outcomes are less broken builds and reduced time from break to fix, as well as a yardstick for measuring the team’s ambition for improvement.

Recent Posts By David Eastman
  • From Automated Cloud Deployment to Progressive Delivery
More from David Eastman
Related Posts
  • Agile and DevOps Success Needs Continuous Testing
  • DevOps: Shift Left to Reduce Failure
  • Does Agile need continuous integration?
    Related Categories
  • Blogs
  • Continuous Testing
  • DevOps Practice
  • Enterprise DevOps
    Related Topics
  • agile transformation
  • continuous testing
  • DevOps Success
  • integration testing
  • Mock Service
Show more
Show less

The Testing Bit and the Continuous Bit: Testing should be part of any agile developer’s skillset; the shift is to apply it to the whole build pipeline. Continuous implies automation, with the build featuring as a living thing whose state is always changing. The infrastructure options have expanded with the advent of cloud computing and virtual containers.

DevOps Connect:DevSecOps @ RSAC 2022

Let’s say your teams’ developers work on components, independently buildable and testable chunks of the whole app or service. They receive stories and tasks to improve a customer journey and then add functionality to implement these. And when done, they check their work into your team’s code repository.

Starting with One Developer, One Laptop and One Test

The initial testing focus for a single developer (or pair) working on code will be the unit test and the coverage test. Whether writing the test first or code first, the unit test pokes the bounds of the new code and the coverage test checks that all code paths are exercised.

As an example, maybe the developer has implemented the “customer wants to deposit money” story on an accounts component of a banking system. The tests should check what happens if a user deposits zero, negative or fractional money and the coverage confirms the tests have wandered down all possible the code paths of the new feature. In this way, coverage tests also prevent a developer from adding code without introducing the corresponding tests.

At this point, it is worthwhile making sure tests are run as part of the build so every time the developer builds the code all the unit tests are run. This is a fairly standard thing for most build systems to do. The bottom line is the chance of checking-in breaking code is greatly reduced.

Now the Bigger Picture

The new code worked on your developer’s laptop, the tests passed and they checked-in the code. But in a busy enterprise team, other developers are also working on the same component, maybe even on the same file. This is no different from working on a book chapter with several authors. Your developer worked with a stable snapshot of the code. It is quite possible changes were made by others that conflict with the changes your developer just made. So how do we proceed?

This is the purpose of the central build. The job of the central build is to check out all code for that component, build it and run all associated tests whenever new code is checked in. In today’s world, the likely path would be to create a container on a cloud server, where the component can be built from scratch, and then all the tests run against it. Traditionally, a tool such as Jenkins would watch for git check-ins and kick off a build. The result is the team always knows if the overall build is green (working) or red (broken). A developer must understand the central build is the true source of truth, not what is happening on their laptop. So, the latest check-in leads to a correctly built component. What next?

There are three general types of testing needed to develop a software system. Tests that make sure new features work correctly and don’t break the component, tests that make sure the components still work with each other and those confirming the customer journeys your component participates in all work as expected. There would be no point in making a deposit function without a customer journey test that proves a customer can deposit cash with the system.

The second type of testing, usually referred to as integration testing, needs an environment where all current successfully built components can communicate with each other. Today, that may mean some form of container orchestration with the system’s components placed and managed in their containers. Tests of a customer journey may involve emulating the customer’s manipulation of a website or mobile app, depending on how the application or service is accessed. These are the tests stakeholders are most interested in as they confirm what has been requested in the stories actually work. As with integration testing, these tests may be run less often.

I Mock Thee

Mock (or fake) services and data are a necessary part of the testing process, and usually, must be maintained and extended as part of the testing. A feature story may require a developer to spend more time developing or extending a mock service than writing the code it helps test. For example, a mock account with some transaction history is needed to test a new deposit function.

Live environments can never be entirely simulated in test environments. Sometimes a live service uses a paid for third-party service, and it would be too expensive to use in testing. It is usually the case that the development staff are not permitted to work with live customer data.

The Build Is Alive

All the structures mentioned are just products of one simple attitude: “How do I know if this works?” For continuous testing to thrive, engineers should always question whether every part of the system is being tested and whether the tests are being evolved at the same pace as feature development. When tests or mocks are missing, an agile team refers to technical debt. This is as it implies, something that must be paid for later.

When team members realize they cannot just check-in code and go to lunch without checking the central build, that is a good sign. Information radiators such as large screen displays of the build state should be used to get the extended team to understand the state of the build is everyone’s concern, throughout the lifecycle.

— David Eastman

Filed Under: Blogs, Continuous Testing, DevOps Practice, Enterprise DevOps Tagged With: agile transformation, continuous testing, DevOps Success, integration testing, Mock Service

Sponsored Content
Featured eBook
The Automated Enterprise

The Automated Enterprise

“The Automated Enterprise” e-book shows the important role IT automation plays in business today. Optimize resources and speed development with Red Hat® management solutions, powered by Red Hat Ansible® Automation. IT automation helps your business better serve your customers, so you can be successful as you: Optimize resources by automating ... Read More
« Why and How to Collect KPIs for Z DevOps
Instana Adds APM and Microservices Industry Veteran As Chief Marketing Officer »

TechStrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

Continuous Deployment
Monday, July 11, 2022 - 1:00 pm EDT
Using External Tables to Store and Query Data on MinIO With SQL Server 2022
Tuesday, July 12, 2022 - 11:00 am EDT
Goldilocks and the 3 Levels of Cardinality: Getting it Just Right
Tuesday, July 12, 2022 - 1:00 pm EDT

Latest from DevOps.com

Rust in Linux 5.20 | Deepfake Hiring Fraud | IBM WFH ‘New Normal’
June 30, 2022 | Richi Jennings
Moving From Lift-and-Shift to Cloud-Native
June 30, 2022 | Alexander Gallagher
The Two Types of Code Vulnerabilities
June 30, 2022 | Casey Bisson
Common RDS Misconfigurations DevSecOps Teams Should Know
June 29, 2022 | Gad Rosenthal
Quick! Define DevSecOps: Let’s Call it Development Security
June 29, 2022 | Don Macvittie

Get The Top Stories of the Week

  • View DevOps.com Privacy Policy
  • This field is for validation purposes and should be left unchanged.

Download Free eBook

The 101 of Continuous Software Delivery
New call-to-action

Most Read on DevOps.com

Rust in Linux 5.20 | Deepfake Hiring Fraud | IBM WFH ‘New No...
June 30, 2022 | Richi Jennings
Chip-to-Cloud IoT: A Step Toward Web3
June 28, 2022 | Nahla Davies
The Two Types of Code Vulnerabilities
June 30, 2022 | Casey Bisson
Quick! Define DevSecOps: Let’s Call it Development Security
June 29, 2022 | Don Macvittie
Common RDS Misconfigurations DevSecOps Teams Should Know
June 29, 2022 | Gad Rosenthal

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2022 ·Techstrong Group, Inc.All rights reserved.