How to build a high-quality testing process on a project and assemble the right QA team

Clevertec we test fintech applications, and in practice anything can happen: we connect to working projects at different stages and lead them from scratch. We've hit our stride, learned from experience, and are sharing how we build processes and form teams for optimal effect.

Let's start with the team

How many testers are needed on one project? There is no golden rule. It depends on the size of the development team, the tasks facing the testing department, and the allocated budget.

But there are patterns that help maintain a consistent and transparent testing process.

Let's look at the example of a mobile banking application that works on two platforms: Android and iOS.

For a good result, the minimum composition of the testing team is a team lead and one or two testers. At the same time one tester for two developers different platforms.

The team leader builds processes, writes test plans, collects and updates information, prepares a test environment – completely organizes the process.
During the development and testing process, a lot of tasks are received, and the team lead delegates them to testers, distributing them according to complexity, and, if necessary, gets involved himself. He sees the overall state of testing, understands priorities and risks, and is ready to report the status at any time. If necessary, this person signals the customer in a timely manner, for example: the team needs to be expanded so that the quality of testing does not drop.

At this time, testers work clearly and with complete immersion on tasks, without switching to organizational and managerial issues. There is a team lead for this.

Do you really need that many people?

Why pay for the work of so many testers if you can leave one for 5-6 developers.

The answer to the question lies in the software life cycle. Working according to agile methodologies, the tester takes part in every stage of the application's life. If we start testing only when the code is written, we can end up with bugs in the product, failure to meet the deadline and, as a result, a low-quality product.

What happens when a tester arrives last on a project?

We simulate a negative scenario: the code is written – at the final stage, QA is invited to join the team.

There are two months for everything. What happened? The team spent the first month immersing themselves: they requested data from TestRail, access to microservices, Jira, looked for test data, wrote cases, test plans and checklists. We sorted it out, but there's only a month left. There is only one way out: select the main user scenarios and test them, bring them to an ideal state. Everything else could not be verified; we will have to check it after the release. This ensures that users will encounter problems.

Conclusion: testing should begin not after development, but along with the birth of the product.

Let's move on to the testing process

We determined: okay, while some are doing the design, others are writing technical specifications, testers are already working on the test environment, studying the devices and drawing up a test plan. Everything so that the final product meets the expectations placed on it.

Sometimes in the early stages of development we involve users as a group for closed testing. This makes it possible to think about improvements even before the general release.

Let's look at what the testing team does at each stage of development.

Working with Requirements

When analysts have completed work on the requirements, QA tests them.

If there are defects: the requirement is not fully described or contains ambiguous phrases, they are returned to the analyst and quickly edited.

If defects in the requirements are discovered after development, it will take much more time to eliminate them: change the requirements, rewrite the code and start testing again. This is difficult and expensive for the entire project – in fact, double work.

The requirements have been clarified. Now the QA team evaluates the amount of work, complexity of tasks, and required resources. At this stage, we clarify all unresolved issues that may complicate testing in the future:

We request test data in advance if it is provided by a third party.
We determine the fleet of devices on which testing will be carried out.
We are planning the distribution of roles.

If the team consists of testers with different work experience, the RACI role matrix helps distribute tasks. Complex tasks are performed by more experienced people, less complex tasks are performed by people with little experience under the guidance of more experienced ones.

Development

What should testers do while developers are writing code and the application is not yet ready? Write test cases and checklists for already tested requirements.

Each specialist has his own idea about the rules and content of test documentation. So that in the event of a tester’s absence or change, the team does not waste time on immersion, we use regulated rules for writing test cases and checklists. They make it easy to redistribute tasks to others with minimal time to realize.

To create and store test documentation, you can use ready-made tools: TestRail, TestLink, JIRA Zephyr, etc.

We use TestLink because it is free, has a developed system of roles and access levels, and has beautiful reports on runs.

Testing

The long-awaited stage has arrived. We begin active testing, performing checks against already written test cases or checklists.

To save time and resources, when receiving a testing task, the first thing we do is conduct smoke checks. If all checks are successful, the active testing phase begins. If we find a defect, we return the task for revision.

We enter detected defects into a bug tracking system: Jira Bugzilla, Redmine or others.

We use the generally accepted template for writing a bug report on the project. Again, to avoid discrepancies and difficulties with immersion in tasks.

Before each release, regression testing is carried out to make sure that the new functionality does not affect the operation of the old one.

During a regression, all code that goes into release is frozen, and changes are allowed only if a bug is found.

When developing native applications, regression needs to be done on multiple platforms. We take into account differences in platform versions, screen sizes, device manufacturers and shells. So instead of two devices, you get 10. Without automation, it takes many man-hours to perform all the manual checks. Don't forget to take this into account when planning testing dates.

Implementation and operation

The last and very important stage is the life of the application after release. Here we receive feedback from users and analyze it thoughtfully. If feedback indicates problems or that some functionality is not clear, we take this into account and improve the product.

When does testing end?

There are three reasons that occur in real development:

All test cases have been passed, bugs found have been fixed and rechecked;
Time is up;
The budget has run out.

There are no ideal processes or universal approaches to them.

Ensuring product quality is not a final process; it continues with each new release. We are improving and correcting the product, adapting to new realities and customer requests.

It is impossible to get 100% quality. But you can achieve maximum quality with a flexible team of QA specialists that is open to new approaches and tools. What do you think? Tell us in the comments.