What skills do testers need in the DevOps era?

DevOps… this is a phrase that has been winning Buzzword Bingo competitions hands down in recent times.  It didn't exist as a term a few years ago but now we can't escape it whatever our role in the  software delivery process is.  So lets focus on what skills testers need in the DevOps era?

We all know how testing has evolved over the years, from an afterthought in the delivery process through to a recognised role that has steadily become more disciplined and structured.  Then in recent years we are told that companies don't want developers or testers anymore.  The shift has been toward generalised specialists, engineers, and T-shaped individuals.  Ever more impressive job titles and roles are bandied about (even 'Test Architects' pop up nowadays).

In the previous world

Everyone had clearly defined roles.  A siloed team of developers would build a solution and throw it over the fence for a bunch of testers to eagerly set about trying to find bugs.  Oh... sorry, I meant testers would try to prove the solution is fit for purpose.  Once test execution was complete it was usually the end of the line for the tester role.  The test manager would issue the 'Test Completion Report'  to be reviewed at a CAB meeting and a live date scheduled.  Sound familiar?  

In a nutshell, testers were not involved in the early or latter stages of the DevOps process, just wedged in the middle, with no power to contribute to any stages prior to or beyond their bit of the action.

In the new world

So what do testers need to know?  How is our role changing? How do we stay relevant?  If the aspiration is for blended teams who have complete autonomy to design, build and release software under their own steam then what new skills do testers need to acquire?

• Process: To people of a certain age (yes…that includes me!) when all these aspirations around shift left,  little and often, etc. were first touted, it was met with a certain amount of fear and trepidation.  As someone who's early career had seen me working in the private  (banks) and public (HMRC) sectors with their huge beaurocratic, risk-adverse processes it took some convincing to be told software delivery could be done a radically different way.  The biggest leap of faith for me personally was around releasing software into production.  What was this little and often phrase all about? At HMRC biannual releases were set in stone for decades.  So having to un-learn what my respected mentors had taught me in my early career was not an easy thing to do.
• Roles: An understanding of the full E2E process.  Gain an appreciation of what other previously siloed roles that we never used to need to know about do.  To be self-sufficient as a delivery team we all need to wear many hats.  What was previously some other teams problem is now our teams responsibility
• Test Automation: Automate as much testing as possible.  This has been a trend for many years now, but the constant drive towards little and often releases to test and production environments places ever more emphasis on automating as much as possible.  Whereas it used to just be functional UI tests we automated, now we want to automate other areas of testing too, such as security, performance and accessibility to name a few.  There is a great choice of free and licensed tools on the market currently, and ever more flexibility for automating more flavours of testing with single or integrated tools.  A note of caution that I will pick up in another article in the near future: I am a huge automation fan, but have never seen it reach a level of maturity where I would be comfortable not performing any manual testing before a feature is promoted to the live estate.
• Release Automation: How to embed the afore-mentioned test automation directly into the release process, so it happens as soon possible, with minimal need for manual intervention.  The only manual stages should be the ones we choose to put in, such as approval/gatekeeper stages for production.  For testers to gain more knowledge of build, continuous integration, continuous testing, deployment processes and how we can make full use of the built-in features of cloud based work management solutions is a great string to add to our bow.
• Monitoring Tools: If we are doing more frequent releases it is even more essential to have an automated alert process for if things go wrong in production.  There are a great wealth of tools out there that enable us to pinpoint the key user journeys and ensure they are working correctly.  Alerts are crucial for us to immediately know if traffic suddenly declines after a change goes live.

These are my thoughts on what skills someone who refers to themselves as a Tester needs to have in the future in order to embrace the DevOps mindset.  I would be interested in hearing the experiences of others who also have long enough memories to remember the old world and have found themselves placed in this brave new world: good and bad experiences are equally valuable learning. 

It would also be great to hear from people young enough to not remember any other way of working, so not having to worry about 'un-learning' anything they had previously been told was mandatory.

Alex Kaiser (Spike95 - Principal Test Automation Consultant) has enjoyed a wide ranging career in testing, spanning 20+ years.  He has had experience of all the joys - private and public sector, huge programmes and small startups, every methodology and new wave of roles.  Being part of some fantastic ground breaking achievements and also some absolute stinkers that are best hidden at the end of his CV!

Spike95 is a technical testing consultancy. We make sure software is reliable, scalable and delivers the experience you and your customers expect.[vlt_social_share title="Like this post? Please share!"]