Area 13 · Development and web

Testing and QA

A bug a tester catches on a Tuesday morning takes half an hour to fix. That same bug, spotted by a shopper during Black Friday, costs orders, support tickets and goodwill. We test to move the moment of discovery earlier - not to hunt for someone in the dev team to blame.

Book a test Types of testing

testing services in this area

100 %

remote, no site visits

Steps

to reproduce every defect

DKK 895

per hour excl. VAT

Five angles on quality

Each service answers one question: does it work, will it hold up under pressure, can people figure it out, and could an attacker get in?

Describe your product

Functional testing

We walk through the flows that matter the way a real customer would: sign-up, basket, paying by MobilePay or card, returns, editing a profile. Edge cases get a chapter of their own, since that is where things usually snap.

Load testing

We simulate crowds of simultaneous visitors and pinpoint where response times climb and errors appear. Learning your ceiling in October is far cheaper than hitting it on campaign day.

Test automation

Core scenarios run on their own in your CI pipeline ahead of every release. Repetitive clicking disappears, and shipping a new version on a Friday feels a lot less nerve-racking.

Usability testing

Real participants complete tasks on their own phones while we watch over a shared screen. We see where they hesitate, what they cannot locate and why baskets get abandoned.

Penetration testing

With written permission we attack the solution as a hostile party would: injection, weak authorisation, leaks in error messages and logs, a fragile login. The report doubles as evidence for customers and auditors.

When a defect gets expensive

One and the same bug carries a very different price tag depending on when it turns up. That is why steady testing beats a single big review the day before handover.

In the requirements

Practically free. One sentence in the brief gets rewritten before a line of code exists.

While coding

Slightly more. The developer adjusts the code while it is still fresh in their head.

In the test phase

Noticeably more. The ticket bounces back, and review plus deployment run all over again.

After release

Costly. An unplanned hotfix is needed, often late in the evening.

Spotted by a customer

Most costly. On top of the fix come lost orders, Trustpilot reviews and extra strain on customer service.

Automation only pays off after a test has run many times. So we automate the stable flows that must work in every release. Screens that get redesigned fortnightly stay manual - otherwise the budget goes on maintaining tests instead of improving the product.

How a testing engagement runs

Instead of a vague verdict on quality you get concrete, prioritised bug reports a developer can pick up straight away. Everything happens remotely through a staging environment, VPN or shared access.

Getting to know the product

We map user journeys, integrations and the spots where a failure hits revenue. Not every screen deserves equal attention.

Test plan and scope

Scenarios, devices and browsers are chosen from your own traffic statistics. You approve the plan, and it fixes the hours and the price.

Testing and bug reports

Every defect lands in your Jira, Azure DevOps or GitHub with steps, a screenshot, the expected outcome and a severity rating.

Retest

Once a fix is ready we check it again and look at neighbouring areas, so that repairing one spot has not broken another.

Questions and answers

They do, and they should keep doing so. Yet a developer confirms that the code does what it was built for. A tester looks the other way: what happens when a user does something unexpected? The two roles pull in opposite directions, and nobody sees their own blind spots easily.

Yes, that is one of our most frequent requests - typically just before acceptance from a supplier or as part of a public tender. We gain nothing from hiding defects, so the assessment is impartial. It makes most sense to test before the acceptance protocol is signed.

Yes. For public sites and solutions within the Danish Web Accessibility Act we check against WCAG 2.1 AA: keyboard navigation, contrast, alt text and screen readers. The findings can feed straight into your accessibility statement.

Three hard numbers: how many simultaneous users the solution copes with comfortably, when response times start to rise, and which part gives out first - CPU, disk, database or the code itself. With those figures you can weigh buying more capacity against optimising.

We recommend anonymised or synthetic test data. If real personal data is involved, we sign a GDPR data processing agreement, and the data stays on servers inside the EU.

Related areas

All services

Area 12 Custom software development Quality built into every sprint Area 09 Websites and web development A thorough check before go-live Area 08 Cyber security Vulnerability scanning and hardening Solution Retail and e-commerce Webshops that survive peak season

Catch the bugs before your customers do

Tell us what needs testing and when it goes live. We will send a test plan and a price estimate based on the number of flows.

Email
office@apply.dk

Coverage
All of Denmark, delivered remotely

I agree that Apply may handle my details as set out in the privacy policy