Area 14 · Development and websites

Testing and QA

A defect spotted by a developer costs sixty minutes of their time. The same defect found by a customer at peak season costs lost revenue and a damaged reputation. Testing exists not to find someone to blame but so the problem surfaces before anyone else sees it.

Order testing Types of testing

×10

cheaper to catch before release

types of testing

Report

with steps to reproduce

Automated tests

repeat checks without hands

What the area consists of

Five directions, each with its own question: does it do what it should, will it stand the load, can a person work it out and are there any holes.

Discuss the product

Functional testing

We repeat the customer's actions by hand: placing an order, paying, returning, editing their own details. Edge cases, where things most often break, form a separate block.

Load testing

We simulate a surge of visitors and find the point where the system stops coping. Learning your limit in advance costs less than discovering it on sale day.

Test automation

The key journeys check themselves before every release. Both the repetitive manual work and the fear of shipping disappear.

UI/UX testing

We watch real people on real phones: where they get stuck, what they cannot find and why an order goes unplaced.

Security testing

We find the holes before release: injection into database queries, mistakes in permission handling, excess information in server responses and logs, weaknesses in the sign-in mechanism.

What a defect costs

The cost of the same defect depends on the stage at which it was found. That is the main argument for regular testing rather than a single run before handover.

At the idea stage

Once over. It is enough to correct the wording in the specification.

While the code is being written

Three times. The developer changes the lines before they reach a build.

In testing

Ten times. The work goes back to the developer and the whole cycle repeats.

After the release ships

Thirty times. An unplanned release with an emergency patch is required.

A customer found it

One hundred times. On top of the cost of the work come lost revenue and a dented reputation.

Investment in automation pays off not at once but after dozens of runs. That is why the machine is given the settled journeys that get walked at every release. Automating something rewritten weekly means spending the budget on maintaining the tests themselves.

How the testing works

The output is not a complaint about quality in general but reproducible findings with priorities, which a developer can start on immediately.

We study the product

We study the user journeys, who the users are and what matters to the business. Giving every area equal attention makes no sense.

We draw up the plan

We fix the list of checks and the list of devices and browsers. The document is agreed with you and sets both the effort and the price.

We test and write the report

Every finding comes with the steps to reproduce, a screenshot and a severity rating. Otherwise the report is worthless.

We check it again

When a fix arrives we look not only at it but at the neighbouring areas: whether anything broke along the way.

Questions and answers

They do test, but they confirm that what they built behaves as intended. A tester's job is the opposite: to find out what happens when you depart from the intention. The roles are fundamentally different and sit badly in one head - the eye stops noticing the obvious.

Yes, people come to us for this regularly just before accepting work from a contractor. We have no reason to hide findings, so the report is impartial. It makes more sense to run such a check before signing off rather than afterwards.

We start from your own analytics rather than a universal list. Usually two or three phone sizes and three browsers are enough - they account for the vast majority of visits. Testing everything is expensive and does not pay for itself.

Three numbers: how many simultaneous visitors it handles comfortably, at what point the slowdown begins and which component is the bottleneck - CPU, storage, the database or the code itself. With those you can choose between adding resources and rewriting.

Related by task

Browse the catalogue

Area 07 Cloud services and hosting Resources sized to the load level found Area 09 Information security In-depth security testing Area 10 Websites and web development Checking a site before launch Area 13 Custom software development Building a system with checks at every step

We will find the defects before your customers do

Напишите, что подлежит проверке и к какой дате. Составим программу работ и рассчитаем стоимость по числу проверяемых путей.

Phone
8 (777) 121 5771

Email
office@apply.kz

Office
Almaty, Bukhar Zhyrau boulevard, 62B

I agree to the processing of personal data