Pacia Intelligence

For QA & Test Leads

Show that testing is the constraint, not the cause.

QA usually gets measured by the bugs it finds and blamed for the time it takes. Pacia puts test flow on the same footing as delivery flow — stages, wait times, regression load and escaped defects — so the conversation moves from "QA is slow" to "here is where work is queuing, and why".

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

Defect types and resolutions come from your Jira site, confirmed by a human.

Most tools treat Jira as planning data and stop at the board

Engineering analytics platforms generally read Jira for sprint and epic reporting and ignore everything that happens after a story is marked done-ish. The result is that test time is invisible, regression load is invisible, and the only QA number that surfaces anywhere is a defect count with no denominator.

Pacia models the QA stages explicitly, and shares that model with the sprint and epic views. Planned, unplanned, delivered, carried out and hit rate mean the same thing on a QA screen as they do on a sprint screen, because they are the same readers underneath. A story that failed test and went back to development reads identically wherever you look at it.

Just as importantly, none of it is guessed. On the first Jira site we connected, "Defect" turned out to be an Xray link type rather than an issue type; the real defect types were Bug and Bug (sub-task), and the genuine not-a-defect resolution was Irreproducible. Every one of those is discovered from your site and confirmed by a person before any rule uses it. An unmapped rule stays inert and says so, rather than matching everything and producing a confident, wrong number.

Show where test work is waiting

Stage counts and wait times distinguish work waiting to enter test from work that failed and returned. A raw bug count cannot show either queue.

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.

What you can finally show

  • Where work is queuing, not just how much you found

    The QA pipeline as stages with counts and wait times: waiting to enter test, in test, failed and returned, ready to release. The stage that is backed up is the one to argue about.

  • Regression load as a rate, not a raw count

    Regressions raised against work delivered, per team and per sprint, using your site’s own defect issue types and link types. A raw bug count rises whenever throughput rises; a rate does not.

  • Escaped defects, traced back

    Defects that reached production, linked to the work that introduced them and to change failure rate, so the quality conversation and the DORA conversation are the same conversation.

  • Story-level detail when someone challenges a number

    Every QA figure drills to the individual stories behind it, with their stage history. Story detail refreshes from Jira on a 60-second freshness window, so the drill-down is current when you are being questioned in a meeting.

  • A seat that costs nothing

    QA colleagues are viewers under Pacia’s pricing model. Your whole test function reads the platform free, because billing counts only people authoring or reviewing code.

Where this lives in Pacia

Common questions

Do I have to change how our Jira is set up?

No. Pacia adapts to your configuration rather than the other way round. It reads your site’s issue types, link types, statuses and resolutions, proposes a mapping, and asks a person to confirm it. Epics are identified by Jira’s own hierarchy level rather than by an issue type called "Epic", for the same reason.

What happens to metrics we have not mapped yet?

They show as unconfigured. Pacia will not treat an empty defect-type list as "match everything" — the rule stays inert and the interface says so. It is a deliberate choice: an obviously missing number gets fixed, a plausible wrong one gets quoted in a board meeting.

Does this work with Xray or Zephyr?

Pacia reads the Jira issues, links and changelogs that those add-ons write, which is how it handles Xray link types correctly. It does not connect to their APIs directly, so test-execution detail that lives only inside the add-on is not pulled through.

Do QA users count towards the licence?

Only if they author or review code during the billing window. A QA lead who reads the platform daily and does not commit code is a free, unlimited viewer.

See it against your own delivery data

Connect one repository and judge it on your own history rather than a demo dataset. Guided onboarding is included on every paid plan.

Talk to us