Gatling specialists for your dedicated team.

Where Gatling fits in a long-term product team.

Scenarios as code is the property that keeps Gatling suites alive. They live in the repository, they are reviewed like any other change, and they refactor properly. That is a real advantage over tools whose test plans are XML files that are hard to diff.

Its asynchronous engine generates much more load per machine than thread-per-user tools, which matters for cost and accuracy: fewer machines means less chance the generator becomes the constraint. The trade-off is a JVM language requirement that not every team has.

What your dedicated team does with Gatling.

Performance work is most effective when the same people own the scenarios and interpret the results. Handing a report to a team that did not design the test produces numbers without the context needed to act on them.

That is why load testing works best as ongoing capacity through outsource qa testing.

Common Gatling use cases.

• Scenarios reviewed like application code Load tests in the repository, refactored and diffed like any other code.
• High load from modest infrastructure Efficient generation, so the test measures the system.
• Reports detailed enough to act on Percentile distributions over time that show where a system degrades, as well as when.

Adding Gatling skills to your team.

Load scenarios are version-controlled alongside the application, and the people who design them interpret the results. How that responsibility is framed is set out in how an assignment runs.

You can add Gatling capacity as one dedicated specialist or as part of a wider remote team, managed by a service delivery manager from our offices in Thailand. Companies hire dedicated developers this way under one agreement and one monthly fee.