AMA Epistemology Answer: Conflicting Beliefs

Partially back from a two month hiatus - apologies this took forever but it never left my backlog!
From the original moment: AMA about Epistemology - the practice of testing

Ady asked: "If quality professionals are there to help navigate beliefs in search of the truth. How do they build a shared understanding if stakeholders hold conflicting beliefs to the truth found?"

I have found that the difficult part of quality engineering is rarely finding the divergence of truth and belief. It's reporting that divergence, navigating the stakeholders, and ultimately advocating for alignment. And this is why we get paid - and occasionally in trouble for being the bearer of bad news. 

Context is key. Know your stakeholders and what they are likely to respond to. Some are metrics driven, some like pictures, some like formal reports. Some respond well to informal feedback, customer escalations, or churn while others need to be reminded of strict legal requirements that need to be met. 

In all cases documentation is the most important deliverable. If you can document a divergence and capture multiple different angles as to why it is an issue and why it should be resolved, you've given yourself a universal codex to present to any stakeholder. To build that, you as the quality engineer need to have a deep understanding of your systems space - the target customers, the companies goals, the problem space, relevant oracles, legal requirements etc. This deep holistic knowledge is what sets quality engineers apart from other professions. 

Once you are prepared to present your case, the conversation starts. There's an old saying "a consensus is reached when no one is happy." If we believed that everyone could fully align on the resolution, I would not be answering this question. The reality is, we're going to have to achieve a new belief and align the system to it. By presenting the information in a format that the necessary stakeholders can understand, they will need to discuss amongst themselves the resolution. This is why bug reports often morph into feature change requests. 

Personally I believe that quality engineers should not have a strong belief about the system. We should simply be holding spaces for other's beliefs while presenting where they conflict with each other and misalign with the truth. At the end of the day, what matters isnt arguing over weather it's a 'bug' or a 'feature' but rather ensuring that alignment.