The test hub is one Playwright project for the applications Data & Business Solutions maintains. It exists because each application had been growing its own tests, the selectors were guesses, and a green run was not telling anyone the test had proved anything. This is how the hub went from an unrun scaffold to a scanner, a proof dashboard, and a request another team can make.
Principal Consultant
In the week of March 16 the consultant took a scaffold of about 31 tests, whose selectors were not mapped to any live page, and made it one hub with a shared sign-in, in its own repository.
The consultant also set the two standards the hub is judged by. A test that has never touched the application is a plan, not a result. And a run that goes quiet and never finishes is stopped, not passed.
In September the consultant looked at a hosted tool that already stores test cases and decided against it. That tool reports to engineers. What was wanted was proof that someone who does not write tests can open and read. That decision is why the proof dashboard exists.
Business Analyst
The analyst's job here was to say what proof means and where the gaps were.
By the week of September 21 the task tracker still said 100 tests and 10 projects. The hub was at 587 tests and 11 projects. A task list has no pass, no fail, and nowhere to put the screenshot, so it is the wrong place for a run. That gap became the dashboard's brief: read a hub run and say what the run proved.
In the week of October 12 the analyst wrote the request model. A team that builds something elsewhere, with no account on the machine that runs the hub, should be able to ask for an end-to-end test. It hands over the address, the code and the cases it already has. The hub writes what is missing, runs it, and writes a report back. The dashboard is the front door and the record. The hub is the engine. The dashboard does not run the tests.
PMO
The PMO's work shows in what was staged and what was written down as not done.
On October 2 the fix for the weak tests was approved in stages. Teach the checker about assertions that live in helpers. Rewrite the weak tests so a skipped condition is a failure. Delete a scaffold only after a real test already proves the same steps.
The PMO also kept the honest lines in the record. On April 3 a branch held 307 tests in 77 files and the pull request was opened, and the note says the new tests had not been watched running. On October 19 a plan to test a PDF export from the hub was approved the same day, and the note says the suite had not run. Neither line was polished out.
Developer
The developer built the scanner before anyone wrote more tests. It maps the pages of an application, and the first version only follows links. It does not press a button. The report is one HTML file, and a skill can draft a test from that map, which a person accepts or rejects before it stays.
On April 3 a second mode was added that does click. It opens tabs, search forms and rows, and it refuses any button that would change or delete data. Its first scan mapped 81 pages.
In the week of October 12 the developer wrote the hub side of the request model. The front door, the dashboard side, was not finished in that session.
Code Reviewer
The first commit of the hub was reviewed in the week of March 16. The review found issues. The high and medium ones were fixed the same day, and the follow-up review came back with none.
In the week of March 30, with 100 tests across 10 projects, a challenge wrote down the fact nobody had said aloud: none of the tests had been run against a live application. The selectors had been taken from reading the source. That finding is where the scanner came from.
QA
The dashboard's first real finding, in the week of September 28, was about the tests themselves. In one suite, 76 of 196 test declarations could come back green without proving anything: 30 were scaffolds, a list of comments where the test should be. 34 ran and asserted nothing. 12 had every assertion inside a condition, so a false condition passed by skipping the check.
On October 2 the count was re-derived and the tests were read. Some of the 76 were the checker being blunt, because an assertion lived in a helper the checker did not count. Some were real. The same check showed saved sessions for a different host than the one the run was aimed at, and applications that were timing out or answering with a redirect. A session file can look fine because the cookie names are right. The preflight now has to say which host those cookies belong to.
Still open
A passing test that never asserted anything is the bug still being closed. The request from another team has its hub side and not yet its front door. The PDF export plan was approved and the notes do not say its suite has run.