← Index

MEL Test Dashboard

I could not find a test-management tool that fit how we work, so I built and shipped one. Sole author, 95 commits.

Client
Codesage · EnAble India
Role
Sole designer, engineer and maintainer
Period
May 2026 — Present
commits — sole author
95commits — sole author
test cases served
1,028test cases served
Playwright automation scripts
207Playwright automation scripts
serverless function budget, met
12serverless function budget, met

Overview

Internal product · Serverless web app

Our test cases lived in Excel, our bugs lived in Jira, our evidence lived in a folder of screenshots, and nothing connected them. Answering “what is the state of this release?” meant reconciling three sources by hand. So I built one screen that unifies test cases, runs and Jira — with a Playwright watcher that picks up queued tests, executes them, and posts the results back on its own.

BuildExcel UAT workbookssource of truthPython buildworkbook → HTMLStatic dashboard pageno framework, no build serverServeEdge middlewaresigned-cookie gateServerless APIstatus · runs · Jira proxyUpstash Redisshared run statustest requestedExecuteQA queueanyone can request a testPlaywright watcherpolls · runs headlessRun + evidencesteps · screenshotsJiraREST APIresult posted back1,028 test cases served · 207 Playwright run scripts · the whole surface folded into a 12-function budget
From Excel workbook to executed run and back to Jira — the dashboard's full loop.

01

What it does

  • Serves every test case in the suite with live Pass / Fail / On Hold status, persisted to Redis so the whole team sees the same state on refresh.
  • Shows a run panel per execution: pointwise steps, expected versus observed, and pass/fail screenshots with element-level highlighting.
  • Embeds a Jira board — tasks and bugs by status and by date — with comments, status transitions, assignee changes and screenshot paste, all from inside the dashboard.
  • Runs a live QA queue: anyone can request a test, a Playwright watcher picks it up, executes it and posts the result back with evidence attached.
  • Carries a wireframe-versus-build Compare tab that walks every Master Data entity sub-view by sub-view.
  • Generates an analytics view that reacts to the selected date window.

02

How it is built

A Python build step reads the UAT workbooks and emits a single pre-built HTML page, so the dashboard has no client-side framework and no build server — it loads instantly. State and auth live in serverless functions behind edge middleware.

  • Python generator turns Excel UAT sheets into the dashboard page; re-run it whenever the workbook changes
  • Serverless API routes for auth, status, test cases, runs, test requests and the Jira proxy
  • Edge middleware gates every request on a signed cookie before anything renders
  • Upstash Redis holds status so it is shared, not per-browser
  • The Jira REST API is proxied server-side so no token ever reaches the client

03

A constraint I had to design around

The hosting plan caps a project at twelve serverless functions, and a naive route-per-endpoint layout blew past it. Rather than upgrade, I folded the attachment proxy into the Jira issue route and the watcher control into the test-requests route — collapsing the surface without losing a feature. The deployment has stayed inside the budget since.

04

Why it mattered

  • Release status became one URL instead of a manual reconciliation across three tools.
  • Evidence stopped going missing — screenshots attach to the run, and the run attaches to the ticket.
  • The suite grew from 833 to 1,021 cases in a single July import without the tooling straining.
  • Queued regression runs execute unattended and report themselves.

Stack

Runtime

  • Vercel serverless functions
  • Edge middleware
  • Node.js

Data

  • Upstash Redis
  • Excel workbooks as source of truth

Build

  • Python
  • Static HTML generation

Automation

  • Playwright
  • 207 run scripts
  • Headless watcher process

Integration

  • Jira REST API
  • Attachment proxy
  • Cookie auth