Engineering Council Test Reliability Report

Scope aligned with Slack channel #dezvoltare, covering 2026-05-16 07:00 to 2026-05-24 20:11. Metrics and timings are sourced from GitLab pipelines, jobs, and test-report artifacts for the daily 6 PM regression suite and the production smoke suite. Trend charts use daily buckets across this window.

Executive Snapshot

9
Daily Runs
2/9
Daily Green
21m 48s
Avg Daily Runtime
16
Smoke Attempts
14/16
Smoke Green
3m 14s
Avg Smoke Runtime
3m 09s
Median Smoke Time
1
Current Green Streak

Executive Analysis

Bottom line: the regression system is informative but not calm. The data suggest repeatable problem areas rather than random breakage, which means focused ownership should move the needle quickly.

What Matters

  • Daily regression passed 2 of 9 runs (22.2%), with a current green streak of 1 and a best streak of 1 in this window.
  • Smoke passed 14 of 16 attempts (87.5%) across 9 production pipelines. 2 pipeline(s) recovered on rerun, which is useful for continuity but also a sign that first-pass deploy signal is noisier than it should be.
  • Failure concentration is not random: Frontend has the highest strict failure ratio at 3.56%, while Billing has the broadest non-pass footprint at 11.21%.
  • University is the weakest smoke surface in this window at 4/5 green (80.0%).
  • Daily-suite runtime averaged 21m 48s.

Engineering Analysis

  • A release gate should fail loudly for product regressions and quietly for infrastructure noise. Rerun recoveries plus incomplete daily or smoke attempts suggest those two failure modes are still partially mixed together.
  • The failure profile is concentrated enough to act on. Frontend and Billing are carrying the strongest signal, which means reliability work should be assigned by category ownership instead of treating the suite as one undifferentiated problem.
  • The broader daily suite is carrying more instability than smoke, which usually means product regressions are escaping into wider coverage areas even when the narrow deploy gate looks acceptable.

Recommended Actions

  • Assign one owner to Frontend for the next cycle and expect a short written burn-down: top failing tests, suspected root causes, flake versus regression breakdown, and what gets fixed or quarantined first.
  • Treat the daily regression suite like an operations queue until it is calm again: triage failures after each red run, close known-noise items fast, and avoid letting multiple unrelated red signals pile up between runs.
  • Put University smoke under closer guardrails for the next release cycle. It is the best place to improve first-pass deploy confidence quickly.

Improvement Ideas

  • Introduce a small reliability budget for tests: every flaky or quarantined case needs an owner and an expiry, and the team should review that budget weekly the same way it reviews bugs or incidents.
  • Track first-fail to root-cause time as a core metric. Fast diagnosis is as important as raw pass rate because the practical value of a test gate depends on how quickly it helps the team recover.
  • Define a runtime budget per suite and require justification when test count or duration grows. Reliable feedback systems stay trusted when they remain both stable and proportionate.

Category Execution Ratios

How computed

Category total executions means the sum of that category's observed test executions across every daily-suite run in the selected window.

Strict Failure Ratio = failed executions for that category divided by total executions for that category across the window.

Non-pass Ratio = (failed + pending + skipped) executions for that category divided by total executions for that category across the window.

Example: if Billing executed 800 times across the week and 2 of those executions failed, Billing strict failure ratio is 0.25%. That does not mean 0.25% of pipelines failed; it means 0.25% of observed Billing executions ended in failed.

How computed

Category total executions means the sum of that category's observed test executions across every daily-suite run in the selected window.

Strict Failure Ratio = failed executions for that category divided by total executions for that category across the window.

Non-pass Ratio = (failed + pending + skipped) executions for that category divided by total executions for that category across the window.

Example: if Billing executed 800 times across the week and 2 of those executions failed, Billing strict failure ratio is 0.25%. That does not mean 0.25% of pipelines failed; it means 0.25% of observed Billing executions ended in failed.

Daily Daily Suite Status0000105-1605-1805-2005-2205-24
Daily Smoke Attempts0123505-1605-1805-2005-2205-24
Daily Average Daily Suite Runtime8m 20s12m 34s16m 48s21m 02s25m 17s05-1605-1805-2005-2205-24
Daily Average Smoke Runtime0m 00s1m 08s2m 16s3m 23s4m 31s05-1605-1805-2005-2205-24
Daily Suite Total Test Growth (Recent 9 Runs)1208121912311243125505-1605-1805-2005-2205-24
Smoke Suite Total Test Growth (Latest Run Per Day)
FrontendUniversity
60728597110Frontend 05-18: 110Frontend 05-19: 110Frontend 05-20: 110Frontend 05-21: 110Frontend 05-22: 110University 05-21: 60University 05-22: 6005-1805-1905-2005-2105-22

Category Aggregate Table

How computed

Category total executions means the sum of that category's observed test executions across every daily-suite run in the selected window.

Strict Failure Ratio = failed executions for that category divided by total executions for that category across the window.

Non-pass Ratio = (failed + pending + skipped) executions for that category divided by total executions for that category across the window.

Example: if Billing executed 800 times across the week and 2 of those executions failed, Billing strict failure ratio is 0.25%. That does not mean 0.25% of pipelines failed; it means 0.25% of observed Billing executions ended in failed.

How computed

Category total executions means the sum of that category's observed test executions across every daily-suite run in the selected window.

Strict Failure Ratio = failed executions for that category divided by total executions for that category across the window.

Non-pass Ratio = (failed + pending + skipped) executions for that category divided by total executions for that category across the window.

Example: if Billing executed 800 times across the week and 2 of those executions failed, Billing strict failure ratio is 0.25%. That does not mean 0.25% of pipelines failed; it means 0.25% of observed Billing executions ended in failed.

CategoryTotalFailedPendingSkippedFailure RatioNon-pass RatioRuns With Failures
Billing972110981.13%11.21%2
Web702013906411.98%11.11%1
Frontend23888501693.56%10.64%6
Library774230632.97%11.11%1
CatFailF%NP%Tot
Billing
Pend 0Skip 98Runs 2
11
1.13%
11.21%
972
Web
Pend 0Skip 641Runs 1
139
1.98%
11.11%
7020
Frontend
Pend 0Skip 169Runs 6
85
3.56%
10.64%
2388
Library
Pend 0Skip 63Runs 1
23
2.97%
11.11%
774

Recent Runs

Recent Daily Suite Runs

DatePipelineSuitesStatusSummary
2026-05-17 18:27156183BillingWebFrontendLibraryFAILEDTotal 1255 | Passed 1252 | Failed 3
2026-05-18 18:26156473BillingWebFrontendLibraryFAILEDTotal 1255 | Passed 1250 | Failed 5
2026-05-19 18:28156720BillingWebFrontendLibraryFAILEDTotal 1255 | Passed 1250 | Failed 5
2026-05-20 18:28156907BillingWebFrontendLibraryFAILEDTotal 1255 | Passed 1252 | Failed 3
2026-05-21 18:24157062BillingWebFrontendLibraryPASSEDTotal 1208 | Passed 1208 | Failed 0
2026-05-22 18:11157199BillingWebFrontendLibraryFAILEDTotal 1208 | Passed 0 | Failed 237
2026-05-23 18:24157201BillingWebFrontendLibraryFAILEDTotal 1208 | Passed 1207 | Failed 1
2026-05-24 18:25157212BillingWebFrontendLibraryPASSEDTotal 1255 | Passed 1255 | Failed 0
2026-05-17 18:27Pipeline 156183BillingWebFrontendLibrary
FAILED
T 1255 | P 1252 | F 3 | Pend 0
2026-05-18 18:26Pipeline 156473BillingWebFrontendLibrary
FAILED
T 1255 | P 1250 | F 5 | Pend 0
2026-05-19 18:28Pipeline 156720BillingWebFrontendLibrary
FAILED
T 1255 | P 1250 | F 5 | Pend 0
2026-05-20 18:28Pipeline 156907BillingWebFrontendLibrary
FAILED
T 1255 | P 1252 | F 3 | Pend 0
2026-05-21 18:24Pipeline 157062BillingWebFrontendLibrary
PASSED
T 1208 | P 1208 | F 0 | Pend 0
2026-05-22 18:11Pipeline 157199BillingWebFrontendLibrary
FAILED
T 1208 | P 0 | F 237 | Pend 0
2026-05-23 18:24Pipeline 157201BillingWebFrontendLibrary
FAILED
T 1208 | P 1207 | F 1 | Pend 0
2026-05-24 18:25Pipeline 157212BillingWebFrontendLibrary
PASSED
T 1255 | P 1255 | F 0 | Pend 0

Recent Smoke Attempts

DateSuitePipelineJobStatusPassedFailedDuration
2026-05-18 15:02Frontend156306Frontend smokePASSED11003m 08s
2026-05-18 17:08Frontend156455Frontend smokePASSED11003m 12s
2026-05-18 22:21Frontend156479Frontend smokePASSED11003m 09s
2026-05-18 23:10Frontend156481Frontend smokePASSED11003m 20s
2026-05-19 12:54Frontend156608Frontend smokeFAILED8015m 01s
2026-05-19 12:59Frontend156608Frontend smokePASSED11004m 02s
2026-05-20 23:05Frontend156608Frontend smokePASSED11003m 31s
2026-05-21 14:43University157003University smokePASSED6002m 13s
2026-05-21 14:50Frontend157003Frontend smokePASSED11003m 49s
2026-05-21 16:13University157030University smokePASSED6002m 13s
2026-05-21 16:19Frontend157030Frontend smokePASSED11003m 06s
2026-05-22 15:37University157139University smokePASSED6002m 10s
2026-05-22 15:41Frontend157139Frontend smokePASSED11003m 08s
2026-05-22 16:56University157198University smokeFAILED5913m 22s
2026-05-22 16:56Frontend157198Frontend smokePASSED11003m 53s
2026-05-22 16:59University157198University smokePASSED6002m 25s

Smoke Suite Breakdown

Frontend
11 attempts across 9 pipelines
91% green
Passed10
Failed1
Incomplete0
Avg runtime3m 34s
Median passing runtime3m 16s
Pipelines9
University
5 attempts across 4 pipelines
80% green
Passed4
Failed1
Incomplete0
Avg runtime2m 28s
Median passing runtime2m 13s
Pipelines4
Generated from GitLab project adservio/helm2. Times are shown in Europe/Bucharest. Daily-suite runtime is measured from GitLab pipeline and job timestamps. Category counts come from GitLab test-report JSON artifacts, with job-trace fallback when older artifacts have expired.