When we’re talking about software quality, in most cases, we mean particular compliance with the requirements. Sometimes, requirements mean those key features of the product which the client (or someone who is empowered to set such conditions) wants to implement. And it is very bad if such requirements are interpreted as uncontested, which ultimately leads to an end in itself – the client’s requirements.

This is regularly encountered in outsourcing, and such a focus of attention negatively affects the final result – what the customer sees and what the potential user can interact with then.

This article examines the concept of “quality” in a broader sense than it can be interpreted from the standpoint of software support, which is used in software testing companies.

Quality Is About Development, Not Testing

Many people associate quality with the software testing process. But this is a completely wrong position because [highlight dark=”no”]quality is determined by the factors of how the software is developed, not how it is tested.[/highlight]

The entire team (not only the development department or technical support department) is responsible for the product quality. Without a doubt, the first one who is concerned about quality is the developer since it’s his/her responsibility if some feature isn’t working properly.

It is very strange to say that everything is ready if there is no such complete confidence. It can be got in several ways – process and technological (including software testing).

But we must remember that it is also wrong to assign all responsibility to QA. The dedicated stage of manual testing after software implementation should not turn into a bottleneck. Ideally, it should not even be transformed into a necessity.

Work on software quality should be included in the implementation of this product. And quality should be equal to the word “do”.

Resilience to Change

In all the ongoing projects, along with the level of quality, the system quality is also important, as well as their technical resistance to possible changes. And we all know that sooner or later there definitely will be changes!

For a system under test to function and develop properly, the changes must be frequent. They should be taken as something regular, routine; don’t bring it to the level of exclusiveness. To do this, you have to realize that changes won’t break anything in a big way.

Not Everything That Fails Is a Bug

Bugs vision can be divided into several components. On the one hand, their number depends not only on how the code was created (how clean it is technically) but also on a thing we call a defect.

We can find a formal defect in the software of any level. But it’s not mandatory to record everything. Sometimes it’s just an unnecessary process and accordingly, a waste of money.

Of course, we don’t urge you to ignore bugs. It’s just a thought that we should differentiate between something important and secondary.

Sometimes, the QA department can go into details, waste a lot of time, and deviate from a path. You can spend much time and effort testing layout to mock-up compliance, and not learning the main user scenario.

What Should We Test Then?

The tester is a zero user of the system, who must perfectly know how the software works, both externally and internally. Its activities should be focused on providing a working user experience and not on the trivial verification of completed tasks by the development department.

[highlight dark=”no”]It is worth testing what is ready, not what was done initially.[/highlight] That is, you should work with features, not tasks.

The primary task of any tester is not to find the maximum number of bugs but to do everything to make them as few as possible. Tests are only effective when they can add value, and not just compensate for shortcomings of the development.

Conclusions

From all of the above, we can summarize the following:

1. Meeting the originally established requirements is not an end in itself for testing. The most important thing is to deliver a good product in the end.
2. User experience is crucially important.
3. Testing is a kind of bonus that should improve the system, it’s not a critical need.