The role of QA in DevOps
With the lines becoming increasingly blurred within DevOps, multi-disciplined teams are looking set to be the shape of things to come.
Unbeknownst to me – until I used the power of the Internet to learn such pub quiz facts – the term ‘DevOps’ was coined in 2009 and popularised with an event held in Ghent, Belgium called DevOpsDays.
This was run by an American agile enthusiast named Andrew ‘Clay’ Shafer, and a Belgian agile enthusiast named Patrick Debois.
I would imagine that is a widely unknown fact amongst industry professionals, and yet these gentlemen are responsible for naming one of the most in-demand disciplines in software development today. I think they’re worthy of a shout-out for that reason, and it’s nice to know where the term we use on a day-to-day basis comes from.
Moving on from the history lesson, let’s delve into a high-level description of DevOps, what it is responsible for, aims for, and importantly; what it isn’t.
What is DevOps?
To quote my friend and colleague Steven Burton, “DevOps is the narrowing of the gap between the creation of the product and the delivery of that product to the customer”.
It achieves this through the use of different frameworks and tools, of which there is a large market to choose from to suit the needs of the project.
DevOps is about company and team culture to deliver value. This means that it’s about making sure the correct thinking processes are in place and there are reduced barriers to getting the right things done.
Tooling and frameworks are very similar to automation, in that they are side effects and almost symptoms of the right kind of culture – we don’t want to put the cart before the horse just because we know the cart is going to be needed at some point.
Traditional Ops are concerned with the infrastructure of systems; not the actual code of the product itself, but where and how it is hosted, deployed, updated, managed.
What is DevOps responsible for?
DevOps’ ultimate responsibility is to ensure any features that are developed are delivered to the customer as efficiently and quickly as possible. Test environments are an important part of this and part of DevOps is ensuring they are available and realistic when compared to live.
DevOps has to ensure that it is simple and efficient, to deploy versions of the software with the lowest amount of risk possible. It should adhere to clear agreements and provide metrics to stakeholders that show how well the agreements are being met.
As alluded to earlier, DevOps’ primary concern is getting what was written in an IDE into a usable state for the client as quickly as possible, and facilitating all of the steps in between.
What is DevOps not?
DevOps is not:
- Responsible for what the product functionally does
- A tool, any more than ‘software development’ is a tool
- Subjective, it asks specifically what is required, and delivers that (that’s one of the reasons that, as a tester, I can really identify with it)
- For someone else to worry about
- Synonymous with automation, however automation of tasks/testing can be involved
- A role or team, any more than you have a specific ‘agile’ team to make your company more agile.
As stated earlier, we want to reduce the overall time it takes to get new functionality out and live. DevOps is largely going to be responsible for this, and what a responsibility it is. It won’t matter how polished your product is if it is simply late to market; you will have been overtaken by then.
Furthermore, moving code across and through the different staging environments that companies use facilitates other necessary operations – hence the subject of this article.
Testing in DevOps
Testing is a vital part of the DevOps ways of working and an ultimate benefactor of a good pipeline. As a tester, we are trying to help assure quality software and lower the risk as early in the process as possible. Having pipelines which narrow the gaps in different stages of the software development lifecycle enables us to do this.
From ensuring that a product is more testable to making that product available on a realistic test environment as soon as possible, DevOps encourages many processes that make testing a better- targeted activity.
Therefore, as a tester, you have a vested interest in driving forward a DevOps culture within your team and department.
Teamwork makes the dream work
In my career I have seen multiple ways of handling DevOps, from there being an integrated member of a team who specifically deals with it, an entire external team who are responsible, to lastly it being an additional responsibility of a whole development team.
Let me say this in no uncertain terms: I wholeheartedly hold the opinion that the last option is strictly superior to the former two. I am aware that this isn’t exactly an outspoken view per se, but it will certainly be against what some readers hold dear, or what they are accustomed to.
The advantages of having a team full of people who are embracing a DevOps culture is that they will fully understand the product they’re delivering, as it’s what they work on every day.
This means they are less reliant on external dependencies and have less blockers with external teams. They won’t have to raise a ticket with a team in a different part of the building. They know exactly what the product needs, what it needs to run suitably, how it might be un-performant, what level of support is required. If they need something to be slightly tweaked or changed… they can do it!
In reality, I believe multi-disciplined teams are where we are going to end up in the near future – as a standard.
Would you prefer to hire a developer with no DevOps experience or one with plenty, all other things considered equal?
It’s a no brainer in reality. Teams need people who take responsibility for what they work on, and don’t just throw something over the fence and decide it’s not for them to worry about any more.
This is the current lay of the land in the team I work in, and I feel empowered in the knowledge that if something wasn’t how we wanted it to be, we could just change it. Be it our Slack integrations, our monitoring, our AWS deployment system – it doesn’t matter. It’s all for us to decide.
This leads me onto my final point: what can we do as aspiring DevOps-ateers? (here’s hoping that phrase catches on so I can be quoted in an article in 10 years time!)
Responsibility is a word I have used a lot over the last few paragraphs, but I can’t stress how much your company will want its employees to be taking some on. Not only does it develop your skills in areas you may not have much expertise in, but taking on more responsibility genuinely makes your career more fulfilling in my opinion – heck, this is just a fact of life in general.
People often love to boast about how they have no responsibilities so they have free reign to do whatever they want. It only gets you so far, however, before you realise in life it’s taking on responsibility that makes you stronger as a person and far, far more capable to deal with the problems of both work and life.
I don’t think people in the QA part of the team should have any more or less affiliation than anybody else in the team – it should ideally be a joint effort of all.
My recommendation for becoming more adept at DevOps practices is to read as much as you can in your spare time about the topic, and then take a really good look at the way your process in your team or workplace currently operates – from your use of CI pipelines to your code merging strategy.
You will know where the pitfalls are, where you are slow when you need to be fast, where you are unstable where stability is key. Discuss it with your team, and see what they think.
Soon, a list will emerge. Some things won’t be fixable the next day, or even in the next six months. But once you write down the problems, they’re in your sights and you can start chipping away at them one-by-one.
Too many businesses like to turn a blind eye to these things, and then wonder why there are blockages or inefficiencies.
Don’t be wilfully blind – find those problems.
Rob Catton, consultant, Infinity Works
