Insights
Quality assurance
Testing as a discipline rather than a phase — what manual and exploratory work still catches that automation does not, how a regression suite earns its maintenance cost, and how to tell whether a QA function is producing confidence or producing tickets.
Where we stand
Most teams do not have a testing problem. They have a problem knowing what they have already checked, which looks identical from the outside and has a completely different remedy. Adding testers to a team that cannot say what its last release covered produces more activity and the same uncertainty.
So the first useful artefact is almost never a test. It is a written statement of what is expected to work, agreed by people who disagree about it right now and do not yet realise they disagree. Unclear intended behaviour can produce disputed findings; agreeing acceptance criteria makes the test evidence more useful.
We are sceptical of coverage as a target. A number that goes up when you add assertions to code nobody depends on is easy to move and tells you very little; the useful question is which failures would reach a customer, and whether anything in the pipeline would stop them. That question is harder and has no dashboard.
And quality is not a phase that happens after a build. Every part of it that can be pushed earlier gets cheaper: a requirement clarified in a conversation costs nothing, the same misunderstanding found in a release candidate costs a cycle. Not everything can move left, but almost everything that stays right costs more than it should.
Articles on Quality assurance
- What QA is included in development, and when to add independent testingDistinguish the checks needed to deliver an agreed build from broader independent QA, maintained automation and an OWASP security assessment.
- AI-assisted development: where speed meets engineering judgementA quicker first draft is useful. A quicker path to software you can trust needs small changes, human review and evidence that the important behaviour still works.
- How to write a bug report a developer can act onA defect report is a handover of an unfinished investigation. Most of them fail in the same three places, and none of the repairs involve a longer template.
- Diagnosing flaky tests: a procedure, not a retryA retry policy converts an unreliable suite into a slow one that sounds confident. Four families of flake, the tell that identifies each, and the order to work through them.
- Test data management: five strategies and what each one costsHow a test obtains the state it needs decides whether a suite survives parallel execution. Five approaches, the failure mode of each, and the problems nobody puts in the estimate.
- When to automate a test, and when the answer is noNot a philosophy of automation but a decision taken one case at a time. Five signals, four possible verdicts, and why "keep it manual" is not the losing option.
- In-house QA vs outsourced QA: how to decide which one you needThe comparison is rarely about the day rate. It is about hiring lead time, what happens between releases, and how much of your quality knowledge sits in one person’s head.
- Testing with production-like data without breaking GDPRRestoring the production database into staging is processing personal data. What that obliges you to do, why anonymised and pseudonymised are not interchangeable words, and what belongs in the test plan.
- Nearshore QA outsourcing in Poland: how engagements actually workWhat nearshore testing costs, why the time zone matters more than the day rate, and the questions worth asking before you sign anything.
- Manual testing vs test automation: which to invest in firstAutomation is not a more advanced form of manual testing. They answer different questions, and picking the wrong one first is an expensive way to learn that.
Contact
Have a project in mind?
Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.