ATPL

Services · Design and quality

Find the problem before your customer does.

For teams releasing software without a tester. We test releases on real devices and real data, automate the checks that matter, and tell you plainly whether it is ready.

125+
Restaurants and cafés on Ethos
16
Years building technology
Brief a releaseTalk engineering

No tester

Shipping without a tester

Customers find the bug that a checklist would have caught in an afternoon.

Brief a release

  • Break

    Every release fixes one thing and breaks another, and customers find out first.

  • Laptop

    The site works on the developer’s laptop and fails on the customer’s phone.

  • Month-end

    Nobody has tested what happens at month-end, under load, or with a bad internet connection.

How it ships

Risk first, then cases

We list what can hurt the business, then write cases around that — not around every button.

  1. case/01

    Understand

    We read the application and its history of incidents, then write a test plan covering what has actually broken and what must never.

  2. case/02

    Design

    The plan names which checks are manual, which are automated and which run on every release, with the devices and browsers listed.

  3. case/03

    Build

    The first full test pass happens on a staging environment, and the automated suite is added to your pipeline.

  4. case/04

    Stay

    Each release gets a test pass and a short report; the automated suite grows with the application under a monthly arrangement.

Go or no-go

Plans, devices and the go / no-go

We test on real phones and real data, then say plainly whether it is ready.

  • Regression automation

    The checks that must pass every time written as automated tests and run in the pipeline, so a fix cannot silently break billing.

  • Load and failure testing

    Traffic peaks, slow connections and a dead third-party API rehearsed before launch, not discovered during a campaign.

  • Data and billing checks

    GST rounding, totals, stock movements and reports verified against known figures, because a wrong invoice costs more than a wrong colour.

  • Bug reports a developer can act on

    Steps, device, screenshots and expected result for every defect, tracked to closure.

Primary deliverable

Ships with the engagement

Live brief

01 · Lead outcome

Release testing

Each release checked against a written test plan on real browsers and handsets, with a go or no-go you can rely on.

  • 01Regression automation
  • 02Load and failure testing
  • 03Data and billing checks
  • 04Bug reports a developer can act on

How we work

Testing is part of every ATPL build, and a release of Ethos reaches 125+ restaurants and cafés, which is where the habit comes from; this page describes that method for other teams’ software until a client engagement can be named.

    Chosen for the job

    Node.js · Python · React · Laravel

    Decide the shape

    QA scope and cost

    Manual vs automated, device coverage, and what ready means in writing.

    Software quality assurance is the planned testing of an application before and after release: functional checks, regression tests, device and browser coverage, load tests and data verification. ATPL runs it on staging environments with real data and reports plainly whether a release is ready.

    You need automation for the few things that must never break, such as login, checkout or billing totals; everything else can be tested by hand per release. ATPL automates that core first and adds to it only where a bug has actually recurred.

    Yes. ATPL writes a test plan from the application and its incident history, runs the first full pass on a staging environment and reports defects a developer can act on; the other company keeps building while ATPL keeps checking.

    A one-off release test from ATPL is quoted per application size, typically a few days of work; ongoing QA with an automated suite is a monthly arrangement sized to how often you release. Writing the automated core is a one-time cost.

    Continue to