QA team work management

The organization of work in each team begins with the understanding of each participant, what exactly needs to be done and what is the goal.

Of course, it is important for a manager to create a stable team. In such teams, the work process is more coordinated and productive, because experienced employees are good at organizing their work independently.

However it does not mean that it is difficult to work with newcomers, on the contrary, they can be taught stable practices at work. Being on their own, they will have to learn self-organization and build their own test strategies aimed at the result.

This article will be devoted to the conditions of work in outsourcing, that is, not on an «eternal» project, but in the case of frequent project changes.

Starting work:

It is important to prepare well before the start. Important inputs need to be given to the team about:

• the hierarchy of the project – who is in charge, to whom, what questions can be addressed;
• the purpose of a QA engineer on a project.

The next important stage will be the preparation of documentation. It is best if it is a detailed QA strategy. It is even better if comprehensive documentation is provided by the customer.

Documentation is very important as a source of information on a project. The more detailed everything is written in it, the better. Never take any information for granted. Other team members may understand withheld information differently.

If the project does not have a test plan, you need to create a checklist with hints. In such cases, it is better to have a template of a universal checklist for the start of the project and its support. This is where Google Sheets come in handy.

If we are already talking about Google documents, then it is also necessary to mention the method of their storage. It is best not to store all project documentation (specifications, meeting records, any useful documents and files) in personal accounts. Use shared folders or a shared team account so you don't have to search for access when a team member is on vacation, sick, or fired.

A few things about the initial data – it is extremely important, they must not just be spoken, but also written down. If there was a rally, you can record everything in a meeting notes chat right during the meeting, so that each participant can check and clarify the results. Then all the information must be transferred to the documentation. It is better to keep this documentation in one place rather than scattered across folders or disks.

What should be described in the documentation to make life easier for the lead and the entire team in general?

What is tested and how is it tested?

• What kind of product? What are the analogues, maybe you have already worked with something similar? This will help to understand what bugs can be and how to find them. For example, if we are talking about an online store, then its main functionality is the selection of products, adding them to the cart and purchasing.
• It is necessary to specify the name of the product and provide a link to the site that is currently used for testing, or, in the case of an application or game, it is necessary to inform where the current build can be obtained. It is important that the correct version is tested.
• It is necessary to discuss and look at the main functionality, for example, options for adding goods to the cart, etc.
• It is necessary to discuss priorities from the customer. If it is important for him to check the functionality, there is no need to spend a lot of time checking the layout, and vice versa.
• Specific deadlines must be set for each task, the time allotted for testing in each specific environment (browsers, devices, OS). The terms may be with a small reserve for force majeure, but this is more about global planning.
• For each task that is on the project, you need to announce the requirements for productivity and time spent. In addition to testing, it can be writing documentation.

Environment

• One of the main requirements for testing is the environment in which it needs to be conducted. We are talking about the software and hardware environment: devices, OS versions, browsers, additional software, screen resolution, etc. If we are talking about test automation, then you need access to Stage, the Git repository. DNS, Hosts, Mac settings are also important if required to run the product.
• Localization. It is important to understand in which language you need to test the product, for which country you need to use the AppStore, VPN or proxy, if necessary. Each product is designed for a specific target audience – this point is about that.
• An environment in which errors will be tracked and the testing process will be planned. It can be any bug tracker, project management system, or even Google Sheets. A bug tracker is definitely better than spreadsheets, especially on large projects.

Organizational points

• Emphasize in which chat communication takes place.
• What topics can/cannot be discussed in the chat with the customer.
• Specify whether critical and blocking bugs must be reported and clarified of their priority
• Notify about the start of work on tasks and about completion.
• If there is no progress in the chat for a long time, the testers or the customer are silent, it is better to clarify whether everything is fine and whether there are no certain difficulties in the work.

Preparation of working documentation

• It is necessary to describe the main functional units of the product under test.
• Appoint responsible persons, i.e. in checklists, test cases or test plan, you need to specify who and what will be tested, as well as provide appropriate access.
• You also need to determine which part of the testing will be automated and which will be done manually.

Tracking of work results and reporting

In order to start checking the results of the work, it is necessary to provide examples of what these results should look like. That is, you need to provide a link to the bug tracker or Git repository, as well as access parameters to the desired account. In addition, you need to inform the name of the project and the contact person to whom you will need to assign bug reports. It is necessary to discuss which fields are required to be filled in and whether there are any nuances for filling out bug reports on this particular project. It is best to make a detailed tutorial with videos and screenshots for beginners, especially if using a non-standard bug tracker. Criteria of seriousness and priorities should be as clear and transparent as possible. For beginners, you need to pre-negotiate bug reports and assign them to the executor.

Regarding reporting, it is necessary to agree in advance with the customer what exactly he would like to see in the report. Many novice employees do not like detailed reports. But over time, they become a habit and, on the contrary, help to better organize their own work. Also, a detailed report brings internal satisfaction to the employee by understanding the entire volume of work performed.

Key points of the report:

• what exactly was tested (project, product name, version, etc.);
• the environment in which testing was conducted;
• the time spent on the task;
• links to bug reports that were in the work.

It is important to add into a copy the previously discussed recipients. It is also important to consider the key points of the beginning and end of testing. That is, when exactly you can start testing (usually after obtaining all accesses, links and test accounts), as well as after what amount of work it needs to be completed. It is also better to indicate pending checks in the report. It is necessary to note the percentage of progress, what remains to be tested and what needs to be paid attention to.

In conclusion, we can say that well-organized teamwork rarely depends on the high achievements of each individual member of the team. Good work depends on good preparation, as well as a positive atmosphere in the team. However, preparation, no matter how good it is, will not eliminate all questions. Because people tend to forget what they've been told, can be lazy to look up information in the documentation if it's faster to ask someone who knows for sure, and also tend to doubt. Therefore, you need to be patient with questions and very often even encourage them, so that you do not have to correct all the work done.