Letter from the Editor – June 2018

This is our third issue concerning topics of Continuous Delivery (CD) and DevOps with the inclusion of Continuous Testing. DevOps has been around for a while and I hope the period of buzz is over and companies moving towards building a development pipeline have begun their process, including changing their test strategies.

Many organizations recognize that they have to hit the brakes and likely do an engineering project to re-architect the system before commencing.

Very different from organizations jumping on the Agile and Scrum bandwagons in name only, DevOps is more about business change, Operations/IT/deployment change, and investing in tools more so than Dev and Testing practice change. Although there is a big impact on the Dev team since many Dev teams take the lead on configuring the new pipeline tools. Dev and Testing got turned on its head with Agile. It’s more commonly the product architecture, tools, and deployment process getting turned upside down now.

Encouraging Operations/IT to get involved early in development, shifting Dev testing tasks left earlier in the cycle, and automating as many Ops tasks as possible are all foundation ideas in DevOps. Commonly talked about tools for this include Puppet, Chef, and Docker.

As much as tool and deployment changes are important, successful teams need DevOps Culture changes such as building trust, building cross-functional knowledge, and cutting out blame. This is a culture where everyone is working towards deployment.

You ask, what part of CD/DevOps do test teams need to focus on? I can say: first, understanding Continuous Testing. The distributed nature of quality ownership in CT includes much more Dev white box testing, specifically unit testing than many organizations are used to.  This is part of the shift-left practice. The theoretical result of this is that more unit testing leads to more robust functionality earlier that includes a different need for higher level testing and Test Automation. You can refer to many published works on the “Test Automation Pyramid,” where more testing is happening at the unit level than at the UI level.

Another profound development change that some organizations have a difficulty grasping—culturally— is the notion of a much smaller release than what we are accustomed to. DevOps is based on much smaller changes streamed into the production pipeline deployed in small increments to lower the risk of traditionally larger releases that most organizations do. This “small change” mindset has profound impacts, such as easy deployment, easy rollbacks when necessary, small focused Dev and Test periods, faster automation, and smaller regression suites with a minuscule focus.  All this for another foundation idea in DevOps: immediate feedback.

The much smaller, and faster regression test suites are a stumbling block for many test teams. I sympathize with this! The demand to continuously automate more persists in software development teams. In many cases, little thought was given to significant tagging, traceability, and most

importantly—retiring tests. This led to bloated and slow regression suites. Continuous Testing demands lean and mean automated suites. This is a shift in mindset that may take some time for test teams to catch up to, as it is a different style of automation. It’s lean.  But still remember to automate, automate and automate, but make it smarter and leaner! Making choices to not run all the automation, at all times is risky and difficult. Be sure to communicate and collaborate. Explain the test coverage for various regression runs.

If you are doing DevOps/Continuous Delivery/Continuous Testing, pay attention to this issue! In this issue, we gear our focus towards Testing in DevOps.  There’s an intriguing interview with Dave Farley, one of the pioneers of Continuous Delivery. Also included is an article from our partner, Sauce Labs that explores the complexity of combining Continuous Testing and DevOps. Whether you are just beginning your Continuous Delivery journey, or have already implemented a pipeline, this issue has you covered!

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

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 ...
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 ...
What is testing in Agile? It’s analogous to three blind men attempting to describe an elephant by the way it feels to them. Agile is difficult to define and everyone has their own perspective of what Agile is. When it comes to testing and Agile the rules are what you make them. Agile is ideas ...
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 ...
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 ...
Automation is a mantra in testing. Anyone associated with software development wants more test automation, but it’s often misunderstood. People who do test automation know how difficult it can be. But some people do not understand that automation is code, and that it needs to have architecture and design just like production code. They do ...
Methods and strategy have been my favorite topics since I started working in testing. It’s essentially engineering problem-solving. It’s both looking for efficiency and attempting to measure effectiveness. So, how do we develop a set of practices to solve our Software Testing engineering problems?
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 ...
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. ...
I once consulted for a company to give a week-long course on testing and QA. It was a survey course covering a wide range of topics. I was setting up and chatting with students in the room. One man came over to me and said: “I have been testing for 6 months and I am completely ...
Change is constant. What’s different today is the rate of change. Moore’s law resulted from the observation that that the rate of change in computing power is exponential. The products, services and software landscape appears just as dynamic. At the same time, we pretty much take for granted the ubiquitous presence of software running our ...
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 ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe