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

I have been excited about this issue since I included it in the 2011 editorial calendar. This issue of LogiGear Magazine dives into an exploration of agile automation—from the most efficient methods for test automation, to skill sets and better preparation for test teams, and even to understanding the variety of tools in question. We ...
This is a very special issue of LogiGear Magazine. When we were putting together the Editorial Calendar for this year, we decided that instead of a technology issue, we would focus on the human side of quality and test engineering. We want to focus on individual Test Engineers and their jobs. We talked to a ...
“Why do we need to understand a bunch of test methods? I write test cases from user stories or requirements, automate what I can and execute the rest manually, and its fine.” If this is your situation: good for you. If you are time crunched, if your automated tests have lost relevance, are hard to ...
If you are reading this issue, you are probably aware of the impact on the business world of cloud computing. Most people do not have a good grasp on what the cloud is or how people and products can use it. BTW, you are already a cloud user. If your email is stored somewhere “on ...
Testing Embedded systems and testing the Internet of Things could each have their own issue of LogiGear magazine. But these days they are referred to presupposing knowledge of the other, so we thought it would be a good idea to tackle the two together in this issue to give a broad understanding of the landscape ...
For everyone still celebrating holidays: Happy Lunar New Year! At this time of the year many teams and companies are starting new projects, new initiatives, and hiring new staff. LogiGear Magazine will continue to be the resource for you for better testing with much less stress! We are excited about the focus of this month’s ...
Because of the type of work I do (consulting projects at different companies), I’ve been lucky in my Software Development career to have worked on a bunch of software projects specific to hardware devices or integrating new hardware into software systems. Starting with the Palm Pilot, I worked on some operating systems (OS) projects, firmware, ...
As part of my work, I spend a lot of time at client’s sites and talk to various software development organizations. I am beginning to see a problem arise regarding Test Automation. There is too much automation! Surprised? While there are still many teams struggling to make progress with Test Automation, many teams have been doing ...
Continuous Testing… what is it? When we first decided to do a magazine issue dedicated to the DevOps practice of Continuous Testing, I joked with someone: “It’s about testing continuously.” And their reply was: “Yeah. What else would it be?” I was joking, but clearly the joke didn’t land. Continuous Testing is about testing continuously, ...
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 ...
Testers need to learn their craft and hone in on their skill set. That means building skills, sharpening their tools, and becoming creative detectives. There is no cookie-cutter tester and no best practice. The best circumstance is a fully-skilled, aggressive tester mixed with curiosity, nimbleness, and agility.
Testing the Software Car. As usual with the LogiGear Magazine, we are tackling a big subject. With our goal of having single-topic issues, we have the ability to grab and disseminate as much information as we can related to a current topic that is interesting and also on the frontier of Software Testing.   Some ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe