When discussing quality, complying with a particular set of requirements usually comes to mind. A client, analyst, or someone else sets tasks and people often take those as the requirements. The worst case scenario is that these requirements are taken as non-negotiable, and lead to the wrong results if followed to the letter. This often happens with outsourced development, and it can have a negative impact on the end user’s experience.

At SmartHead, we believe that there is more to quality than just meeting client demands. It’s not purely complying with requirements, but also the requirements themselves. We do not take only the client’s expectations into consideration, but the end user’s experience too. This means that our concept of quality also includes components such as usability, UI texts, responsiveness, and release frequency.

High-quality execution means that different needs are satisfied, namely those of the developer, the client, and the end-user.

How can this be achieved? It’s not easy by any means, but you should adopt a mindset of built-in quality from the start.

Quality is about development, not about testing

Quality is often associated with testing. But why?

Quality is determined by the way in which a product is built, not how it is tested.

The whole team is responsible for quality — especially the developer — who must be sure that the feature under development works correctly. It is wrong to say that a task is done when there is still uncertainty surrounding its completion. You can be confident that everything works well in two different ways: by how you write the code, and by how you organize the whole development process, including testing. However, it is crucial that quality assurance comes down to more than just testing. Moreover, the post-development manual testing stage should not be a bottleneck, and ideally should not be needed at all.

So, quality engineering should be included in the development process. To say that everything is “done” means that quality is assured.

Resilience

In products with long life cycles, changes are inevitable. So alongside its quality at the moment of feature development, “system quality” and its level of resilience are also important.

Making regular changes is completely normal, and products are likely to require much more than just one-off correction. This is only possible if it is certain that changes won’t break anything, and if this is the case, we can say that the system is resilient to change.

There are issues with resilience or quality if you do not want to touch anything while it is operating, or if the developers are reluctant to discard code they have already written.

The codebase is not something that we build and hand over. It is our environment that we should make comfortable to work in. It should be easy to add, edit and delete code.

No detailed requirements — no problem

If there are no detailed requirements, this does not mean you need to run to the client to ask “where in the UI should this button be?” Nor does it mean that it can go anywhere, however.

Apart from the incoming requirements (or lack thereof) it’s important to rely on common sense, experience, and taste — and high levels of each of these must be maintained.

The need to write detailed requirements can put pressure on clients to make important decisions regarding the product despite the fact that they lack either the knowledge or information to do so.

The absence of detailed requirements is not a problem, but rather an opportunity to do the job as well as possible and adopt a flexible approach towards the project’s scope, taking into consideration the available time and budget. In other words, focusing on the most important elements and ignoring the less significant ones is the best strategy.

Of course, we should understand what we are doing and why we are doing it, but a detailed description of everything is not necessary.

Bugs are inevitable, but not in excess

“Bugs are inevitable” is often said to justify low-quality development. Just because it is impossible to create bugless software does not mean that an excessive amount of bugs is acceptable.

Bugs are OK provided that: they do not prevent you from reaching project goals, they can be fixed quickly, and are not critical for the system’s stability. Severe bugs that break the main use cases occur quite rarely.

However, if every task is reopened after testing, or if fixing one bug causes three new ones to spring up, it means that there is an issue with quality.

Not everything is a bug

Bugs can also be viewed from another perspective. Their quantity depends not only on how the code is written, but also on the definition of a bug. Formally, a bug can be found in software of any quality. But not everything needs to be reported because it can just lead to some extra work.

We are not suggesting that you ignore bugs, although it is nonetheless important that you understand what requires your attention, and when you can move on. Testers can get bogged down in the details to such an extent that they run out of time to focus on what is actually significant. A lot of time can be lost on checking the layout, which then leaves little opportunity to check the main user scenario. Every task can be returned because of insignificant details, but this can mean that you lose sight of the bigger picture when it comes to quality. When all the tasks are reopened, it is not clear what has been done.

Moreover, you should not test the developer’s competence. If you spend more time testing their tasks purely because you don’t trust their ability, then bugs aren’t your problem. Instead, it is likely that there is mistrust in the team or the task is too complex for the developer. Ultimately, you should test software, not people — trust them instead.

In addition, we see little value in testing the design or the written requirements. They themselves, when they are not implemented, bring no value to end-users. You can and should review, discuss, and design them among your team, yet, there is no need to test them formally.

In a world of endless resources, it would be great to test everything, of course. However, in the here and now, there are simply more important tasks to consider.

So what should we test then?

The QA engineer is a product’s “user zero” who knows it well both from outside and inside. They should prioritize the user’s experience rather than checking the developer’s work. They should check what has been done, not what was being done, in other words features, not tasks.

The QA engineer’s objective is not to find as many bugs as possible, but to ensure that fewer of them make it into the final product. From this point of view, the fewer bugs they find the better.

The QA engineer is also responsible for accessibility and usability, including copywriting, animations, etc.

The QA engineer can also improve development quality by contributing their own thought processes. For example, they can help developers to write tests, cover edge cases, and ensure sufficient and reasonable coverage.

Testing is effective when it aims to bring additional value, and not when it compensates for the drawbacks of development.

Summary

1. Compliance with the requirements that were set initially shouldn’t be the goal. It’s much more important to make a great product.

2. User experience should be taken into consideration.

3. The quality level is set during the development. If time is wasted on compensating poor development with testing, then development, and thus quality, is neglected.

4. Manual testing should not be a critical need but something that adds to the value.