Everything Testclub does is the same skill pointed at a different target: understand how a system is supposed to work, then think clearly about how it doesn't. API logic, AI behaviour, or the test suite that guards both.
Automated scanners test for known patterns: injection signatures, missing headers, exposed credentials. Useful for baseline hygiene. Useless for business logic. Can a user reach another user's data by changing an ID? Can a payment be submitted twice under concurrent requests? Can a privilege be escalated by replaying a modified JWT? These are logic questions, not signature questions. No tool can answer them without understanding what the system is supposed to do.
# BOLA: accessing another user's account data GET /api/v2/accounts/1045 Authorization: Bearer eyJhbG...user_1044 200 OK { "account_id": 1045, "balance": "£142,800.00" } # Same request after remediation 403 Forbidden { "error": "insufficient_permissions" } # No scanner tests for this. It requires understanding # that the token and the resource should match.
We test against the OWASP API Security Top 10 as a starting framework, then into the logic specific to your system: BOLA, broken authentication, mass assignment, SSRF, race conditions in payment and state-change flows, chained privilege escalation, JWT implementation flaws, GraphQL abuse. Burp Suite Pro plus manual testing against real attack scenarios. Where useful, K6 load testing in the same engagement: a rate limit that can be bypassed is both a performance risk and a vulnerability.
You get: a report with full reproduction steps, business impact, and a prioritised fix for every finding, what to change, in what order, and why, walked through with your engineers. Typical engagement: two to four weeks.
AI accelerates the build phase. Code gets written faster, content gets generated faster, workflows get automated faster. But building was never the bottleneck. Specification and verification were. And AI makes both harder.
When AI writes your code, you have more output to verify, produced by something that doesn't explain its reasoning. When AI handles a business process, you know even less than you did before about what it did and how it did it. The faster you build, the more you need to test.
As AI accelerates the build phase, the work shifts to both ends of the barbell: better specification upfront, better testing afterwards. The total effort doesn't shrink. It moves. The time you save generating, you spend again verifying.
This is why AI system testing exists as a discipline. Not because AI is unreliable. Because AI is brilliant, fast, and opaque, and the faster it moves, the more rigorous the verification needs to be.
For any regulated or high-stakes deployment, you need the failure rate empirically, before you go live. Not the vendor's benchmark. Yours. Tested in your environment, against your data, on your tasks.
The method is black-box testing applied to non-deterministic systems. Define the inputs. Define what correct looks like. Run at scale. Record pass and fail. Characterise the failure patterns. The AI-specific challenge is the oracle problem, deciding what "correct" means when outputs vary, which we handle through structured output evaluation, LLM-as-judge protocols, and human review sampling.
| Task category | Runs | Pass | Fail | Rate |
|---|---|---|---|---|
| Contract clause extraction | 500 | 471 | 29 | 94.2% |
| Risk flag classification | 500 | 443 | 57 | 88.6% |
| Multi-step reasoning | 200 | 154 | 46 | 77.0% |
| Numerical extraction | 500 | 489 | 11 | 97.8% |
| Edge case handling | 300 | 201 | 99 | 67.0% |
Illustrative output format. Actual results vary by deployment.
If you operate under the EU AI Act, fully applicable from August 2026, or DORA, the evidence question is no longer optional: both ask you to show how your systems behave under test, not how the vendor's benchmark behaved. This work produces that evidence.
You get: failure rates by task category with confidence intervals, characterised failure modes (hallucination, silent omission, misclassification, compounding), and recommendations for guardrails, monitoring and human-in-the-loop design, written for your CISO or Head of Risk, not just your engineers. Typical engagement: two to four weeks.
A test that checks a button exists is noise. A test that verifies a payment can't be processed twice under concurrent requests is specification made executable. We build automated suites that encode real specification and deliver them into your repo and CI pipeline, yours to run, extend and own.
Playwright for end-to-end browser testing. K6 for load and performance: bottlenecks, breaking points, capacity baselines. BDD frameworks for specification by example, business rules turned into executable tests that serve as both documentation and regression suite. This is where Testclub started, and it's still how many of our clients first knew us.
Scope. Every engagement starts with a short scoping note: what we'll test, how long it takes, what we need from you. Fixed scope, no drift.
What we need. API documentation or specs (their absence is itself a finding), a staging environment, and test accounts. We work under your NDA from the first call.
Safe testing. Staging by default. Production only with written authorisation and agreed rules of engagement. Your data never leaves environments you control.
Credentials. Testclub's work is logic-focused security testing. It complements an accredited penetration test, it doesn't replace one. If compliance requires CREST-accredited scanning, keep it; we find what it structurally can't.
Insurance. Professional indemnity insured. Happy to share details on request.
A 30-minute conversation about your system will tell you.