Testing and QA

What this does

Brain-Stem writes your tests, runs them as part of delivery, and keeps them current as the software changes.

Each test is written from a requirement, not read back off the code it tests. So we are always working from your list of requirements. The ones that never get a test show up while we work.

Where it starts

We work against your repository as it is. You prepare nothing, and the first tests run against the code you already have.

What it writes

• Unit tests. Each function and component is checked in isolation.
• Smoke tests. A short suite decides whether a build is worth testing further.
• Integration tests. Whole paths across services are exercised, including system integration testing.
• API and contract tests. Each service is checked against the interface it publishes, so a change that breaks a consumer is caught where it is made.
• End-to-end tests. Real user journeys are driven through the interface, the way your customers will.
• Regression tests. The suite grows every time something breaks, so the same fault cannot return unnoticed.
• Performance and load tests. The system is put under the traffic you expect and well past it, to find where it bends.
• Accessibility tests. The interface is checked against WCAG 2.2 AA on every change, not in an audit once a year.
• Exploratory runs. Unscripted, randomised input is driven at the application to find what the written tests miss.

Each test is code. It goes through the review your own code goes through, and it lands in your repository, where your team can read it, change it or delete it.

How it runs them

The tests for a change run when the change is made, before it reaches anyone else. If one fails, the change stops there, while the person who wrote it still has the code open. Nothing waits for a later test cycle.

How it keeps them current

Suites rot. A test written once starts drifting the moment the code moves, and a test that has quietly stopped asserting looks exactly like one that passes.

When a requirement or the code behind it changes, we ensure the tests covering it change too. This ensures nothing decays between releases.

What nothing covers

Every test is joined to the requirement it verifies, so the requirements with no test at all can be listed. They are flagged by name.

Code coverage does not answer this. Line and branch coverage reports how much of your code ran, so it counts code rather than requirements. A file can be well covered and still hold a requirement that nothing checks.