Pacia Intelligence

Platform

QA measured as flow, not as a bug count.

A raw defect count rises whenever throughput rises, which makes it useless as a quality signal and unfair as a QA metric. Pacia models the test pipeline as stages with counts and wait times, reports regressions as a rate, and traces escaped defects back to the work that produced them.

Talk to us
QA pipeline — current sprint
Waiting to enter test
9 stories
In test
14 stories
Failed, returned to development
4 stories
Regressions raised
11
Escaped to production
2

What the QA views cover

  • QA overview

    The current state of test across every team, in the same planned/unplanned/delivered vocabulary the sprint views use.

  • QA pipeline

    Stage-by-stage flow with counts and wait times, so you can point at the stage that is backed up.

  • QA signals

    Leading indicators — regression rate, failure-and-return rate, stories sitting in test too long.

  • QA insights & explore

    Trend analysis with a drill-down that lets you slice the whole set rather than the visible page.

  • Story detail

    One story’s full stage history. Refreshed from Jira on a 60-second freshness window, so the drill-down is current when you are being challenged.

  • QA My Day

    A personal queue for testers — what has arrived for test, what has come back, what is waiting on them.

Stages with wait times, not a defect total

A raw bug count rises whenever throughput rises, which makes it useless as a quality signal and unfair as a QA metric. Modelling test as flow gives you somewhere to point.

The test pipeline as flow, not as a bug count

  1. 9Ready for test
  2. 14In test
  3. 4Failed, returned
  4. 7Ready to release

Nine stories waiting to enter test and four that failed and went back are two very different problems, and a defect count shows neither. The stage that is backed up is the one worth arguing about.

Why the mapping step matters

Every Jira site has its own vocabulary, and guessing at it is not a small inaccuracy — it silently changes the number.

  • "Defect" is not always an issue type

    On the first site we connected it was an Xray link type. The genuine defect issue types were Bug and Bug (sub-task). A tool that matched on the word "Defect" would have reported a defect rate of zero, confidently.

  • Not every resolution means a real defect

    The same site’s genuine not-a-defect resolution was Irreproducible. Excluded resolutions are configured per project, because no two sites agree on this.

  • Empty means not configured, never "match everything"

    An unmapped rule stays inert and the interface shows the unconfigured state rather than rendering a zero. This is the single most important rule in the QA model.

  • Confirmed by a person, not inferred

    Pacia discovers the candidate issue types, link types and resolutions from your site and proposes a mapping. Somebody who knows your process confirms it before any metric uses it.

  • Shared readers with sprints and epics

    QA stage resolution and regression reading are the same services the sprint and epic views use, which is why a story reads identically on every screen instead of differing by a stage or two.

Common questions

Does this integrate with Xray or Zephyr directly?

Not through their own APIs. Pacia reads the Jira issues, links and changelogs those add-ons write, which is how it handles Xray link types correctly. Test-execution detail held only inside the add-on is not pulled through.

What if our QA process does not look like a pipeline?

The stages come from your own Jira statuses, mapped to phases during setup. If your process has six stages or two, that is what is modelled.

Do QA users need a paid seat?

No. Billing counts people who authored or reviewed code. Testers who do not commit are free, unlimited viewers.

Put test flow next to delivery flow

Talk to us