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

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 ...
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 ...
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 ...
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.
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 ...
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.
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 ...
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?
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.
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.
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 ...
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