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

Every organization goes through times when the internal, or home team, cannot execute the testing project easily or quickly enough. The reasons are many, from the lack of an effective test strategy to low automation engineering skill, to staff positions going unfilled due to a great job market. With everyone working and very few people ...
Everything is mobile. What else can we say? Everything. If your product or service is currently not, it will be very soon. As Apple says: “There’s an app for that.” There is an app for everything. The race for mobile apps has consumed the software development world. I did a few projects at Palm Computing in the ...
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 ...
Happy New Year from LogiGear to those of us who celebrated New Years on January 1! And for our lunar calendar followers, an almost Happy New Year come February 3rd. We look forward to an exciting and full 2011 as its predecessor was a tough year for many in the software business. At LogiGear Magazine, ...
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 ...
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 ...
I was just recently at a company that had a beautiful test architecture, framework, and Cucumber with tons of well-automated tests. But there was no good test management on top of the Cucumber tests, and they did not do a good job tagging the tests. Although almost everybody on the team could write and maintain ...
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 ...
Testing tools – very important, very often overlooked, and very often where mistakes are made. First, the most common mistake people make about tools is thinking tools are only about test automation! False. Automation tools are merely one type testing tool. We will try to balance this issue between test automation tools and other test ...
Every year, LogiGear Magazine devotes one full issue to Test Automation. We could do more than one, and perhaps even that would not be enough. The problems around automation have become increasingly complex. And now, automation is much more integrated into the software development process. For over a decade teams have been faced with “do ...
As we settle into autumn, we’re taking the time to start some new traditions. This is LogiGear magazine’s first issue on SMAC. SMAC—social, mobile, analytics and cloud. We will be doing more issues in the next few years on these topics since so much of the product world is moving to this development stack.
I remember the times when test teams sat in their own area and we were not allowed to “bother” developers.

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe