When you begin to automate your deployments, you’re also going to start automating your testing. After all, a deployment, in and of itself, is a test. However, pretty quickly, you are going to come to the question that’s the title of this post:
Who is responsible for building tests?
I have two flippant answers that I need to get off my chest before we can continue:
- It Depends
Bad humor aside, who is going to receive responsibility for building tests? My answer actually involves asking two other questions:
Who does the test serve?
Who has the knowledge needed to appropriately implement the test?
I believe answering these questions will absolutely answer the responsibility question.
Who Does The Test Serve?
Another way to phrase this question is, what is the purpose of the test. We need to determine if the test is meeting the needs of the development team, the database team, ops, QA, or whoever else might be involved with testing the software you’re developing. Understanding which team, or individual, needs the test will certainly help to determine who is responsible for seeing that the test gets created. The team that is most likely to be concerned about the outcome of the test should certainly be driving any decisions made around the test. However, that doesn’t mean that these are the people who will ultimately implement the test.
Who Has the Necessary Knowledge/Skill?
While we have determined who owns the test, or at least, who would like to see it implemented through our first question. It doesn’t answer who has the skills needed to implement the test. It’s entirely possible that a test that serves the development team is better implemented by the DBAs because the necessary data setup, movement, or even permissions on the database fall outside their skill, knowledge or access. The same thing can hold true with any job description and their associated skill set and knowledge. Some teams may be more interested in seeing a test implemented, but other teams will be doing the implementation work.
One note here, this is not an excuse to dump all the work on a single team. “Ah well, you’re the only team that knows how to add tests to Octopus, so you get to build all of them.” This is not an acceptable approach. Instead, the need for a test could also become the need to expand your skill set just a bit so that you can implement the test.
Because DevOps is so much about breaking down barriers and fostering communication, the idea that only one team will be responsible for all aspects of any part of your DevOps implementation is unlikely. Instead, you are going to see developers working more within the operations space. Conversely, you’ll see DBAs writing a bit of code to get a test set up. All sorts of variation on this theme will pop up all over. Because, after all, everyone is really, ultimately, responsible for ensuring that the work gets done.
Was this article helpful?