Before accepting a delivery
An agency hands over the application. Once you have signed it off, every fix is up for negotiation; beforehand, it is part of the job.
Whoever writes an application checks that it does what was planned. Whoever tests it hunts for the opposite: the case where it breaks. We put your online shop, client portal, mobile app or the software a supplier has just handed over through its paces, and come back with hard facts: what fails, how to reproduce it, how much it matters and what to fix first. Five services, one method, and every bit of the work done remotely on your test environment.
Each service answers a different worry. Does it do what we agreed? Will it survive the busiest day? Can we stop checking the same screens by hand every week? Do people understand what they see? Could someone reach data they should not? If you are unsure which applies, describe the problem and we will point you to the right one.
Every feature is checked against what was agreed, using real-life Spanish data: tax IDs, IBANs, VAT rates, the retailers' equivalence surcharge, Redsys and Bizum payments. You keep a suite of cases your team can rerun with each version.
We recreate Black Friday, the opening of an application window on a council portal or enrolment week on a copy of the system, to learn how many users it copes with and which component buckles first.
Checks repeated with every release start running by themselves in your pipeline, using Playwright, Cypress or Appium. We work out first whether it pays, and if it does not, we say so.
Five people from your real audience try to complete a task from home over a video call while we watch where they hesitate and where they give up. An accessibility review is part of it.
A controlled break-in attempt, always with the system owner's written authorisation and with scope and dates fixed by contract. The focus is on permissions between users, login and data inputs.
Hardly anyone orders testing for its own sake. There are particular moments when a defect turns out especially costly, and at those moments a few days of outside review save weeks of trouble.
An agency hands over the application. Once you have signed it off, every fix is up for negotiation; beforehand, it is part of the job.
A PrestaShop upgrade, a new ERP, a change of host. Things that worked for years can quietly break, especially around tax and shipping.
Sales season, Black Friday, a deadline opening. The day with the most traffic is the worst possible day to find the server's ceiling.
Manual checking can no longer keep up. Either the repetitive part gets automated or releases start going out unchecked.
A major customer or a tender asks for security testing. A penetration test report with scope and dates answers that request.
Testing at the end beats not testing, but testing during development is far cheaper. A bug caught while the developer still has the code open takes minutes to fix. The same bug in production means an urgent patch, calls from customers and, if invoices are affected, an awkward chat with your accountant. Wherever we can, we prefer to join a project in short cycles rather than only on the eve of release.
You will not get a verdict like «acceptable quality». You get numbered findings, sorted by severity, each with the steps to reproduce it. We reach your test environment through secure access or with test accounts set up for us.
You show us the application and explain who uses it and which systems it talks to. Together we mark the parts that cost money or reputation when they fail.
Which tests, on which browsers and devices, what is left out and the maximum number of hours. You approve the plan and the price before anything starts.
Each fault goes into your own tool, whether Jira, GitLab, GitHub or Azure DevOps, with steps, data, a screenshot and a severity rating, so the developer has nothing left to ask.
When fixes arrive we check each one and look at whatever surrounds it, because mending one thing sometimes breaks the next. It ends with a report and a recommendation.
In-house testing is essential, yet it has a natural blind spot: the author of the code knows how it is meant to be used and uses it that way. An outsider arrives without that habit, tries what nobody expected and has no stake in a good result. It also frees your developers to spend their time building.
Yes. A council or public body taking delivery of a commissioned application can ask us for an independent review before acceptance, checking what the technical specifications required. If the tender calls for accessibility testing under Royal Decree 1112/2018 or security testing in line with the ENS, we include it. Tender proposals are handled through tender@apply.es.
For functional testing of a small application, a week or two is plenty. For load testing ahead of a campaign, allow a month or more, since improvements have to be made and measured again afterwards. For a penetration test, the timing depends mostly on getting the authorisation signed and coordinating with your hosting provider.
One-off jobs are charged by the hour at €75 per hour + VAT, with a cap approved in the proposal. If you need testing with every release, it can be included in a Start, Business or Premium monthly plan at a fixed fee. Invoices are issued electronically and paid by bank transfer within 30 days.
Ideally there is none: we suggest fictitious data or an anonymised copy. If real data cannot be avoided, a GDPR data processing agreement is signed first, access is limited to the bare minimum, logged, and withdrawn when the work is finished.
Tell us what needs testing and when you plan to release. We will send a test plan with an estimate of hours.
Your request is with us
Expect an answer within one working day. A reported fault that has halted your team is handled first.
No match found. Try another spelling, or go with the closest provincial capital: every job is done remotely, so the location makes no difference to what we deliver anywhere in Spain.