Skip to content
steelabs

03 /Test Automation

Test Framework Development

The architecture underneath an automated suite: how a test obtains data, how environments are configured, where the abstractions sit, what a failure reports, and which conventions everyone follows. This decides whether a suite is still being run once it is large, and it is the part most efforts skip in order to demonstrate a passing script sooner.

What you get

  • A framework skeleton with a working slice

    Project layout, configuration, fixtures and one journey running from end to end. An empty framework is an opinion; a framework with a real test through it is a proof.

  • A test data strategy

    How each test acquires the state it needs and returns it: fixtures, seeding through the API, or an isolated tenant per run. Shared hand-maintained data is the commonest reason a suite turns unreliable, and it cannot be corrected later without rewriting the tests.

  • Environment configuration

    One suite running against local, staging and CI by switching configuration instead of by editing code. A branch per environment is how a fix gets applied in two places and forgotten in the third.

  • Reporting and a triage path

    A report naming what broke, at which step, with the artefact attached, plus a written answer to who looks at a red run and by when. Reporting is not decoration; it determines whether anybody acts.

  • Written conventions and handover

    A short document covering naming, structure, and what belongs in a helper rather than in a test, followed by sessions where your engineers add tests under review. Conventions held only in the head of whoever started the suite leave when that person does.

How it runs

  1. 01

    Read what already exists

    We examine the current tests, the pipeline and the release rhythm before proposing any structure. Frameworks usually fail by having been designed for a team’s ambitions rather than for its actual cadence.

    You provide: Repository access, pipeline configuration, and an honest account of what gets ignored

  2. 02

    Decide the layers

    We settle what is verified through the interface, what through the service layer, and what belongs in unit tests your developers own. Most of the cost of a bad suite is checking things at the most expensive level available.

    We produce: A layering decision with the reasoning shown · An agreed test data approach

  3. 03

    Build the skeleton

    Structure, configuration, fixtures, reporting and a first journey wired into your pipeline. The slice stays deliberately narrow so the shape can be argued about while changing it is still cheap.

    We produce: Framework repository · A first journey running in your pipeline

  4. 04

    Transfer ownership

    Your engineers extend the framework while we review, until adding a test is routine rather than an event. We would rather leave behind a team that no longer needs us than a repository nobody dares touch.

    We produce: Conventions document · Onboarding sessions · Review notes on early contributions

Where this stops

  • Not a product of ours that you license. Every framework we build lives in your repository, in your language, with nothing to renew and no vendor lock behind it.
  • Not the suite itself. The framework is the structure plus a first journey through it; automating the rest of your flows is scoped separately, because the two pieces of work are very different sizes.
  • Not a guaranteed rescue of an existing suite. Where tests share state between themselves we will say that repairing them costs more than starting again, and show the working instead of simply quoting the larger job.
  • Not a substitute for developers writing unit tests. A framework at the browser level cannot compensate for a codebase with nothing underneath it, and attempting that is how a short suite becomes a long one.

Related reading

FAQ

Test Framework Development questions we hear often

Why not simply start writing tests?

Because the earliest tests set the conventions whether anyone intended them to or not. Data handling, waiting and locator style all get copied from whatever already exists, so a fortnight of unplanned scripts quietly becomes the architecture. Building the structure first is not ceremony: it is the difference between adding a test in an hour and giving up on adding it.

Can the framework live in our repository and our language?

That is the default, and we would argue against the alternative. A suite written in a language your engineers do not use daily gets maintained by nobody once the engagement ends, however elegant it looked at handover. If your team writes TypeScript, the framework is TypeScript. Any reason to differ needs to be one you can still defend a year from now.

When does a framework start being useful?

At the vertical slice, which is deliberately early. It covers one journey, so it catches one class of breakage, but it proves that the data approach, the pipeline and the reporting genuinely work together. Broad coverage then takes as long as the number of journeys demands, and we would rather add them in order of consequence than promise a date for all of them.

What if our developers want to own it from day one?

Good, and it changes how the work runs rather than whether it runs. We build the skeleton with your engineers present, review their first tests against the conventions, and hand over sooner. The failure mode worth watching is a framework designed by whoever was most enthusiastic and maintained by whoever remained; the conventions document exists to prevent exactly that.

Contact

Have a project in mind?

Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.

Start the conversationsales@steelabs.tech