Quality Assurance, The Copenhagen Interpretation & The Cost of Uncertainty by Noah Ezsak

One of the oldest perspectives in quantum mechanics is known as the Copenhagen Interpetation. In an attempt to understand the position or velocity of a particle, scientists had determined that objects have certain pairs of properties that are dependent upon each other when observed. So during an experiment, only one property within a pair could be determined upon at a time. The thought experiment termed is better known as Shrodinger's Cat; colloquially, it means you won't know until you find out.

In the software business, this thought experiment is humorously challenged as organizations frequently expose themselves to significant risks and costs they could otherwise prevent. Risk, in this instance is measurable, but not pecuniary. As to knowing the cost of a bug in production; well, executives, coworkers, and customers are in the similar predicament as Shrodinger. Ultimately, it can vary depending on a number of factors, including the severity of the bug, the impact it has on the company's operations, and the steps the company must take to address the issue. In some cases, the cost of a bug in production might not incovenience a costumer at all, it could simply bring all the contracted teams into a large meeting to discuss collaboration, or exist until other fires are put out adding to existing technical debt & delayed time to production. In other cases, the cost can be much higher, such as lost revenue, legal liabilities. or damage to the company's reputation.

It is difficult to estimate the exact cost of a bug in production without more information about the specific situation. Companies are tolerant of costs, but not of risk. If you think of a risk as a potential cost, we frequently make a distiction between risk and cost based on the possibilities that are available. Risk occurs when the likelihood of an occurence is known- like tossing dice. Costs occur when the likelihood of a particular outcome isn't known like the lack of test coverage.

Unlike the business, scientists and testers love the game of uncertainty, it's what drives their curiousity and pursuit. In fact if you think about it, the Scienitfic Method was the first open source Quality Assurance solution on the market and just like any open source platform it came with all the grief of doing it by yourself & unsupported *rimshot.* But science prevailed and from the Copenhagen Interpretation came an equation. To summarize the findings Shrodinger proved as long the current properties were known, similar to modeling a test script, Shrodinger could understand the properties and follow as (quantum) physically close the path of where the particle might find itself next.

In the testing world not knowing where the next critical bug lies is choosing the loss of revenue at cost of operation excellence. This is the very essence of test coverage. Quality Assurance is more than just great documentation and architecture: it's verifying stakeholders have been delivered exactly what has been asked for. In the case of great execution, a QA team can actually be a resource for innovation. By reducing the release times & scaling test coverage the business can turn to developement and ask for greater experimentation. By protecting the future projects and increasing the pace of lagging projects, the creation and destruction of technical debt: the silent killer of innovation, QA can help shrink downtime so the business can constantly push in the right direction at scale. So, having excellent test coverage and certainty in the release is what gives the business the confidence to be nimble and innovate as fast possible to pursue the correct strategy... It's almost poetic how the mapping of a test script mirrors the collection of data and the pivots a business must take to course correct.

This game of cat and mouse, or light and particle, is what drives great science and test coverage. It's not like Shrodinger could shine a light on all of his particles to understand everything at once. Luckily for QA, bugs don't also act as waves (haha), and just like Shrodingers Equation, the tools necessary to scale test coverage are available.

There are of course critics of extensive testing and the abuse of automation. Automated testing does need stable code to function. Obviously the last thing you want to hear from QA is, "I don't understand how that code worked." On the other end, if the problem is the script itself and the result is a failure, then the value of the automation is null. The harshest of critics argue the maintanence of a project makes scaling test coverage not worth the ROI... This critism is the most perculiar, as if to say, "Why even try at all?" This topic also confronts a very interesting argument within the QA: Selenium, vs Codeless automation. Finally, some suggest not everything needs to be automated, there are many instances where manual is favorable. Like, when the script is very simple or maybe a step within the script needs double checking.

The irony of these statements; however, is the process of scripting is still manual, and with modern tools almost all testing upon a GUI is as intuitive as the interface and workflows itself. It is only the execution of the script that is automated. Automation simply allows for scaling while lowering the operating costs, which makes a competing tool the answer to the maintanence-headache of Selenium. From an operational standpoint, gross negligence in testing is a choice. Without question, there are hard dollar costs and soft dollar costs, the soft dollar costs can often become accrued liabilities when the consequence are work-arounds or diminished customer satsifaction. The risk and exposure whether by a 1000 small cuts or 1 critical incident will, with certainty, cost the business as your code and platforms become more involved.

Personally, I think quality assurance should be renamed Quality Insurance. From the business's perspective the risks justify the costs. But as stated before, risk occurs when the likelihood of a certain occurence is known, which is only half of the battle. The only question is how prepared and how capable is the team to scale test coverage. As a cost center there are definitive ways to improve efficiency. With modern tools it's incredibly possible to increase collaboration across the business suite by allowing business users to contribute to improve headcount and execution. As a financial exercise, the marginal costs of fortification is the insurance you are paying to have that certainty and confidence. The Copenhagen Interpretation is a great metaphor for the challenge of QA. Of all the bugs to find, how is it possible to track them, estimate the damage, and to understand their nature? How can a business track down bugs to feel confident, reduce costs, risks, and drive innovation faster? Well, in this analogy, the cat opens the box itself and ensures it's own certainty.

Connect with me here on Linkedin for more content & market insights: Noah Ezsak