Engineering Council Test Reliability Report

Scope aligned with Slack channel #dezvoltare, covering 2026-03-14 07:00 to 2026-03-21 07:00. 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

7
Daily Runs
4/7
Daily Green
19m 43s
Avg Daily Runtime
21
Smoke Attempts
12/21
Smoke Green
3m 21s
Avg Smoke Runtime
3m 03s
Median Smoke Time
2
Current Green Streak

Executive Analysis

Bottom line: release confidence is unstable in both the broad regression path and the deploy smoke path. The immediate job is to separate real product regressions from execution noise, then burn down the concentrated failure clusters.

What Matters

  • Daily regression passed 4 of 7 runs (57.1%), with a current green streak of 2 and a best streak of 2 in this window.
  • Smoke passed 12 of 21 attempts (57.1%) across 14 production pipelines. 1 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. 2 failed attempt(s) never reached test execution counts at all.
  • Failure concentration is not random: Frontend has the highest strict failure ratio at 0.68%, while Frontend has the broadest non-pass footprint at 0.68%.
  • University is the weakest smoke surface in this window at 0/4 green (0.0%).
  • Daily-suite runtime averaged 19m 43s, while observed daily test volume moved from 1,188 to 1,189.

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 Frontend are carrying the strongest signal, which means reliability work should be assigned by category ownership instead of treating the suite as one undifferentiated problem.

Recommended Actions

  • Split incomplete execution failures from real assertion failures in the report narrative. Setup breakage should stay visible, but it should not look identical to a product regression in the executive readout.
  • 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 Status0000103-1403-1603-1803-20
Daily Smoke Attempts0135703-1403-1603-1803-20
Daily Average Daily Suite Runtime19m 13s19m 40s20m 08s20m 36s21m 03s03-1403-1603-1803-20
Daily Average Smoke Runtime0m 00s1m 12s2m 24s3m 36s4m 48s03-1403-1603-1803-20
Daily Suite Total Test Growth (Recent 7 Runs)1188118811881188118903-1403-1603-1803-20
Smoke Suite Total Test Growth (Latest Run Per Day)
FrontendUniversity
0275582110Frontend 03-16: 110Frontend 03-17: 110Frontend 03-18: 110Frontend 03-20: 1University 03-18: 0University 03-20: 6003-1603-1703-1803-20

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
Billing7560000.00%0.00%0
Web52012000.04%0.04%2
Frontend175912000.68%0.68%3
Library6020000.00%0.00%0
CatFailF%NP%Tot
Billing
Pend 0Skip 0Runs 0
0
0.00%
0.00%
756
Web
Pend 0Skip 0Runs 2
2
0.04%
0.04%
5201
Frontend
Pend 0Skip 0Runs 3
12
0.68%
0.68%
1759
Library
Pend 0Skip 0Runs 0
0
0.00%
0.00%
602

Recent Runs

Recent Daily Suite Runs

DatePipelineSuitesStatusSummary
2026-03-14 18:22148497BillingWebFrontendLibraryPASSEDTotal 1188 | Passed 1188 | Failed 0
2026-03-15 18:23148499BillingWebFrontendLibraryPASSEDTotal 1188 | Passed 1188 | Failed 0
2026-03-16 18:23148604BillingWebFrontendLibraryFAILEDTotal 1188 | Passed 1187 | Failed 5
2026-03-17 18:22148823BillingWebFrontendLibraryFAILEDTotal 1188 | Passed 1188 | Failed 4
2026-03-18 18:22149034BillingWebFrontendLibraryFAILEDTotal 1188 | Passed 1187 | Failed 5
2026-03-19 18:24149182BillingWebFrontendLibraryPASSEDTotal 1189 | Passed 1189 | Failed 0
2026-03-20 18:22149392BillingWebFrontendLibraryPASSEDTotal 1189 | Passed 1189 | Failed 0
2026-03-14 18:22Pipeline 148497BillingWebFrontendLibrary
PASSED
T 1188 | P 1188 | F 0 | Pend 0
2026-03-15 18:23Pipeline 148499BillingWebFrontendLibrary
PASSED
T 1188 | P 1188 | F 0 | Pend 0
2026-03-16 18:23Pipeline 148604BillingWebFrontendLibrary
FAILED
T 1188 | P 1187 | F 5 | Pend 0
2026-03-17 18:22Pipeline 148823BillingWebFrontendLibrary
FAILED
T 1188 | P 1188 | F 4 | Pend 0
2026-03-18 18:22Pipeline 149034BillingWebFrontendLibrary
FAILED
T 1188 | P 1187 | F 5 | Pend 0
2026-03-19 18:24Pipeline 149182BillingWebFrontendLibrary
PASSED
T 1189 | P 1189 | F 0 | Pend 0
2026-03-20 18:22Pipeline 149392BillingWebFrontendLibrary
PASSED
T 1189 | P 1189 | F 0 | Pend 0

Recent Smoke Attempts

DateSuitePipelineJobStatusPassedFailedDuration
2026-03-16 21:17Frontend148625Frontend smokePASSED11003m 03s
2026-03-16 21:49Frontend148633Frontend smokePASSED11003m 02s
2026-03-16 22:08Frontend148635Frontend smokePASSED11002m 58s
2026-03-16 22:38Frontend148640Frontend smokePASSED11003m 00s
2026-03-16 22:59Frontend148644Frontend smokePASSED11002m 57s
2026-03-16 23:53Frontend148646Frontend smokePASSED11003m 00s
2026-03-17 00:06Frontend148648Frontend smokePASSED11003m 03s
2026-03-17 00:24Frontend148651Frontend smokePASSED11003m 03s
2026-03-17 12:06Frontend148704Frontend smokePASSED11003m 04s
2026-03-17 16:09Frontend148791Frontend smokePASSED11003m 04s
2026-03-17 16:56Frontend148817Frontend smokePASSED11003m 09s
2026-03-18 12:28University148817University smokeFAILEDn/an/a0m 02s
2026-03-18 12:28University148817University smokeFAILEDn/an/a0m 02s
2026-03-18 16:49Frontend149024Frontend smokePASSED11003m 10s
2026-03-20 13:16Frontend149311Frontend smokeFAILED042m 13s
2026-03-20 13:19Frontend149311Frontend smokeFAILED042m 06s
2026-03-20 13:30Frontend149311Frontend smokeFAILED042m 13s
2026-03-20 13:36University149311University smokeFAILED06021m 11s
2026-03-20 17:03Frontend149382Frontend smokeFAILED041m 26s
2026-03-20 17:06University149382University smokeFAILED5733m 38s
2026-03-20 17:13Frontend149382Frontend smokeFAILED010m 48s

Smoke Suite Breakdown

Frontend
17 attempts across 14 pipelines
71% green
Passed12
Failed5
Incomplete0
Avg runtime2m 40s
Median passing runtime3m 03s
Pipelines14
University
4 attempts across 3 pipelines
0% green
Passed0
Failed4
Incomplete2
Avg runtime6m 13s
Median passing runtimen/a
Pipelines3
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.