AMA Epistemology Answer: Definition Shifting

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

Demi asked: "What is the biggest change to your definition of QA that you dive into epistemology has caused?"

I think my current definition of QA is "Truth Finder and Risk Analyzer." I believe that QA does not break anything - the system comes to us broken, we just reveal that information. The truth is, this is the product. It's what was built. It's what we sell. It's what customers use. If you cant handle the truth, good news: we can fix it! But first we have to know what is true. 

This backs away from metrics-driven definitions that usually include writing test automation code or writing down test cases. Such things are easily trackable, but dont really drive Quality (see: Performative Testing). Instead, my deliverables become building understanding: meetings with stakeholders, exploring the product, and reports on what I observed. Of course I spent all Tuesday in a Slack huddle - I dont understand this feature, and clearly neither did the Project Manager, so we had to talk about that.  

At the next level is the analysis. The product is flawed, here's how each individual flaw is most likely to impact us as an organization. Who is impacted and how badly - what's the risk of not fixing this? What's the worst that can happen? Your product will never be perfect - key stakeholders need to know where to best spend their resources. 

I worked for an organization that had a horrible back-end configuration page. When I revealed the truth of how flawed that page was, the response was 'who cares? It's internal the person using it knows how to use it' and I replied 'what if they get hit by a bus? Can YOU train a replacement?' The risk became immediately apparent.