These are not Pepechura client projects; our team worked inside these companies’ own teams.
SaaS platform for the construction industry
Our team worked, from inside Subtraid’s own development team, on AI-assisted end-to-end test automation written with Playwright and TypeScript. The tests follow a page-object structure and run in the CI pipeline.
Playwright is an open-source browser automation tool from Microsoft. A test opens a real browser, signs in like a user, fills in forms, clicks buttons and checks that the expected result appears on screen. The same test can run on Chromium, Firefox and WebKit, the engine behind Safari. Because Playwright waits on its own for an element to be visible and clickable, it removes one of the main sources of tests that “sometimes pass, sometimes fail” from the start.
Trying to automate everything produces a test suite that costs more to maintain than it did to write. We keep automation for flows that repeat on every release and are expensive when they break. The first try of a new feature, exploratory testing that steps off the script and usability checks stay human work. In our projects a senior QA tests every release before it goes out; automation does not replace that check, it spares the QA from repeating the same steps every week.
| Good to automate | Better tested by hand | |
|---|---|---|
| Flow | Flows that stay the same on every release: sign-in, sign-up, payment, ordering, form submission | Features that are new and not yet settled |
| What is checked | That the record is created, the right role sees the right screen, the error message appears | Whether the text is clear and the layout comfortable |
| When | On every release and every merge, automatically | On the screens that changed, once per release |
| Method | A script written in advance, the same steps every time | Exploratory testing that tries unexpected use |
When a test sometimes passes and sometimes fails, the team soon stops looking at red results and the automation loses its value. To prevent that, we write tests with these rules from the start:
Our team applied these rules while working on Playwright-based test automation from inside Subtraid’s own development team: tests written in TypeScript, a structure that puts each screen into a page object, a setup that signs in once per user role and shares the session across tests, and a CI pipeline that runs a short critical set and the full suite separately. AI coding agents, given the test-architecture rules in writing, were used to help write the tests.
We write tests in the same language as the app itself; a mistyped selector or a missing parameter is caught before the test runs.
Each screen’s fields and buttons live in one class. When the interface changes, only that class is updated and the scenarios stay the same.
Tests run in a CI pipeline such as GitHub Actions or Bitbucket Pipelines, in Playwright’s official Docker image; a critical set gives fast feedback and the full suite runs in parallel steps.
Lets you replay every step of a failed test, its network requests and the screen at that moment, so the cause is found without guesswork.
To generate fresh, realistic test data on every run, so tests do not collide with each other’s data.
For repetitive work such as writing new scenarios and adding test IDs to the front end, we use agents that follow written architecture rules.
We talk about your app, how often you release and which flows you test by hand today.
We rank the flows that do the most damage when they break, and write down which roles and which environment (test or staging) they will run against.
Every week new tests are added to the CI pipeline. You see the report too, and we choose the next week’s flows together.
A senior QA tests the release before it goes out. We document how to run the tests, how to read the report and the rules for adding new ones.
We fix the bugs that surface in this period free of charge. After that, keeping the tests up to date as the interface changes can be part of monthly maintenance.
Timelines and budget ranges are published on our web application development and pricing pages; everything on this page follows the same figures.
Yes. Playwright does not care which technology the app is built with; it works with any web app that opens in a browser. If the front end has no stable test IDs, we add them along with the tests, which requires access to the source code.
Automatic waiting for elements, driving several browser engines through one interface, running tests in parallel and recording a trace of failed tests all come built in. That said, if your team already has a settled Cypress or Selenium suite, we would not suggest rewriting it just to switch tools.
Playwright is for the web: it can emulate mobile browsers’ screen sizes and touch behaviour, but it cannot drive a native app downloaded from the stores. If you have a mobile app, we discuss the right approach for it separately in the scoping call.
Yes. Automation checks that the flows we know about have not broken; finding out whether a new feature is designed right, or what happens under unexpected use, is human work. In our projects a senior QA tests every release before it goes out.
A perpetual licence to use the software and documentation. If you want the source code transferred to you, that is possible for an extra fee, stated separately in the quote.
Tell us which flows you test by hand today; in a free 30-minute scoping call we work out together which of them are worth automating.