Skip to main content

Quality and testing

Testers who find problems early and establish a process that continues to find them.

Effective testing is a set of practices the whole team shares, not a phase at the end of a sprint. Our testers join your team, test the work in progress and build the automation and process that allow you to release with confidence. Over time your developers consider testing earlier in their work, and fewer defects are reported by customers.

What your team gains

In many growing teams, testing happens in the last days of a sprint if time allows. Regression checks rely on someone working through the application from memory, and problems in a release are often discovered through customer support.

Our testers improve this progressively. They become involved when a story is written and ask about edge cases before development begins. They automate the checks that were previously run by hand for every release, and they write defect reports that are easy to reproduce, so that developers spend their time fixing problems rather than investigating them.

  • Clear acceptance criteria agreed before work starts
  • Automated regression tests that run on every change
  • Defect reports a developer can act on quickly
  • A test approach your team understands and maintains
  • Fewer problems discovered after a release

Combining manual and automated testing

We value test automation, but we apply it selectively. Some checks are inexpensive to automate and tedious to repeat by hand, such as validating every field on a large form with each build. Others, such as whether a new screen is clear to the people using it, require human judgement.

Our testers determine which approach suits each part of your product. They usually begin with the flows that matter most to the business, such as sign-up, payment and the core tasks your customers perform daily, and extend coverage from there. The aim is a test suite your team trusts. Tests that fail unpredictably tend to be ignored, and an ignored suite provides no protection.

A QA process suited to a smaller team

Large organisations can support a separate QA department with formal sign-off stages. Most of our clients do not have that structure and are better served without it. We help you establish a process in which quality is part of how the team works, rather than a queue at the end of each sprint.

Depending on your team, that may involve a short definition of done that includes testing, developers writing unit tests while testers concentrate on integration and exploratory testing, or a brief defect triage held twice a week. We recommend what suits your size and leave out what does not.

Throughout, our testers work closely with your developers. They attend your stand-ups, read your pull requests and speak with the development team daily, rather than operating as a separate group that reports defects from a distance. They use your tools, keep your hours and are available to you directly.

Frequently asked questions

We have no automated tests. Where should we start?

With the flows that would cause the most harm if they failed. Our tester will identify these with you in the first few weeks and automate them first. You will have useful coverage well before you have complete coverage, which is the right order.

Can one tester support several developers?

Often, yes, particularly once the core automation is in place and developers are writing their own unit tests. We will tell you if the workload becomes too much for one person.

Do your testers write code?

Our test automation engineers do. They write and maintain automated tests in your repositories, alongside your application code, and those tests are reviewed like any other change.

Will you use our existing test tools?

If they are working well, yes. If they are the reason the tests are not being run, we will say so and propose a simpler alternative. The decision remains yours.