Observability meet Qualtability

Observability, colloquially known as 011y, meet Qualtability (also answers to q10y).

For those of you new to my blog, My name is Anne-Marie Charrett (@charrett on twitter). I’m a quality engineer by trade, a software tester by craft.

I’ve always been passionate about pulling things apart to figure out how they work.I was always the one in the house to fix the TV. No big surprise when I did engineering at University. Even less of surprise when I ended up pulling software apart to identify flaws. When asked at University what I understood quality to be, I said it was a mindset. To this day I stand by that definition. It probably explains why I like Jerry Weinberg’s definition of quality: It being value to some person.

Observability as defined by honeycomb.io is

“A system that is appropriately observable is a system that is instrumented well enough that you
can ask any question required to support it at the level of quality you want to deliver to your
users.”

Both are intrinsically linked.

To be able to provide observability in a way that is digestible we need to understand what quality is for our consumers. Without being able to observe systems in all their glory, we won’t know its qualtability. Qualta–whaaa?

Qualtability is :

the ability of a system to see that state of quality at any point in time. Ideally we want to be able to observe our systems so at any point in time we can interpret that information to better understand how good (or bad) our quality is.

We need to be able to see quality right across software delivery, not only right at the end before release or in production. We need to figure out ways we can observe and infer the state of quality at any point in time. We want to be able to see the state of quality at design, during development and after release. We need tools and techniques to do that, now more than ever.

Why now? Because corporate understanding of what quality is constantly changing as it tries to adapt to changing consumer demand. Speed to market has to some degree become a quality attribute. No longer is it “the large eating the small, but the fast eating the slow”. The definition of product is shifting too, to something that is less visible to a consumer’, less easier to test from a consumer perspective. For example a ‘product’ might be a set of API’s with little direct user interaction. Combine with increased system complexity and we are faced with systems that not only are getting harder to test, but there is less time in which to do it diligently.

The goal is to have a consistent view of quality at any point in time across the delivery and avoid the hockey stick approach we are all familiar with.

We want to apply a diversity of techniques and approaches to see quality at any point in time. We want to avoid lumping our ability to see quality into software testing at the end where we get an almighty surprise. We want to see the state of quality before and after we release, so that to some point we become release agnostic. This is what Qualtability is all about. Without observable systems our ability to ask questions of these complex systems becomes limited.

It’s with this mismatch and hodge podge set of ideas that I’m setting off to o11y tomorrow. I hope to listen and learn from a bunch of smart and forward thinkers in the observability space. I hope to be able to share my expertise in software testing and quality.

See you all tomorrow folks!