A software fault costs most when a customer is the one who spots it. By then you have lost an order, collected a poor app store rating or ended the month with figures that will not reconcile with the bank. Caught a few weeks earlier in a test system, the very same fault is just one more line on a developer's to-do list. Why does a search for “Žužemberk” come back empty while “Zuzemberk” works? Where does a one-cent gap appear when someone pays in instalments? How can the PDF invoice show a different VAT rate from the basket? We put such questions to web shops, dealer portals, phone apps and freshly delivered contractor systems alike. There are five disciplines and a single way of reporting, and all the work runs inside your test environment over a secure remote link, without anyone turning up at your office.
Each discipline answers its own question. Are the calculations right? Will it survive a rush? Could a machine take over the manual pre-release checks? Can people actually complete the form? Could someone reach data that is not theirs? If you cannot tell which fits, describe what is going wrong.
Checks that the software delivers what the specification or quotation said it would. Č, š and ž in names and search, four-digit postcodes, 22% and 9.5% VAT on the right lines, card payments with 3-D Secure, credit notes for returns. You keep the full set of test cases to rerun with each new release.
We point thousands of virtual visitors at a replica of your system simultaneously: Black Friday evening, the minute concert tickets go on sale, the morning a coastal hotel opens early bookings for summer. The report shows whether the database, checkout or the server delivering images is first to buckle.
Ship every week and manual checking soon falls behind. Recurring scenarios get written as Playwright, Cypress or Appium scripts that run inside your CI/CD set-up. We work out in advance how many releases it takes to pay back the effort, and if the answer is never, we say so.
Placing a dealer order, choosing a dental slot, starting a return: several of your actual users attempt such tasks on their own devices while we record, over a video call, each moment of hesitation. The work also covers accessibility, checked against the WCAG 2.1 AA criteria.
Signed off in writing by the system owner and kept inside agreed boundaries, we try the path a real intruder might choose. We concentrate on weaknesses peculiar to your own software: a partner able to view a competitor's price list, stolen sessions, code slipped in through form fields.
At certain moments a defect becomes far more expensive. A few days of independent checking just beforehand saves weeks of patching, apologising and extra supplier hours.
Your agency or developer declares the project done. Gaps spotted before you sign the acceptance record are normally put right as part of the original contract. Spotted afterwards, the same gaps can come back to you as a fresh quote for additional work.
A new payment provider, a PHP upgrade, a server move or a different accounting package. Users see no change, yet shipping charges, fees or invoice numbering can drift without anyone noticing.
Television advertising, an influencer partnership, Black Friday or the Christmas season. Buying traffic only to land it on a broken page wastes the ad budget twice over.
Store review by Apple and Google, old Android releases, compact displays. Rejection delays the launch, while a debut release that crashes leaves ratings that are hard to shake off.
A major customer, a foreign partner or a cyber insurer wants evidence of a penetration test. A report giving the scope, the date and the findings you closed is the quickest answer, especially if you supply an organisation that falls under NIS2.
The best bug ticket lets a developer see the fault at the first attempt. A ticket reading “payment sometimes fails” travels back and forth for days. A ticket naming the browser, the card, the step and the exact error message tends to be fixed the same day. That is the level of detail we write every finding in, so your developers get on with the fix instead of chasing the tester for details.
Instead of a vague “looks fine overall”, you receive numbered findings ranked by severity. Access is via a secure remote link, or via accounts opened specifically for us. Production is left alone unless we have agreed otherwise.
On a video call we go through the application, who uses it and what it connects to. Functions whose breakdown would lose you revenue or customers, or cause regulatory trouble, go to the top of the list.
What gets tested, which browsers and devices, what is out of scope and how many hours we expect, summarised on one page. Billing starts only after your approval.
Each finding, including a screenshot and the data used, is filed on your GitHub, GitLab, Jira or Azure DevOps board. At the end of every day you receive a count of issues by severity.
Fixes are checked individually, together with whatever surrounds them. The closing report gives a plain recommendation: ship now, or resolve a named list of points beforehand.
For most functional, load and usability work, no. We work from the outside, as users do, with nothing more than a test system and logins. For automation the scripts belong in your repository next to the code, so we ask for limited access there. For penetration testing it depends on the approach you choose: black, grey or white box.
Scanning is automated and hunts for already-known weaknesses: wide coverage, little depth. During a penetration test, a specialist learns how your application works and spends hours probing by hand, for instance whether one partner can open another's orders or whether a refund can be triggered twice. No scanner picks that up. Your hosting provider's terms may require notice before testing, and we sort that out before we begin.
One or two weeks is often enough for functional testing of a small application. Allow at least a month for a load test before a major campaign, because the first measurement is followed by improvements and a second measurement. For penetration testing, the timeline is usually set by getting authorisation and coordinating with the host.
One-off projects are billed at €50 per hour plus VAT against an hours estimate you approve beforehand. If you need testing with every release, it can be added to a monthly Start, Business or Premium plan. Invoices arrive as PDFs by email with 30 days to pay. Please check with your accountant how VAT should be treated on a service from a supplier outside the EU.
Ideally there would be none there at all, which is why we propose fabricated test data or an anonymised copy. Where real data cannot be avoided, we sign a GDPR data processing agreement first, keep access tightly limited, log it and remove it when the work ends. Health records and other special category data get no exceptions.
Tell us what needs testing and when you plan to release. We will send a test plan with an hours estimate.
Enquiry received
An engineer will write back no later than the following working day. Faults that leave your staff unable to work are always looked at first.
No town by that name here. Check the letters, or settle for the nearest larger place. Our engineers work only over the internet, so Kočevje and Koper get precisely the same treatment.
