Testclub is a process-led company. Everything we do runs via the same four-stage process, which can be applied to various areas or factors.
Everything we do is Business Logic Verification, and based in exploration and discovery. Heavily contingent on the context of your team, your application and its emerging properties. The defects we find are the territory scanners, automated tests and AI testing tools miss, because they sit deep in the specification gap.
| Discover | Specify | Interrogate | Report | |
|---|---|---|---|---|
| Functional | Learn the application's features and routes. | Write specification as executable tests — BDD, Gherkin, automation. | Exploratory testing. Execute tests, find defects. | Report findings. Report or dashboard. |
| Web security | Learn features and components. | Contextual recon of attack surfaces — upload points, entry paths. | Test for SSRF, access control, SQLi, file inclusion, XXE, JS injection, JWT forgery. | Report findings. Report or dashboard. |
| API security / penetration | List endpoints — OpenAPI/Swagger, across versions. | Map endpoints to features. Recon API attack surfaces. | Pen test endpoints — fuzzing, authorization, authentication, token attacks. | Report findings. Report or dashboard. |
| AI / LLM integration | List every LLM input source. Each ingested source is an attack surface. | Map inputs to outputs. Define what "good" looks like. Understand guardrails. | Test for RAG poisoning, prompt injection (direct and indirect), data leakage, output categorisation. | Report findings. Report or dashboard. |
Automated scanners test for known patterns: injection signatures, missing headers, exposed credentials. Useful for baseline hygiene but 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. Context is all.
# 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 WEB and API Security Top 10s as a starting framework, applying those to the specific logic and features of 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-assisted development is real and is a wonder! Code that used to take weeks now takes days. That's the productivity miracle everyone's talking about. But speed in the build phase doesn't mean speed everywhere. A pipeline only moves as fast as its slowest stage, and building was never the hard part. Specifying what "correct" really means, and then checking that the system actually does that, and only that, always was. AI raises the stakes on both.
So the work doesn't disappear. It shifts. Less time spent building, more time spent specifying what good looks like and proving the system delivers it. Every study on AI-assisted coding shows the same shape: gains in raw output, and a growing tail of review, QA and rework behind it. Speed up the middle of the pipeline and the ends carry more weight, not less.
This is what AI system testing is for. Not because AI is unreliable, often it's excellent. Because black-box, non-deterministic behaviour needs far more rigorous checking than code a human wrote and can explain, and most teams haven't adjusted their QA to match.
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% |
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.
You cannot test quality in. It has to be built in from the outset, starting with the first conversation about what a feature should do, not checked afterwards when it's already been built wrong. This is where Testclub started 25 years ago and it's still most of what we do. We take a vague requirement and turn it into acceptance criteria tight enough that a developer can build from it and a test can prove it. Specification and verification are two sides of the same concern.
We work with your team to specify features by example. Given, When, Then. One scenario, then another, until every case that matters is written down and nothing is left to assumption. Those scenarios are the specification and the test script at the same time. We then automate them. Playwright for browser tests, K6 for load and performance, BDD frameworks so results come back in plain English that a business reader can follow. Tests are delivered into your repo and CI pipeline. You run them, extend them, and own them.
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.
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.
Staging by default. Production only with written authorisation and agreed rules of engagement. Your data never leaves environments you control.
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.