Requirements review
User stories and specifications are read critically so that conflicts surface while they still live on paper, which is when they cost least to resolve.
Your software has to work on the happy path shown in a sales demo and on every detour real people take. Catching a fault during QA is far cheaper than hearing about it from a customer on the phone, so we test for the detours too.
Individual bug finds matter less than you might think. The lasting asset is a growing library of cases that gets replayed on every new version.
User stories and specifications are read critically so that conflicts surface while they still live on paper, which is when they cost least to resolve.
Checks with a stated expected outcome, reusable by us, by your in-house staff or as input for automation later on.
Core journeys, edge values and deliberately bad input, for instance a CVR number with seven digits or a street name spelt with æ, ø and å.
Confirming that this sprint's changes left last sprint's features intact. Old bugs love to come back here.
Steps, environment, test data and expected result, filed directly in your Jira, Azure DevOps or GitHub so nobody has to play detective.
A summary of coverage, of what fell outside it, and of the risk you take on by shipping.
Cycle one is the slowest because the library is being written from nothing. From then on, runs speed up markedly. All work happens remotely against your test or staging environment.
We learn how the product works and which parts the business simply cannot afford to break.
Scope and limits. Exhaustive testing is impossible, so risk decides the order.
Cases are worked through, findings logged, and fixed items retested.
A go or no-go recommendation listing untested areas and any risk still open.
Bugs with no reproduction steps end up closed as »cannot reproduce«. A ticket saying »checkout is broken« can ping-pong around a team for weeks. Precise steps, data, browser and environment turn that into a fix within days.
Developers naturally walk the route they designed and cannot see their own blind spots. A separate tester deliberately goes off-route: nonsense input, a lost connection, someone hammering the pay button twice.
As a rule of thumb, 25 to 35 per cent of development effort. With less, only core journeys are covered and some bugs slip through to users. That trade-off can be perfectly reasonable if it is a conscious one.
Gladly, and it is a frequent request: the software runs, but nobody fully trusts it. We explore it first and derive the cases from how it really behaves, because specifications are usually missing.
Smaller jobs are billed at DKK 895 per hour, excl. VAT. Recurring pre-release cycles can be agreed at a fixed price, so the budget is known up front.
Tell us about the system and the parts that make you nervous. You will get a test plan and an effort estimate.
Thank you for getting in touch
One of our consultants already has it. Expect a reply within the working day; anything urgent goes straight to an engineer.
That city is not on our list. Check the spelling or pick the nearest larger town.