The tech industry is seeing traditional testing and quality roles be renamed, changed, restructured and sometimes disappearing altogether. Yet, the need for testing and quality in software development hasn’t gone anywhere (and if anything, I think this need is growing!). So what’s changed?
As more organisations and teams move towards working in agile ways, I see two things happening in the testing and quality world: software developers and engineers are integrating testing work more naturally into their development activities, and testers are having to broaden their skillset. One of the skills that I think testers should be learning is how to implement DevOps (Development Operations) practices in their teams.
What is DevOps?
DevOps combines many different aspects of the software development environment into a model focussed on continuous improvement, automation and collaboration.
The DevOps cycle is often represented using an infinity loop, where one half of the loop represents traditional development activities such as defining requirements, developing code and testing it, and the other half represents operations activities such as deployment, packaging and maintenance/support work. The joy of DevOps is that these two activities are no longer siloed, and instead become one continuous activity that the whole team can get involved with.
So what does this mean for testing and quality?
Well in some DevOps models, quality and assurance activities become more tightly integrated with development and operations, and become intrinsically embedded in the DevOps cycle. Testing and Quality Assurance work becomes part of the entire team’s everyday practice, and part of the organisation’s development process.
But whilst this may mean we see less traditional, dedicated testing teams, we will begin to see the rise of quality leads who help shape the direction of quality processes within the DevOps lifecycle. They will be responsible for developing their expertise in automation, regulations, change management and testing tools and then implementing process improvements to help make the whole DevOps cycle operate at a higher quality standard without losing any of it’s efficiency.
The good news for testers is their expertise are still very much needed. The news some people won’t like to hear, is that we need to diversify our skillset and change our opinions on what it means to be a ‘tester’. As we enter the new era of agile working, a tester’s role is not so much about performing manual testing as it is about the larger picture of ensuring quality in every stage of the software development lifecycle.
Why implement DevOps at all?
Whilst it may be clear to see how DevOps fits in with agile teams, people who work on Waterfall projects may well think DevOps isn’t for them, and I would disagree. I think even those of us working in linear methodologies can benefit from learning some DevOps skills and implementing them in our teams.
A great example is in highly regulated industries like aerospace. The greatest benefit a DevOps model can provide is its cultural philosophy of removing expertise silos, and implementing automated processes wherever possible. In sectors like aerospace, development teams have to adhere to countless regulations and laws, making the development and discovery of requirements and code complex at best, and confusing at worst.
With a DevOps culture, developers and engineers would make use of automated tools to help simplify and speed up these processes. This may involve more of an initial investment upfront: whether that’s investing money in a COTS product to help with requirements traceability, or dedicating time to allow your teams to set up a linting and unit testing pipeline for their codebase. But when you look at the long term impact, the investment is worth it.
There will be less gaps and mistakes due to human error meaning you are less likely to be hit with fines or customer complaints. Your whole codebase can be automatically analysed, and continuously improved, keeping your code modern, functional and readable. Your teams can spend their time doing more complex tasks and using their knowledge and skills to improve the quality and value of your software products, rather than worrying about potential test coverage gaps or grappling with parts of a codebase that haven’t been looked at it decades.

Leave a comment