Gartner has estimated that by 2021, demand for application development will grow five times faster than tech teams can deliver, and the digital skills shortage is projected to result in 4 million vacant roles by 2030. With fierce competition for the best talent, it’s crucial for businesses to be able to attract and retain top technical talent to build a happy workforce with low turnover.

Our recent developer survey gave developers a chance to tell us the factors that impact their job satisfaction. Having realistic targets (87% agree) and the right tools (92% agree) came out on top. Contrary to popular belief, to increase their job satisfaction, developers are also eager to introduce automation for the repetitive tasks they don’t enjoy such as unit testing. In fact, 66% of those surveyed believe unit test setup is mundane.

Achievable targets lead to satisfied developers

Survey findings also suggested that manager expectations tend to be slightly higher than developers can deliver. In the companies our respondents work at, for example, the average target for code coverage by unit tests is 63%, but almost half (48%) of surveyed developers reported that they have found it difficult to achieve these coverage targets. 42% of the developers we surveyed agreed that they have skipped writing unit tests in order to speed up new feature development.

As the developers we surveyed agreed that having realistic targets is important to their job satisfaction, ensuring they have the right tools to reach these targets is critical to maintaining their job satisfaction. So if management’s expectations are going to stay high—as they should—what supporting tools do developers need in order to achieve their targets? According to the research, the answer appears to be increased automation, with 86% of respondents agreeing that the availability of automation for repetitive tasks is a factor in their job satisfaction.

 Which tasks should be automated?

Automation is frequently discussed as a key tenet of DevOps, but how and where to effectively introduce automation tools isn’t always clear in practice. Some development tasks are a better fit for automation than others. Does a task follow a set of rules? Does it need to be done often? Is it important to the quality or security of your software product? If the answer to all of these questions is “Yes,” then it’s probably worth automating.

Also important, however, is how teams feel about doing it manually: Do developers dislike this task? Will they do it if they don’t have to? When developers don’t want to find time to work on a task, there is an even greater reason to find out how to take it off their plates. In this way, automation humanises people by removing robotic work.

The stages of the software delivery lifecycle that are well suited for automation include deploying new releases, finding bugs, and testing—both creating tests and running them. Writing unit tests, for example, takes up 20% of a developer’s time, according to our survey. Unit tests are often repetitive and uninteresting to write, but they are an important part of catching unintentional changes in code that can lead to bugs. Still, 39% of developers wish they didn’t have to write unit tests at all. This is one area that can be automated for the benefit of everyone.

Automation benefits for code quality

Not only does introducing automation address a core cause of workplace dissatisfaction, but it also improves the speed of software development and the quality of the final result. 40% of the developers surveyed chose manual processes as a top factor contributing to poor software quality, likely because people are prone to making mistakes on repetitive tasks that they aren’t intrinsically motivated to do.

The organisations that attract and retain top talent by providing the support and tooling their teams require will also be the ones that produce quality software for their customers. Take care of your people and success will follow.

Written by Mathew Lodge, CEO of Diffblue

The post What developers really want from their jobs appeared first on DevOps Online North America.

The new world of modern software delivery, ushered in by the impact of digital disruption, offers tremendous opportunities both to improve solution quality at the desired speed and to develop new capabilities. However, as testers, we need to acknowledge that in order to ensure that software quality remains at the forefront of the mindset of everyone involved throughout the development lifecycle, our role and approach will have to change.

Cultural change is required

There is a general recognition that the cultural changes required for an organisation to successfully move into the world of DevOps/CI/CD can prove a much bigger barrier than the technical challenges.

To survive and thrive in this new world we need to develop a continuous testing culture across our function, complimenting and supporting a wider continuous delivery culture. We must become the champions and advocates for testing and quality activities across the lifecycle. This should bring what we have long sought – involvement right from the outset.

Rather than managing towards ‘hand-offs’ into segregated testing phases, we need to foster the approach of collaborative work and joint problem-solving.

The wider culture, typically adopted in this modern delivery world, of trying new approaches and tools and discarding those things that don’t work/add value, can help us in testing to also be more innovative. We can, and perhaps should, become more comfortable in experimenting with new techniques and ways of working in the quest to improve quality.

New friends and allies

The advent of DevOps also brings the opportunity to work more closely with our colleagues in operations. We share goals of protecting production and the customer from poor quality and resulting outages. Often those areas that the operations team are concerned about and want to see closely monitored are areas that we should be focussing our quality lens on too. On the flip side, the instrumenting and tools we utilise in testing may also deliver benefit to our operations colleagues.

Single view of the risk

In this world of modern software delivery and improved collaboration, we have an opportunity to develop a single, joint view of the level of risk and where this lies across the solution landscape. When we have achieved this single view, there should be much greater buy-in from our technical colleagues and senior stakeholders into our proposed approach to testing, which should be closely aligned to that same view of risk. In turn, this should avoid any suggestion that the scope of testing/QA is inappropriate and might even ‘kill the business case’.

Establishing a ‘ruthless automation’ mindset

The challenge in this new world for all disciplines including testing/QA is to think about how to automate all tasks as far as possible almost as soon as they are identified. This has been referred to by Forrester as ‘ruthless automation’. This approach of maintaining a constant eye on the challenge of frequent perhaps daily or even more frequent releases is an important shift in mindset.

Transformation from testers to quality engineers

It has been suggested that what is required to deliver solutions is actually ‘T-shaped technologists’, individuals with a dual focus. Firstly, they have their specialism, perhaps in development or more likely in our case test automation, exploratory testing or test data management, but then secondly, they must have the overall end-to-end delivery focus required. This means we will have the opportunity to develop new skills, become more technical if we have the aptitude/desire, but certainly move closer to the other functions.

We need to add value by advocating and driving quality across all of the different delivery functions and activities. From the initial story definition, through to the method of deployment, we can champion quality. This must include ensuring that the final delivery we are working towards meets all the necessary quality criteria. We have the opportunity now to re-invent ourselves and become quality engineers rather than merely testers.

Avoiding the perils of burn-out

When we establish what constitutes a sustainable pace of delivery, we need to consider not just technical considerations but our engineers and avoiding them becoming stretched beyond reasonable work commitments.

As managers, we need to ensure our quality engineers have a work/life balance that is appropriate. The benefits of an improved delivery speed could be very short-lived if in the process our talented engineers suffer ‘burn-out’ and consequently become less productive.

Embracing the opportunities

The new era should ultimately (appreciating this won’t happen overnight!) bring with it a clearing of the technical debt that previously meant being stuck with troubleshooting problematic legacy systems. This, in turn, should mean greater opportunity for our teams to work on more exciting new work.

Professional testers and those working in QA share a genuine passion for delivering quality solutions. The new world of modern software development offers us opportunities to develop new skills and have a greater influence, and ultimately play a pivotal role in delivering better quality at the speed demanded by today’s demanding and perhaps more discerning customers.

Rather than seeing the new delivery methods of DevOps/CI/CD as a threat to our existence, we need to evolve our teams and individuals to meet the challenge. Ultimately, we need to transform ourselves to become fully fledged quality engineers and in the process, earn enhanced trust and respect from our colleagues.

Written by Richard Simms, Test Architect, ROQ

The post Embracing the opportunities of DevOps appeared first on DevOps Online North America.

Last week, the American multinational technology company seeded its fifth beta a month after its minor bug fix update, iOS 10.3.2.

With the proper configuration profile installed or through the Apple Developer Center, developers will be able to download the update iOS 10.3.3 beta 6 after installing and registering to the configuration profile.

No notable bug fixes or features were found significantly in the first five iOS 10.3.3 betas, suggesting that its update focuses on small-scale bug fixes and security updates.

MacRumours believe that Apple shifting to iOS 11 has affected iOS 10.3.3, because of it being one of the last updates to the iOS 10 operating system.

Written by Leah Alger

Read more from DevOps Online | Follow us on Twitter

The post Apple’s iOs update for beta testers and developers appeared first on DevOps Online North America.

Even with a helping hand from developers, testers, deploys, monitors, log, configuration management and collaboration platforms, the online gaming company’s road to DevOps wasn’t straightforward. “Our road to DevOps consisted of monthly releases, downtime during release, costly meetings between teams, communication issues and late integration issues,” said Sztupak.

In a bid for Gamesys to change its path another route needed to be found. “We needed to find a way to prevent the following issues: we needed to split up monolith, create a platform that allows people to create microservices easily, deploy those microservices, automate processes and automate what’s on the Dev’ side,” he added.

Before the change, backend and frontend teams were separated, teams were effectively going at different speeds and frontend and backend teams were merged into verticals.

“A platform team needed to be built up from members of different teams. We set up to drive the move to microservices, gave ourselves more leeway in assessing new technologies, created Dropwizard (a common platform) and found a way of specifying our APIs,” revealed Sztupak.

After 5 months and 3 weeks they finally found solutions. Legacy-in-a-box removed the convoluted build and deployment process, and made it easy to make changes to the legacy monolith.

“To ensure that the following was achieved, teams started to create microservices even though there was no way of deploying them, containers were introduced, GoCD was used as a framework, and everything was built automatically in git,” he added, concluding that Ansible, Docker and GoCD are the backbone of DevOps technologies.

Written by Leah Alger

The post Gamesys road to DevOps appeared first on DevOps Online North America.

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.

Summary

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.

The post Bring all the stakeholders together appeared first on DevOps Online North America.