DevOps and the emergence of TestOps!

The tech landscape is forever changing; a perfect example of this being the constant ripping up and rewriting of the software development life cycle. It comes as no surprise there are demands and expectations for people to learn new skills and adapt to the new ways of working.

The way we operate, not only as an engineering team, but within an organisation, is quickly shifting. In recent years, the emergence of DevOps has a tester’s responsibilities and title varying from project to project, and from client to client.

This is a frequent topic of conversation wherever you go and whoever you meet.

Why is this? Because life is better with DevOps.

DevOps is more than just a methodology, it paves the way for quicker and more frequent releases. It enables the QA to spend more time on improving the release process and in turn take a better quality product to market.

Let’s just make one point clear DevOps is a ‘methodology’, it is not just another development task, it is a way of working. Often I have seen DevOps classified as another role.

DevOps is the process by which you shorten the time it takes to deliver to consumers. It is a means to deliver as quickly and efficiently as possible and to optimise the stream of development from conception to delivery.

None so more than in recent years has this been so crucial to our industry and the wider market.

In a tech-dominated society, the quicker you can deliver the longer you can stay ahead of your competitors. In this type of environment, the tester should be proactive in detecting and mitigating issues.

What is TestOps anyway?

So, if there are DevOps engineers already doing the job then why are we talking about TestOps and what is TestOps anyway?

Our tech industry is booming with microservices and cloud services. Things are getting a lot more complex; most companies no longer build an application on its own. Most applications are a mix of many small services that come together to make a complete product.

This complete product usually lives in the cloud, where it is easily accessible at any time, anywhere, given you have sufficient privileges.

But, what does this all mean and how does this have anything to do with the average tester?

All of these interconnected services and components are a part of a chain that is the complete product. This chain of services means that there are many more points of interception for a tester to be involved in. Long gone are the days where you have a manual regression pack that continuously gets bigger and longer to test.

Testing today is comprised of many forms, such as visual testing, performance, security, functional and API testing. As you can imagine having to test a combination of those for every release that goes out can really slow down the delivery process – in fact this will most likely cause a bottleneck which the tester is responsible for. Continuously testing and validating the product is a tester’s responsibility.

This is where TestOps comes in. TestOps is responsible for utilising tools and identifying tech to implement some of these types of testing.

An emerging skillset

TestOps is an emerging skill within our testing communities and is being driven by the need to continually test products at different levels using different tools. It involves using a test automation framework to continually test and validate the product as it is being built. Testing frameworks have become much easier to work with and scale up with new extensions and features in recent years.

QA is one of the fundamental pillars of DevOps; it’s rightly so that a tester should bear the main responsibility to enhance the test automation process.

TestOps is a combination of a software testing intellect with some of the skills of a DevOps engineer and this is why it is different from the ordinary tester. I believe this is the ‘complete tester’ and combines the quality, development mindset and the knowledge to connect it all together.

An ordinary QA these days is responsible for writing automation tests and executing them as well as mixing in the manual testing aspect too.

They don’t normally get involved in setting up environments or CI/ CD builds.

A tester adopting TestOps should understand how to integrate their framework with tools such as Docker, Browserstack and Jenkins, to name a few, so that they can get the most out of their tests.

Not only should they be technical in working with these, but they must also understand how to best approach the level of testing at different stages and different environments.

The key goal for TestOps is to work in such a way that your tests should be as robust as possible with the lowest execution time.

More involved in the ecosystem

TestOps is there to set up an ecosystem which includes the automation framework and integrated tools, with a longer-term vision to continually enhance this ecosystem. It’s common practice in our industry for developers to build their own build/deploy pipeline, with some assistance from a DevOps engineer.

For the tester this is different, In practice all, or a majority of this work, is handled by a DevOps engineer and developers, this, in turn, doesn’t allow the tester to have a greater input into the process.

TestOps can change this, by owning this process and handling Test related DevOps activities. This enables the QA to be self- sufficient and directly involved in their respective area. Just like the developers, they will curate the test pipeline to their exact function and needs.

By all means, we don’t expect a tester to become a developer or DevOps engineer, but they will own a part of the pipeline. Those practicing TestOps should endeavour to make their automation pipeline as bespoke as possible, to ensure it can handle business changes and adapt as quickly as possible.

Another key pillar, not just in TestOps but in testing as a whole, is that you are constantly trying to inform the business of what is going on through feedback mechanisms, whether through logging output, visual displays, or other means.

This also means notifying early by detecting failing tests faster, in turn allowing the business to react and respond quicker. A fundamental part of this visibility is being able to interpret test outputs into a clear format and easy to find locations.

It is increasingly important for TestOps to integrate an effective reporting tool to their automation; they should not leave it to a basic console output. It is TestOps’ responsibility to ensure full visibility of tests to all concerned and convey a clear understanding to others what those tests are outputting as well as how and where.

If you have a scenario to check whether or not clicking a button does something, then make sure this is presented, it is easier to read and understand something that says ‘could not find x button to click’ than to display error:ff5hfh undefined exit status code 1.

The reason this is especially important is that the results are often reserved and checked only by QAs. It is TestOps’ responsibility to ensure the full visibility and readability of test execution outcomes to all stakeholders in the business.

A fundamental understanding

TestOps for me is more than technical skill; it is understanding the fundamental reasons why we need QA at every stage possible and how we can be involved without being directly involved, and how we can give confidence to the business when we are not there.

Understanding how we can utilise testing tools to reduce the repetitive workload of QAs, and how this can transform the development process into a faster, more reliable, more responsive operation.

Like all facets of the tech industry, testing is evolving rapidly. We have seen SDETs and QA Engineers become commonplace in tech teams across many sectors.

In recent years, the industry and developments in technology have dictated changes in how testing is performed, including bringing elements of DevOps into the arsenal of tools available to testers.

For me, these demands imposed make it imperative that testers adopt TestOps in the future, despite any resistance to deviation away from the classic manual testing approach that has been such a staple approach in the past.

Companies are realising the potential that testers have and how under-utilised sometimes they are – they want to get the most out of them.

Testers are essentially the gatekeepers to the quality and usability of development projects. With all the talk about AI, Blockchain and IoT in recent years, it is definitely a fast-paced and constantly moving job role.

These will all play a crucial part in the future of how we do our job. This is a journey I have been personally taking myself. As a tester, you have this rich exposure to everything and it can feel like something we take for granted or not take up – an opportunity to extend our skillset.

Testers should also adopt this to their respective area in DevOps. The lines are constantly getting blurred between testers and developers. This is not just born out of necessity for the hiring business, but naturally by the progression of technology and different streams of work.

Ditmir Hasani, CEO, QA Tech Consultancy