ATOMYQ: Another Testing Oriented Model w/ Yummy Quality

The third edition of OmniTestingConf happened last month. This edition was themed around the Native Quality Management idea, and several speakers brought their insights about ways of improving quality together and having it as ongoing concern of all team members.

During my talk, I covered the richness of "quality", all the possible meanings we can have related to it. But also, what "value" means and where does it come from.

I came up with a new model: ATOMYQ: Another Test Oriented Model with Yummy Quality :-)

But why do we need another model? And what does it mean? Well, first models are ways to abstract some part of reality; they are ways for us to explain ideas and start conversations. They don't need to be accurate but they are nevertheless quite useful, because they can highlight concepts and how they relate to one another.

Meet ATOMYQ

ATOMYQ is a model that centers testing around 3 main players: Product, Team and (each) Person.

Team

All starts with the team. The team as a whole has a set of diverse skills that require learning and practice. Skills are used to craft our product, in all its dimensions, and all its assets. Unfortunately for us there are constraints. Constrains that will influence our skills, their intensity, their extensity, their reach. Testing also makes use of skills, many skills in fact (technical and "soft" skills). All of those are engineering skills. Testing is also applied into our other skills whenever we exercise them, i.e., we are only excellent coders if we care performance while coding algorithms, for example. All of this is the reason why team skills are so important, and why we should care about improving and fostering a knowledge culture. Investing in the team, is investing on the product and its value in broad sense.

Testing uses different sources of information to uncover bugs and opportunities in our product. Well, let me clarify the previous sentence. First, we use data... and some of that data is actually valuable information; a written specification is just a source of data, not a scientific, closed fact. Second, testing doesn't exist in the void... or alone. Testing is performed by humans that can make use of skills, tools, automation and all possible means to assist them.

Ideally, testing should be performed by the team, in everything that the team does or doesn't. But testing, as a brain driven activity, ultimately runs inside each person. Each one of us will have different insights, different backgrounds that are essential to explore our product and its idealization.

Product

Many times we think we pack value into the binares we build or the code we write. Well, tt's just not about the code we build... it's everything related to product, including documentation, all enabling kind of materials, and more.

What we build, how we build and what we decide not to build are the foundations of product attributes. Our product as a whole has a bunch of emergent properties and attributes, some of them are called quality attributes in the sense that they contribute somehow to a given view of quality.

Nowadays I see the release frequency, i.e. how frequently we release updates on our product, also as an attribute of the product. The quality adjective that can perhaps frame it is: freshness.

On the ATOMYQ diagram we can depict bugs and opportunies as living in the product; I struggle to position them to be honest, but that will require some additional thoughts.

Person

Each person, as a unique individual, weights differently product attributes to come up with value.

This not only changes with whoever is involved but also depends on the context, and on the time. Example: if a person was robbed/scammed up recently, maybe security now is one of the attributes that matter most for that person, at least for the next couple of days/weeks!

Quality also informs testing, and thus influences it, as we'll pursue testing focused around the quality attributes that matter most.

Other things worth mentioning

Our product assets, which are diverse, come from the team as a whole, and not from a single individual. It's the skills within the team that shape our product. Testing is mostly done by the team members but not only; other people, including our users, also test our products.

Testing is not used just to find bugs; I like to think on testing from a positive perspective and think more about opportunities for increasing the value of our products.

As a team sport, testing also shapes how we think and thus improves our skills because as we become aware of potential problems, it changes what we do and how we craft our product assets in the future. So yes, if we think on testing as something happening at team level, connected to the team skills, then yes, testing improves quality on mid/long term. This may be controversial, I understand, but it's my experience has someone that worked having different roles within product development teams, or whenever working with some external ones.

If we think testing as something done by a given person having the "tester" role, then we can see more testing as a bug reporting kinda of activity. Finding bugs is indeed important but we need to move from there and actually improve quality. If testers become more and more quality coaches, they start influencing the team and we'll see improvement on the skills within the team, ultimately leading to the overall improvement of quality. Still testing itself is crucial, but as a whole team concern. Well, that's how I see it right now.

In sum

ATOMYQ presents the interactions about different players in organizations that are helping others achieve some goals, through the value provided by their products.

Quality is multidimensional, time dependent and view dependent. We don't pack quality. We work with quality in mind, so what we do, shaped by the skills that we have and that the team has, will lead to better product assets.

The goal is working torwards increased team confidence, aligned with better team understanding of what value means and what blocks us from delivering/caring for/improving it.

Testing for sure help us as it is at the center of ATOMYQ, close to opportunities and bugs we cannot ignore. However, testing is not atomic. Instead, it's something we do, more or less explicitly, continuosly because ultimately we use it to improve our knowledge and the art and engineering that is building products, that people use, love, and even pay for.

Skills are essential; testing itself is a broad skill that can help us not only become more informed but also look at things differently, wisely, with value and risk in mind. Looking not just about where we stand, but where we want to go and what we can do to get us there.

Happy holidays/merry christmas, with quality time. And I leave "quality time" definition to yourself, as I'm sure that noone better than you will know the best answer that fits your context :)