Bring all the stakeholders together

Mandi Walls, Technical Practice Manager, Chef, discusses how software is being adopted across the board and how testers can benefit from the DevOps culture.

Chef’s participation in the London DevOps Focus Group event provided a valuable opportunity to speak with peers that we don’t always get the chance to meet as often as we’d like. Our products – focused as they are, on infrastructure automation and compliance as well as application delivery – are usually adopted by operations or system engineering teams more than testing teams.

Testers need support too

My view, however – which has only been reinforced by our work and client experience – is that testers need the same support and predictability in their platforms that developers and operations teams do. And this experience has been drawn from Chef’s role as an active and influential member of the DevOps movement since its inception.

We’ve helped numerous customers and community users through their transformation, from organisations that see IT and technology as a cost centre, to organisations that use technology as an accelerator for the core businesses. This is why I’m confident the need to properly support testing teams is not going away any time soon.

In fact, more and more industries are becoming reliant on software to better serve their customers, respond quicker to market feedback, and drive efficiency in their workflows.

Being successfully software and technology-driven

Indeed, a leading indicator for how successful a transformation programme will be is the extent to which an organisation’s leaders recognise technology as having a valuable role to play, as opposed to treating technology as a cost centre to be managed, contained, and minimised. This also means recognising the importance of developing, testing, and, finally, running applications.

One of the highlights of ChefConf 2016, held in July in Austin, Texas, was a keynote presentation by Veresh Sita of Alaska Airlines. The airline industry is one of many where the primary business is being improved through the application of technology to many different areas of the company. Sita’s message detailed how Alaska Airlines is applying technology to enhance the passenger experience, thus giving the company an edge in an extremely competitive market.

Today, many industries that aren’t the first one might associate with being software and technology driven, such as banking, real estate, and entertainment, are embracing new practices to enhance their non-technical offerings and improve customer experiences. This places increased strain on their own technology departments and partners, which have to keep up with growing workloads, while still guaranteeing quality within a shorter timeframe.

DevOps itself can be understood as a direct response to these market forces and pressures. While DevOps is a portmanteau of development and operations, it recognises there are multiple stakeholders in the success of any technology team, including the test and QA staff in an organisation. As such, the keys to success in modern IT include tools and practices that benefit the teams working in test practices, as well as those in software development and operations.

By combining the people, culture, and technology of an organisation into a winning formula, DevOps includes all the people involved in the production and release of technology and software products, not just the development and operations staff. A successful DevOps transformation project must include everyone needed to deliver the project to completion.

One of the topics discussed at the DevOps Focus Groups roundtable was the continuing challenge for testing teams of ensuring the correct environments for testing applications appropriately. Fully automating the provisioning, updating, and ongoing maintenance of testing environments with a configuration management tool, such as Chef, is an important first step to increasing the velocity of software creation and delivery. This velocity also has a great many other positive effects on the business, because of the value testing teams deliver by ensuring the quality of the products and software being released.

The realities of the production environment

In spite of this, the cost of building and maintaining environments to ensure that testing is carried out against systems that reflect the realities of the production environment is a point of contention in many organisations. In traditional, non-automated „
enterprises, the additional overhead of manually building and maintaining correct test environments is seen as adding costs and resources to projects that are difficult to justify.

Automation, and the sharing of environment definitions between production and non-production environments, as provided by a tool like Chef, alleviates a substantial amount of this overhead. We accomplish this through the employment of a mechanism we have termed ‘infrastructure as code’.

Creating and maintaining non-production environments with the same code used for production environments allows for better sharing of the definitions of the infrastructure via Chef’s recipes and cookbooks. This further provides mechanisms for testing the infrastructure definitions themselves, via tools in the Chef ecosystem like Test Kitchen and InSpec.

These tools provide plugins and interfaces to various providers and other tooling so teams can build sophisticated workflows, by linking common components together via their command lines. InSpec serves as an integration testing tool for infrastructure, as well as providing resources for checking and reporting on the security settings on systems. Chef’s testing workflow allows teams to regression test common infrastructure tasks, from upgrading individual pieces of required software to upgrading entire operating systems, while also maintaining the quality of all environments.

Overall, automation of tasks and processes alleviates risk while boosting efficiency and reliability. When processes are encoded in an automation tool like Chef, they can be examined, audited, shared, versioned, and updated by stakeholders as needed. Storing this information as a text-based file also reduces the risk introduced by the use of non-repeatable GUI-based tooling.

This means no more wiki pages of screenshots describing how to configure software correctly for the project. Instead, the configuration is documented in the code used to create the environment. It can then be deployed repeatedly without suffering from missed steps or forgotten procedures.

Capital One presented a talk about the importance of automating test procedures at O’Reilly’s Velocity Conference in Santa Clara in October. They quote their Founder and CEO, Rich Fairbank, who said, “… the winners in banking will have the capabilities of a world-class software company.” From experience, we know this holds true for many industries.


For most traditional tech teams, this journey is long and challenging, but the rewards are great, and ultimately strengthen the organisation’s market position. Chef’s products have played a key part in many of these journeys already, and we look forward to helping more companies achieve greater efficiency, faster feature production, and more reliable delivery of software.


This article originally appeared in the DevOps Focus Groups Supplement as part of the January 2017 issue of TEST Magazine. Edited for web by Jordan Platt.