Importance of Testability in DevOps

I want to home in on testing for a moment. There's a reason it's first, and one of the reasons I'm so passionate about this model is that it democratizes accountability. I think this is especially important with testing. I prefer the word accountable over responsible.

Accountability is a willingness to account for one's actions, whereas responsibility is having control over a situation or a formal duty to deal with an issue. The best example I have for this is parenting. I have a 7-year-old daughter. She's amazing. As a mom, I'm responsible for keeping my child alive. I provide basic necessities food, shelter, and water. But the higher-order role I play in her life is to love her. To model the principles I value. And to train her to be a self-sufficient, independent, functioning human.

That's where I'm accountable to my daughter. I make decisions daily and I never know if I'm choosing correctly, of course, but I do know that the information I used to make the decision was sound, and I know how I came to the conclusion I did. And when she's older, I'll be able to account for my decisions, even in the cases where I have chosen incorrectly, I have confidence that the best choice was the one I made based on the data I had at the time. That's all we can really do. Just like Rome depended on a broad network of roads to support their forces. Testing is what enables teams to move quickly and safely.

Testing is the responsibility of all of us. Innovation requires risk. It just does. We think creatively. We try new things, and we hope those experiments don't blow up in our faces. Occasionally they do. That's okay too. Testing is really what mitigates those risks. Now, there are a lot of different types of tests. In fact, so many it can feel overwhelming. I mean, which is most important? Which should you prioritize? Does 100% unit testing coverage actually matter or not at all? How do you evaluate the application or service? How do you determine that it's well-tested?

The trick, I think, is to really just get started. A single test is better than no test, of course. A dozen Well-implemented unit tests will carry you a lot further than you might imagine. And you know better than anyone the state of your current system, even if you don't have solid data yet. I mean, you have those things that keep you up at night. That corner of the codebase. That works even though it probably shouldn't. That's always concerning.

Let's see. You can have that intermittent failure you see every couple of months that self-resolves. That's awkward. Those. Start there. Whatever it is. And then continue to improve your testing stance. But no matter the type of test, your testing strategy should be continuous.

Comments are closed.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}