Development should include testing. So why do we have test ops?

How’s life

Joel:

  • January is proving to be very busy!
  • We are running the State of Testing, so I want to plug that one since we need the help of everyone filling out the survey.

Rob:

  • Great Christmas break, now back into a new year with new opportunities.

I’ve been somewhat bemused by the rise of Test Ops.

For years now I’ve seen testers strive to carve out niches for themselves within the industry – we’ve done a podcast previously on some of the main niches you might find. It’s natural – as the world shifts and tech changes we forever need to be mixing things up and emerging new ideas.

Test Ops though is one that still bemuses me to this day, and no amount of reading about it seems to make any sense to my old brain.

So let’s try to analyze together what Test Ops means, or what it may mean, and get an idea of what practical things we can get from it in order to improve the value we provide as testers in our teams.

How about we define it first?

  • There is a good article called “DevOps and the emergence of TestOps!” by a guy called Ditmir Hasani- https://www.devopsonline.co.uk/devops-and-the-emergence-of-testops/ that tries to define it, and it does a pretty decent job at it, at least in my perspective.
  • In a nutshell, he explains that as we work more and more with DevOps, shortening cycles and increasing collaboration, and as architectures turn more to Microservices and the endless interactions within them. 
    Then Testing becomes a bottleneck to work on, and TestOps is responsible to look for technology and tools to help the team test better and faster, especially in this new methodology and technological reality.
  • So, to simplify this:
    • DevOps is making teams collaborate more but also release faster, meaning less time for testing – we all know that.
    • Cloud, Microservices, Integrations, Portability, etc just multiply the set of testing tasks we have in our team basically ad-infinitum.
    • Traditional testing doesn’t cut it.
    • Hence we have TestOps to find tech and tools to solve our problems.
    • SOUNDS LOVELY!!!!!
  • I think that TestOps sounds like a term that someone from a tool company or consulting firm came up in order to sell more stuff.  Believe me because I have been working in tool companies for most of my career.  So do not take it too seriously.

But leaving sarcasm aside, let’s try to understand what makes sense of this…

  • The points that we mentioned are real.
    • DevOps has had a great impact on development and obviously on testing – since testing provides services to development in this case.  If our “customer” changes the way they work we need to change ours to fit.
    • The way we used to work doesn’t cut it, not in the time we have, the approach that works, the people who test, etc
    • Tools can help.  We definitely need better tools – please buy more tools (wink wink – remember I work for a tool company)
  • If you were a tester that went to sleep back in 2010, 10 years ago,  and woke up today, your skillset would most probably not be good for the challenges that are required from you – IF YOU WORK ON THE TYPE OF ORGANIZATION that is working based on DevOps and on Cutting edge cloud or mobile tech.

But there are many things in this discourse of TestOps that sound to me a bit forced, and in a sense that do not match the culture of a DevOps organization – that same organization where TestOps should be implemented

  • It still sounds to me like using TestOps reflects the fact that we are trying to say that Testing is the responsibility of the tester (all hail this point).  Well, this is not true if you are working on a truly agile and especially DevOps team.  If you are working DevOps, then one of the first things to change is the fact that Developers will run tests, and a lot of tests.  You will still have testers, but they will not be able to test everything – sometimes not even most of it.  So thinking that testers are in charge of testing sounds like when people said that they work agile, but Testers test on this sprint what developers coded on the previous sprint.
  • Exactly why I cannot understand, in my old head, why testing is not just already part of Development – testing is an activity done by all, not a role done by a few.
  • Tools, tools, tools, all we need are tools and they will save the day.  Oh God, can someone please take people who talk or even think like that away from us?  A fool with a tool is still a fool.  And tools won’t make you less of a fool, never!
    Tools are important, sometimes even critical, but they are never the answer.  If you do not have a great process and team behaviors, together with tooling and technology then you might as well not waste the time (and money) to buy the tool.

Shouldn’t we just call it DevOps?

  • So, doesn’t this mean that this TestOps is just a way of saying testers on DevOps need to look for additional tools and technology to do their work?
  • I think it is good that we are explicitly talking about tools to help testing as DevOps becomes more challenging, but we should not imply other things since it just diminishes from it, and especially from the fact that in DevOps we need to have a SINGLE team of both Developers, Operations and Testers working together.

And we have not yet even started talking about Testing in Production, or Modern Testing, and a lot of additional stuff that we have to cover for Testing in DevOps…

  • But better leave that for their own episodes.

 

No comments yet.

Leave a Reply