Practice Notes from Quality & Delivery Transformations

Blog

  • Practice Note: Two Kinds of Blogs

    I recently realized that I have been thinking about blogs in the wrong way. For most of my professional life, I assumed that writing followed a simple sequence:

    Think → know → write

    The purpose of a blog was to communicate something that had already been figured out. You learned something. You formed an opinion. You developed a framework. Then you wrote about it. The blog was a publishing mechanism. Nothing more.

    The Reporting Blog

    This is the type of blog most professionals write. Its purpose is to report existing knowledge. Examples include:

    • Lessons learned from a project
    • Explanations of a methodology
    • Reviews of a framework
    • Conference summaries
    • Practical advice

    The underlying assumption is: I know something that may be useful to others.

    There is absolutely nothing wrong with this. In fact, most professional blogs should probably do exactly that. But recently I discovered another possibility.

    The Discovery Blog

    The second type of blog serves a completely different purpose. Instead of communicating conclusions, it helps generate them. The process looks more like this:

    Observation → writing → reflection → insight

    The author does not necessarily know where the idea will lead. Writing becomes part of the thinking process. The blog becomes a laboratory rather than a broadcasting platform. This was a surprising realization for me.

    Thinking Through Dialogue

    The insight became even more interesting when I connected it to something I have noticed about my own way of thinking. I have never been particularly good at sitting alone and brainstorming. Many people seem able to start with a blank page and generate ideas. My mind does not appear to work that way.

    Instead, most of my useful ideas emerge through dialogue. A conversation introduces a question. An observation triggers a response. A challenge reveals an inconsistency. A pattern suddenly becomes visible. The thinking happens in the interaction. Only afterwards do I realize what I think.

    This explains why some of my most valuable insights have emerged from discussions rather than solitary reflection. The dialogue itself becomes part of the reasoning process.

    Writing as a Dialogue

    Perhaps that is why the idea of a discovery-oriented blog feels so appealing. Writing does not have to be the final step. Writing can become another form of dialogue. Not necessarily with other people. Sometimes with oneself. Sometimes with future readers. Sometimes with an idea that has not fully formed yet.

    A field note captures an observation. The act of writing clarifies the observation. New questions emerge. Those questions lead to new field notes. Over time, a line of thinking begins to develop. The blog becomes part of the conversation.

    A Different Relationship with Uncertainty

    The discovery blog also changes the role of uncertainty. In a reporting blog, uncertainty can feel like a weakness. The expectation is that the author knows the answer.

    In a discovery blog, uncertainty is often the starting point. A good field note can begin with:

    I noticed something.

    Or:

    I am not sure why this keeps appearing.

    Or:

    These two things seem related, but I do not yet understand how. The goal is not to provide closure. The goal is to make progress.

    An Unexpected Possibility

    The most surprising realization is that a blog may be useful long before there is anything important to report. In fact, it may be most useful before that point.

    Instead of documenting finished ideas, it can help create them. A field note becomes a record of an investigation. A collection of field notes becomes a trail of reasoning. And occasionally, several observations converge into something larger. A hypothesis. A framework. Perhaps even a genuinely new idea.

    I used to think that blogs existed to share what we know. I am beginning to suspect that some blogs exist to help us discover it.

  • Practice Note: What If Testing Is Just a Form of Assessment?

    Over the past few weeks, while working on assessment models for QA capability and Data Quality, I stumbled upon an idea that has been difficult to shake off.

    The observation itself is surprisingly simple: the structure of a QA capability assessment and a system test is essentially the same. The only thing that changes is the object being assessed.

    At first, this felt like an interesting analogy. The more I thought about it, however, the more it began to feel like something more fundamental.

    Starting with System Testing

    Most of us who have worked in testing have been taught a familiar model:

    • Requirements define what the system should do.
    • Test cases verify those requirements.
    • Defects are reported.
    • A release decision is made.

    Nothing controversial there.

    But viewed through a different lens, the process can be described in another way:

    • Requirements define a reference model.
    • Testing is an assessment process.
    • Test results are evidence.
    • Defects are findings.
    • The test report is an evaluation.
    • The release recommendation is decision support.

    In other words, system testing can be described as a quality assessment of a software system. That may sound like a semantic distinction, but it has interesting consequences.

    Looking Beyond Testing

    Around the same time, I was working with assessment models for QA capability and Data Quality.

    Those assessments typically look like this:

    • Define a reference model.
    • Gather evidence through interviews, reviews and metrics.
    • Identify gaps.
    • Evaluate current capability.
    • Recommend improvements.

    Structurally, the process is identical. The only difference is that the object being assessed is no longer a software system. Instead of assessing a product, we assess:

    • A QA organization
    • A data platform
    • An operating model
    • A security posture
    • An architecture

    The pattern remains the same:

    Object → reference model → assessment activities → evidence → findings → evaluation → decision support

    Once you see it, it becomes difficult to unsee.

    Is QA Already Solving This?

    One could argue that Quality Assurance and later Quality Engineering have already attempted to broaden testing into something larger. There is certainly truth in that:

    Testing evolved from defect detection. QA expanded the focus toward process quality. Quality Engineering expanded it further toward prevention, automation and quality built into delivery. Yet even Quality Engineering remains largely anchored in the vocabulary of testing:

    • Test automation
    • Test coverage
    • Test strategy
    • Test management
    • Test environments

    The underlying mental model often remains:

    Software → testing → quality

    What if the model should instead be:

    Object → assessment → evidence → quality evaluation

    That is a subtle but important shift.

    A Different Perspective on Testing

    If assessment becomes the primary concept, testing becomes one assessment technique among many.

    Consider the following examples:

    ObjectAssessment Technique
    Source CodeUnit Testing
    Software SystemSystem Testing
    ArchitectureArchitecture Review
    Data PlatformData Profiling
    Security PosturePenetration Testing
    QA OrganizationInterviews and Document Review

    Different techniques, same assessment pattern.

    This perspective also changes the questions we ask.

    Instead of how many test cases have we executed, we ask: have we collected sufficient evidence?

    Instead of what is our test coverage, we ask: which quality attributes have been assessed?

    Instead of how many defects remain, we ask: what is our confidence level and residual risk?

    These are fundamentally different conversations. They are also conversations that executives tend to understand much better than traditional testing metrics.

    A Broader Quality Assessment Framework?

    Perhaps the most interesting implication is organizational rather than technical. Many consulting organizations offer services such as:

    • System testing
    • Data quality assessments
    • Security reviews
    • Architecture assessments
    • QA capability assessments

    These are often positioned as separate offerings with separate methodologies.

    But what if they are all instances of the same underlying discipline? A generic quality assessment framework could potentially provide:

    • A common assessment model
    • A common reference model structure
    • A common evidence model
    • A common reporting approach
    • A common maturity model

    The assessed object changes. The assessment pattern does not.

    An Open Question

    I do not yet know whether this idea is genuinely new or merely a reframing of concepts that already exist within Quality Engineering.

    What I do know is that it has changed the way I think about testing. For years, I viewed testing as a discipline concerned with finding defects.

    Today, I increasingly see testing as one technique for generating evidence about quality. That may sound like a small distinction. I suspect it is not.

    If the observation holds, then perhaps testing is not the overarching discipline after all. Perhaps quality assessment is. And testing is simply one of its most visible techniques.

  • Practice Note: Revisiting Quality

    For a long time, I have had a somewhat complicated relationship with the word “quality.” Like many people who started their careers in testing and QA, I gradually became uncomfortable with the label. Not because quality is unimportant, but because the term often seemed too narrow.

    When people hear “quality,” they frequently think about testing. When they hear “testing,” they often think about defects. And when they think about defects, the conversation quickly becomes operational rather than strategic.

    Over time, I found myself increasingly interested in topics that appeared to sit outside the traditional quality domain:

    • Architecture
    • Data
    • Governance
    • Operating models
    • Organizational capability
    • Decision-making

    These seemed like larger and more interesting questions. Or so I thought.

    An Unexpected Observation

    Recently, while working with different kinds of assessments, I started noticing a recurring pattern. The object being assessed varied considerably:

    • A software system
    • A data platform
    • An organizational capability
    • A process
    • An architecture

    Yet the assessment itself always seemed to follow the same structure.

    First, there was an idea of what “good” looked like. Then there was a way of collecting evidence. Then findings were identified. Finally, a judgment was made about fitness, capability, risk or readiness. The terminology changed, but the pattern did not.

    The Question Behind the Question

    At first, I thought I was moving away from quality. Now I am no longer sure. Perhaps I was not moving away from quality at all. Perhaps I was moving away from a narrow interpretation of quality. Traditional quality discussions often focus on products:

    • Does the software work?
    • Does it meet requirements?
    • How many defects remain?

    Important questions, certainly. But they are not the only quality questions.

    We also ask:

    • Is the architecture sustainable?
    • Is the data trustworthy?
    • Is the organization capable?
    • Is the process effective?
    • Is the operation resilient?

    These are quality questions too. We simply tend to classify them differently.

    Quality as Fitness for Purpose

    The more I think about it, the more useful the classic definition of quality becomes:

    Fitness for purpose.

    The phrase is deceptively simple. It does not limit quality to software. It does not limit quality to testing. It does not even limit quality to technology. Anything can be evaluated in terms of fitness for purpose:

    • A system.
    • A dataset.
    • A process.
    • An organization.
    • An operating model.
    • An architecture.

    The assessed object changes, but the underlying question remains remarkably consistent.

    Assessment as the Missing Link

    This realization led me to another thought: perhaps quality is not primarily about testing. Perhaps quality is primarily about assessment. Assessment is the mechanism through which we determine fitness for purpose.

    Testing is one assessment technique. Reviews are another. Interviews are another. Metrics analysis is another. Profiling is another.

    The specific techniques matter less than the purpose they serve. They generate evidence. That evidence supports an evaluation. That evaluation supports a decision.

    Viewed this way, testing becomes part of a much larger family of activities.

    A Wider Perspective

    Ironically, the more I tried to move away from quality, the more frequently I encountered it. Not the operational version of quality, but the broader version. The version concerned with evidence, confidence, risk and fitness for purpose. The version that appears whenever people need to make informed decisions about systems, data, organizations or processes.

    Perhaps quality is not a niche after all. Perhaps it only appears that way when viewed through the lens of testing.

    When viewed through the lens of assessment, quality seems to show up almost everywhere.

    An Open Thought

    I am not yet sure where this line of reasoning leads. It may turn out to be nothing more than a useful way of organizing ideas. Or it may suggest that testing, quality assurance, data quality, architecture reviews and capability assessments are all manifestations of the same underlying pattern. For now, I am content to leave that question open.

    What I find interesting is that an attempt to move beyond quality has unexpectedly led me back to it. Only this time, it looks much bigger than before.

  • Practice Note: Assessment Requires Two Forms of Expertise

    One of the most interesting observations from recent assessment work is that high-quality assessments rarely emerge from domain expertise alone. Nor do they emerge from assessment methodology alone.

    The best outcomes seem to arise from the combination of both.

    The Domain Expert

    Every assessment requires people who understand the subject being assessed. They understand the context, the technology the operational realities. They know where the complexity lives.

    Without this expertise, important signals are easily missed. Recommendations risk becoming generic. Conclusions risk becoming detached from reality. Domain expertise provides depth.

    The Assessment Expert

    At the same time, domain expertise alone is often insufficient. Understanding a system is not the same as assessing it. Assessment requires a different set of capabilities:

    • Structuring observations.
    • Evaluating evidence.
    • Identifying patterns.
    • Separating symptoms from root causes.
    • Testing assumptions.
    • Developing findings and recommendations.
    • Maintaining consistency and traceability.

    Assessment expertise provides structure.

    The Limitation of Either Role Alone

    A domain expert working alone may possess deep knowledge but struggle to transform observations into a coherent assessment. The result can become anecdotal, incomplete, or difficult to communicate.

    An assessment expert working alone may apply a rigorous methodology but lack sufficient understanding of the domain. The result can become superficial or disconnected from operational reality.

    Both forms of expertise are valuable. Neither is sufficient on its own.

    A Productive Tension

    What makes the combination powerful is the interaction between the two perspectives. The domain expert challenges the assessment model with reality. The assessment expert challenges the domain expert’s assumptions with evidence and structure.

    One contributes understanding. The other contributes evaluation.

    One asks:

    What is happening?

    The other asks:

    What does it mean?

    The dialogue between the two often produces insights that neither would have reached independently.

    Assessment as a Discipline

    This observation has broader implications. Many organizations treat assessments primarily as a domain activity. As a result, assessments are often led exclusively by subject matter experts.

    Yet assessment itself appears to be a professional discipline. Just as facilitation, coaching, architecture, and auditing require specific skills, assessment requires its own capabilities.

    Methodology matters.

    Evidence matters.

    Reasoning matters.

    Structure matters.

    A Working Hypothesis

    This leads me to a hypothesis:

    The quality of an assessment is determined not only by the quality of domain expertise, but by the quality of the interaction between domain expertise and assessment expertise.

    The strongest assessments do not emerge from either role alone. They emerge from collaboration between people who understand the system and people who understand how to assess it.

    Understanding provides insight. Assessment provides rigor. Both are required.

  • Practice Note: Reference Models and Assessment Models

    Recently, I noticed that two concepts are often discussed together but rarely separated clearly: reference models and assessment models.

    At first glance, they seem closely related. The more assessments I perform, however, the more convinced I become that they answer two fundamentally different questions.

    What Good Looks Like

    Whenever we assess something, we implicitly compare reality against a picture of what “good” looks like. In testing, this might include test strategy, test automation, defect management, governance and continuous improvement. In data quality, it might include ownership, controls, monitoring and remediation processes. In architecture, it might include standards, principles and governance.

    Before we can assess anything, we need a view of the desired state. That is the role of the reference model. A reference model describes the capabilities, practices and characteristics that define success in a particular domain.

    It answers the question:

    What does good look like?

    Understanding Reality

    Once we have defined the desired state, a second question emerges. Where are we today?

    This requires a different kind of model.

    • Interviews.
    • Workshops.
    • Evidence collection.
    • Observations.
    • Document reviews.
    • Scoring methods.
    • Analysis techniques.
    • This is the assessment model.

    The assessment model does not define excellence. Instead, it defines how we evaluate reality. It answers the question:

    How do we determine where we are today?

    The Same Structure Everywhere

    What fascinates me is how consistently this pattern appears, in testing, data quality, cybersecurity, agile maturity, organizational capability, leadership development. The domain changes. The structure remains remarkably similar:

    First, define what good looks like. Then assess the current state against that definition.

    Different objects, same underlying mechanism.

    Why the Distinction Matters

    Separating the two models turns out to be surprisingly useful. Without a reference model, assessment findings become subjective. Without an assessment model, the reference model remains theoretical.

    The two complement each other, but they should not be confused. In fact, many disagreements during assessments are not disagreements about findings at all. They are disagreements about one of the underlying models. Sometimes people disagree about what good looks like. Sometimes they disagree about the evidence. Separating the models makes those discussions much easier to navigate.

    A Broader Observation

    The more I think about it, the more I suspect this distinction extends beyond formal assessments. Every evaluation contains some form of reference model. Often it is implicit. Sometimes it is undocumented. Occasionally it is not even shared by the people involved. Yet it is usually there.

    Whenever we judge quality, maturity, effectiveness or success, we are comparing reality against some notion of what good looks like. The assessment simply makes that comparison explicit.

    An Open Reflection

    I used to think of assessments primarily as activities. A sequence of interviews, workshops and analyses.

    Increasingly, I see them as the interaction between two separate models: one model describing the desired state. Another model describing how we evaluate reality.

    The distinction feels obvious once noticed. Yet I find myself returning to it repeatedly. Perhaps because many discussions become clearer the moment the two are separated. And perhaps because the same pattern appears in far more places than I initially expected.