Letter from the Editor

DevOps can be a big scary thing. Culture change, constant collaboration— whatever that means— a big new set of tools… it’s a lot. What most teams want is to have a smooth running software development pipeline. I have stopped using the phrase “DevOps,” and now I say “Continuous Delivery.” There are many reasons for this.

First, Continuous Delivery seems not as scary as all the big issues that surround DevOps. Second, it seems Continuous Delivery is what teams are really looking for. Third, my work mainly deals with developers and testers rather than IT, Release Engineers, configuration management, or Ops—that side of the DevOps triad is not my focus, nor the people I focus on.

There are a few forces happening at the same time pushing us in this direction.

The first one is the huge influx of tools that are making environment problems go away. Whether you are using containers, virtualization, cloud, on-premises cloud, or EaaS—there is a flood of tools automating IT tasks or moving to the cloud where many of those issues change or go away. The infrastructure-as-code movement and the tools to make it happen are only going to grow in use and ease.

Infrastructure-as-code also puts access and more control over environments and data in the hands of developers than they have had in the past. Programmers can control when code is promoted to the next environment, and the business can more easily control when code gets to customers. This is a big benefit of the new flood of tools and services. They are key to Continuous Delivery and, if the business chooses, Continuous Deployment.

There are many cultural and political changes that go along with DevOps. Just as with Agile implementation, I see many companies sidestepping or ignoring these cultural changes. All of these are topics for articles by themselves.

What I want to focus on here is testing in Continuous Delivery. Focusing on this phrase sidesteps so many of the difficult, or political issues associated with DevOps, and instead allows teams to focus on getting the product ready.

Using Continuous Delivery as a manufacturing production line with modern practices, such as Lean Software Development from Lean Manufacturing, gives us easy-to-understand ideals and practices to improve our efficiency. This is regardless of a toolset, or where we are in Development integration with Ops.

I often describe Continuous Delivery as the Lean practice of “quality at every step.”

Irrespective of whatever the organization is doing with tools, environments, task automation for environments or cloud, every Continuous Delivery pipeline needs quality at every step. Add some new code—unit test it. Make a new build—test it. Move to a new environment—test it. Integrate any service—test it. Add a new service with new data on a new environment—test it a lot.

On top of all of this, testing needs to be automated. So, the most important way to look at the impact of Continuous Delivery on test teams is that you better have all your tests automated—and automated smartly—because every time there is a change somewhere, some subset of automated tests needs to run in order to validate consistency.

Make the code change, then run a small set of tests, and do another build. Make a bigger change, or move to a new environment—then run a bigger set of tests.

Regardless of what you call your practices, your tests need to be automated so that anyone on the team can rewrite them if necessary, including any tool the team chooses to move the product to the next step in the development pipeline.

We will be kick-starting this issue on “Mega Trends in Testing: Continuous Delivery, Production Line, and the Deployment Pipeline.” We have some excellent contributors this month from the CD field. Eric Minick from IBM gives us an interesting take on CD, and Alex Martins from CA Technologies advises us on the best way to get your team ready. In order to help really grow your CD skills, we have chosen the best book for our practice, with a special guest Bas Vodde from Odd-e, here to tell you all the things you need to know before you delve in.

Don’t forget to check out our hit video series on all things DevOps and as always, we have a trending issue to discuss in TA Corner about how “Dockerizing” in TestArchitect makes for a winning combination.

What’s more, we have the results of our Testing in Continuous Delivery survey. Remember, we’ll be launching our third survey in our State of Software Testing Survey series, and this one is entirely on automation. Please take it, and share it with your networks, or other team members, the more answers we get, the more accurate of a picture of our industry we get. Our next issue will also be on Test Automation.

Michael Hackett
Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), and Global Software Test Automation (Happy About Publishing, 2006). He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries. Michael holds a Bachelor of Science in Engineering from Carnegie Mellon University.

The Related Post

In the November 2011 issue: Mobile Application Testing, I began my column with the statement, “Everything is mobile.” One year later the statement is even more true. More devices, more platforms, more diversity, more apps. It boggles the mind how fast the landscape changes. Blackberry has been kicked to the curb by cooler and slicker ...
As fast as Mobile is growing, the platform is still immature and is evolving at a very rapid pace. While there are whole countries that have migrated large government services to mobile, countries ranging from Estonia to Turkey to Kenya have many longtime mobile users have yet to use mPay or other mobile payment systems. ...
Digital Transformation and IT Modernization projects have shifted into high gear during the COVID-19 pandemic. Tough on some teams is having to do more with less and speed up projects on reduced budgets due to the resulting COVID-19 business climate. On the other hand, other companies are adding funding and pressing the schedule under the ...
Big and complex testing. What do these terms conjure up in your mind? When we added this topic to the editorial calendar, I had the notion that we might illustrate some large or complex systems and explore some of the test and quality challenges they present. We might have an article on: building and testing ...
Test automation is a big topic. There are so many different areas to talk about: tool choice, jumpstart, cross platform, services, cloud… Each of these areas have changed so much in the recent past that they could each be worth their own magazine issue.
How do you test software? How do you validate it? How do you find bugs? These are all good questions anyone on your project team or anyone responsible for customers may ask you. Can you articulate your test strategy─not your test process, but explain your approach to testing? I find that this can be a ...
The Greek philosopher Heraclitus of Ephesus (c. 500 BCE) is credited with saying, “The only constant is change.”   This is a statement that, more than 2,000 years later, still holds true. Today, we are in a time of great change. Everything is in flux. The fact is, we are always in a state of change even if ...
API testing– an old school technology gets way cool again. APIs and testing them is nothing new; the technology has been around for decades. The most basic definition of an API is an exposed function— a producer (person or company) writes a function and exposes it so that others, consumers, can use it. We copy ...
There has been a tectonic shift in software development tools in just the past few years. Agile practices and increasingly distributed teams have been significant factors but, in my opinion, the main reason is a new and more intense focus on tools for testing driven by more complex software and shorter development cycles. There have ...
I spend about half my work time in the role of a consultant assessing, auditing and examining software development team practices and processes for the purpose of process improvement. I am regularly surprised to find teams that lack basic skills, management support, tools, information, access to users, Product Owners and to developers. And yet they’re ...
We launched the first ever software testing conference in Vietnam, VISTACON. It was a resounding success, with well over 200 participants and 20+ speakers from around the globe; each speaking on a wide range of cutting-edge testing topics. In this month’s magazine, we have uploaded several video recordings of event presentations – giving our readers ...
A while ago, I helped start a Software Quality Certificate Program as a part of the Software Engineering Program at the University of California, Santa Cruz Extension in Silicon Valley. I was on the Board of Advisors. While putting the curriculum together, a few people suggested a Measurement and Metrics course. Since I was teaching ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news

Subscribe