Afreen Ahmed SFK

The work that defines my current scope

This one sits above my own teams. It is the shared baseline, scope definition and rollup that every engineering team's quality plan reports into — and the piece of work I'd point a hiring manager at first.

The control line is the argument

Most quality improvements are indistinguishable from detection getting worse. If externally-reported defects fall, it can mean the product improved — or it can mean the same bugs are now being caught somewhere else, or not filed at all.

The way to tell is the control. When I ran a targeted coverage programme against a product's highest-leakage modules, externally-reported defects fell sharply while internal detection stayed flat. The flat internal line is what makes the external fall a quality result rather than a reporting artifact.

I hold the same standard against my own results. That programme rolled out gradually rather than on a single date, so I rejected the binary before/after read of it — averaged across a ramp, it showed almost nothing. Measured as a monthly series, the separation between targeted and untargeted modules was unambiguous. The weaker method would have flattered the outcome, and it would still have been the wrong method.

Work I'd want to be judged on

What the quality metrics actually bought

Coverage percentages and defect counts are inputs. They only matter for what they let the business do differently, so this is the translation.

I rebuilt the function around agents

The recurring analysis load in a QE org this size — triage, categorisation, coverage review, release reporting — is enough to consume the function. Rather than staffing it, I built it. What began as prompts is now a source-controlled suite of agents and skills that runs the work on a schedule and publishes without me in the loop.

The coverage number is the one I'd point at. Canvas-based device interaction and Jetpack Compose surfaces had resisted automation for years — they were accepted as manual-only. Agent-generated coverage took them from nothing to 80%.

scheduled execution  ·  qe-agents

$ crontab -l -u qe-agents

# m   h   dom mon dow    job
  0   9    *   *   1-5    qe triage --daily --classify source,severity,component
  0  10    *   *   1-5    qe pr-coverage --watch --gate 'every PR, not a sample'
  1  18    *   *     5    qe analyse --weekly --publish wiki --next-target
  6  19    *   *     5    qe rca --refresh --restamp-as-of
  0  21    *   *   1-5    qe healthcheck --verify-delivery  # silence = healthy

These run whether or not I have the week. That is the point — the recurring analysis now happens at a consistent standard, and my attention goes to the judgement calls instead of the assembly.

I also made API automation agents a mandatory prerequisite for feature release across the engineering org — the point at which this stopped being my tooling and became the way the organisation ships.

How I build the function

My remit is the quality function rather than a team inside it: what gets measured, what gates a release, who is accountable, and what the organisation is allowed to call an improvement.

• I build organisations, not headcount. Grew this function from five engineers to twenty-one across web, mobile and API surfaces, and promoted five internally — three to SDET, one to Senior SDET, one to Lead SDET. I own the QE roadmap and hiring, and designed the subsquad model the org now uses for AI development work.
• I set policy at org level, not process at team level. I made API automation agents a mandatory prerequisite for feature release across the engineering organisation — not a recommendation my teams follow, a gate everyone ships through. The test design and automation playbook, the delivery quality framework, and an activity-level productivity model targeting a 50% efficiency lift are all adopted across product lines.
• I own the definition, not just the number. Where a measure is contested, I write what it means — what counts as externally-reported, what is out of scope, what a baseline has to satisfy before anyone is held to it. That is why I was able to tell leadership a committed target had to be re-baselined rather than reported against.
• I govern risk rather than escalate it. When scope outran coverage, I built the model — developer-to-QA ratio against named consequences, leakage, detection lag, a lost regression cycle — and put an explicit accept-or-reject in front of the decision-makers. Absorbing that quietly is how quality functions lose authority; forcing the choice is how they keep it.
• I represent quality outside engineering. Weekly portfolio-level review at VP level, and account-level quality reporting that turns QE telemetry into something enterprise customer leadership can act on. I flag declines in my own metrics before I am asked — a quality function that only reports good news has stopped being one.
• I grow the people who do the work. Recognition nominations written with the return spelled out, not the effort. An engagement survey turned into an owned action plan with named owners, where I took the items that were mine rather than routing them outward. When engineers move on, mentorship is what they write back to me about.

Rules I actually work by

Not values statements. Decision rules I've written down because each one came from getting something wrong first.

assertion run  ·  operating-principles.spec

$ qe lint --rules ./operating-principles.spec --reporter spec

  quality function · operating rules
    ✓ never infer health from a signal that can mask it
    ✓ permission bugs are never cosmetic
    ✓ classify by what broke, not where it surfaced
    ✓ an unvetted field is directional, never a target
    ✓ inventory coverage before prescribing more of it
    ✓ never trade edge coverage for a tidier suite
    ✓ disagree with the data, not the person

  7 passing (12 years)
  0 failing

# every rule was added after a failure.
# none has been removed.

Detail  ·  why each one exists

Where I think quality engineering goes next

I've now rebuilt one QE function around agents, at the point where that was still an argument rather than an assumption. This is what I took from it, and what I'd build against.

first ninety days  ·  Jenkinsfile

pipeline {
  agent { label 'quality-engineering' }

  stages {
    stage('Measure') {
      // nothing is promised until the number can be trusted
      steps {
        fix 'source attribution'
        fix 'work-category hygiene'
        publish definitions: 'what counts as leakage'
      }
    }
    stage('Baseline') {
      when { expression { instrumentation.isComparable() } }
      steps { snapshot cohort: 'clean', asOf: today() }
    }
    stage('Reduce') {
      steps { target modules: highestLeakage(7), control: true }
    }
  }

  post {
    always  { report includeDeclines: true }
    failure { escalate silently: false }
  }
}

What other people have said about the work

Self-assessment only goes so far, so this is the record other people made. The pattern I'd point to is that it holds across four employers and twelve years, not one company's culture.

Twelve years

Stage view

Detail