Skip to main content
Rows of verification icons with a semi-transparent overlay of binary code

Verification as Code

Reading Time: < 1

 

I recently listened to a talk by Matt Long on Why We Should Test Programmable Infrastructure.  You can watch a version of it on the MoT Dojo.  During the talk, he used the phrase “infrastructure as code”, which you may have heard before.

 

Wikipedia describes “infrastructure as code” as: “the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools […] The definitions may be in a version control system. It can use either scripts or declarative definitions, rather than manual processes […]”

 

ThoughtWorks defines it more plainly as: “writing code […] to manage configurations and automate provisioning of infrastructure in addition to deployments […]”

 

If we really simplify things, infrastructure as code is simply a form of automation in operations.  So why does no-one talk about how we can automate all operations tasks, and get rid of all our operations people in the same way that they talk about automating all testing tasks and getting rid of testers?

 

Gross misunderstanding is one obvious reason.  Another possible explanation is phrasing, or branding.  I think phrases like “infrastructure as code” and “continuous deployment” have very different connotations to “automated provisioning” and “automated deployments”.

 

I wonder how different the narrative might be if we talked about “verification as code” instead of “automated checks”…

 

 

Note: This is just a thought I had, written down.  I’m not saying we should start some campaign to rename anything, I just think it’s interesting to think about and compare.  I’m also trying out shorter-form posts, so I know there’s a lot of things I didn’t talk about here. That was deliberate. As always, please feel free to share your thoughts in the comments.

3 thoughts to “Verification as Code”

  1. It’s an interesting point. I think for me the misconceptions around being able to automate ‘all of the testing’ are because the industry refers to what you’ve described as ‘automated checks’ as ‘automated testing.’ People who don’t understand what testers do (critical thinking, investigation, exploratory testing etc.) then assume all of the testing can be automated, but really it’s just one part of it.

    This is presuming I understand what ‘automated checks’ means – for me it’s anything that can be asserted to be true or false and we’re testing for expected outcomes – happy to be corrected though.

    1. Hey,

      Thanks for your comment.

      I filed that stuff under “gross misunderstanding” 😀 I agree that the misuse of “automated testing” plays a big part too, but I was struck by the idea that there might be other words at play as well.

      I’ve also just learned from someone that there actually have been claims of “automating away ops”, and that “NoOps” is a thing. The more you know! I wonder if this has been a smaller / dying movement, or if I’m just not far enough into those circles to have noticed those conversations / claims. Definitely more to think about!

      Cassandra

    2. misunderstanding around test automation always start from misunderstanding of what testing is.
      the last one also goes together with difficulties in grasping the difference between QA (quality assurance) and testing 🙂 and so on and so forth…

Share Your Thoughts