How DevOps is challenging testing teams
Limited Time Offer!
For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!
Source – devopsonline.co.uk
Antony Edwards, CTO at TestPlant, argues that DevOps may be an unclear buzzword for many organisations, but understanding the importance of keeping roles separate, while focusing on the customer, can allow testing to flourish
The concept of DevOps has become a buzzword in recent years, with many organisations unsure of its actual meaning. DevOps, the combination of development teams and operations teams, became necessary the moment SaaS (software-as-a-service) was born.
SaaS meant that development teams delivered software to their own operations teams rather than to customers, but often the operations team would say that the product wasn’t fit-for-production, and too often a stubborn deadlock would result in which the customer and the company as a whole were the losers.
The development team believed that the product needed to change, whereas the operations team thought that the web server environment was the issue.
As a result, the purpose of DevOps was originally to make both the development and operations team communicate with each other. This reached an arguably historical moment, at the realisation that DevOpps not only should be, but needed to be automated through the deployment process. Today, the name DevOps has become synonymous with two phrases:
Continuous delivery – DevOps is all about delivering new value to users faster (and collaboration between development and operations is central to this).
Automation – When organisations delivered products to customers every few months the build-test-package-deploy process could be manual (even though best-practice said it should be automated). But continuous delivery, where new versions are released several times a day, the process simply must be automated.
Speed over service
When organisations talk about DevOps, the first adjective that springs to mind is ‘fast’. It’s all about speed. Because of this, automation is essential: several hundred manual tests per day would be nothing short of impossible.
In light of this, DevOps teams can naturally become very inwards facing, reducing their emphasis on user experience in the process. The team is likely to focus on their own processes rather than the issues that the customers are facing, focusing on compliance rather than user-centric testing.
To tackle this, organisations often create another team that immediately succeeds the DevOps team, specialising in user testing and the customer experience. In Digital Enterprises (for example, retail and banking) this new team typically lives under the chief digital officer rather than the chief information officer.
Achieving a balance between focusing inwards and outwards takes a while to perfect — often between one or two years — but the benefits are worth it.
Too many cooks
Since the development and operations team joined to create DevOps, some organisations have eliminated roles to create an ‘everyone is everything’ structure. This in itself can be a leadership challenge, although in theory it’s great for employees to take on multiple roles.
However, it also means that employees perfectly qualified for one role are also assigned to a completely unsuitable one, and are expected to complete that role well. This can lead to some tasks being near impractical for certain team members, severely lowering productivity.
The problem with leaders believing that everyone has to be doing the same role is that instead of creating cross-functional teams, the entire team often becomes focussed on the function most people are skilled at (which is typically development since ‘DevOps’ usually grows out of ‘Agile’ change projects).
To tackle this, DevOps teams need to be genuinely cross-functional teams which include people with different skills and strengths just like a great sports team does. DevOps teams shouldn’t be a group of people focussed in one function suddenly given responsibility for all functions.
Putting DevOps to the test
Alongside ensuring that DevOps teams are using their individual strengths and are concerned about customer requirements, the testing process can also be challenged. Organisations often need to test processes that teams don’t have, so they must build them first.
This takes a considerable amount of time, which slows down the testing process. However, these tests rarely solve much larger organisational problems.
What’s missing in several organisations is a separate group of testers that conduct the test alongside the ‘rapid smoke’ tests. These are important in an organisation, since you can’t gauge user experience from 20 minutes of repression tests.
A brighter future for DevOps
With DevOps teams deploying numerous processes every hour, organisations need to automate their testing to ensure that all of the processes that are created are also tested, and are tested to a high standard. DevOps may be an unclear buzzword for many organisations, but understanding the importance of keeping roles separate, while focusing on the customer, can allow testing to flourish.