The need for new set models and approach to fit the software testing profession in a complex domain

Instead of the traditional V-model I tend to promote the VOICE-model as a foundation because it uses terms as value, indicators, and confidence in pursued value instead of implying that quality comes through comparison against certain requirements, expectations, specifications or contracts. It might seem like semantics merely, but I’ve recently found the term “Quality” to be of diminishing value to me compared to “Confidence” because quality is so deeply related to people’s beliefs in the V-model, whereas “confidence” is a better manifestation of what we really aim for in a complex setting. This, since we can talk about it from various angles, both from an emotional aspect as well as a statistical angle: 

– “Do you feel confident that this will work in production?” 

or 

– “Can we with reasonable amount of confidence calculate the probability that this implemented change will lead to the promised effect on business revenue?”

Based on this new terminology to use in a development context, I train people to think, talk and act as a researcher or a scientist. Because there are certain levels of confidence that we as testing professionals need to be aware of to understand and weigh various facts, observations, data and stories differently depending on the situation and context. To visualize this, I´ve added an illustration below of a staircase of evidence to illustrate a couple of various levels. 

The automation triangle is another traditional model that also sometimes limits our ability to reach for the necessary assistance of automation. To create these simulations and predictions we need additional toolsets because we won´t be able to do this manually. Therefore, I´ve normally add another triangle on top of the traditional one, creating more of an hour-glass shape – where the top triangle is the automation triangle for simulations and forecasting as illustrated below. 

These process and models have served me well and generated a higher level of maturity in the discussions related to test & QA topics with various stakeholders, and I´m hoping that you as well are able to be inspired by these and perhaps even reuse some of them.

What could be the first step for us as software engineers if you start to suspect that the context you operate in could be of a complex domain? A context where no plans seem possible to follow any longer, where recommendations from experts seem to provide less or no value and very few pieces of information can be trusted in the long run? 

I would suggest that you remember this checklist and try playing around with these approaches and tools: 

• If you think your system is of a complex nature, start referring to it as something organic, in order to trigger people’s attention and enable new mental models. 
• Explore any short-term benefits of setting up an open data repository to gather test results, application logs, or any other data that might answer a handful of concrete question an important stakeholder might have. 
• Study and explore how to implement algorithms to support every aspect of your development tasks. 
• Start referring to your test environments as an area meant for simulations, where we conduct controlled experiments to predict the future. 

I would like to sum this article up with a reference to the Hippocratic Oath, the ethical oath for physicians that can be traced back to its origin over 2000 years ago. It has been rewritten through history, and formed the base in 2018 of the ITocratic oath by Jeffrey Schmitz (where I´ve gathered inspiration from and added a couple of changes myself):

I swear to fulfill, to the best of my ability and judgment, this protocol: 

• I will respect the hard-won scientific gains of those engineers in whose steps I walk, and gladly share such knowledge as is mine with those who are to follow. 
• I will apply, for the benefit of the end user, all measures required, refraining from committing any changes that do more harm than good towards user experience or business value.
• I will remember that there is an art to software development as well as science, and that warmth, sympathy, and understanding could outweigh any awesome backend API or stylish GUI. 
• I will not be ashamed to say, “I know not”, nor will I fail to call in my colleagues when the skills of another are needed for any improvement in the system landscape.
• I will respect the privacy of my users, for their problems are not disclosed to me that the world may know. Most especially must I tread with care in matters of fatal issues. If it is given to me to prevent a critical incident in production, all thanks. But it may also be within my power to kill any process; this awesome responsibility must be faced with great humbleness and awareness of my own frailty. Above all, I must not play God. 
• I will remember that I do not merely fix bugs or develop a feature, but enabling better user experience, that may cause an effect on customer ratings and business revenue. I need to keep this connection in mind if I am to care adequately for the user. 
• I will prevent issues whenever I can, for prevention is preferable to hot fixes. 
• I will remember that I remain a member of the software community, with special obligations to all my users, no matter if they choose to return awesome or crappy reviews. 

If I do not violate this oath, may I enjoy life and art, respected while I live and remembered with affection thereafter. May I always act to preserve the finest traditions of my calling and may I long experience the joy of creating an awesome digital experience.