How to organize the testing process with 6 steps

Hi all! My name is Elena Poplouhina. I am one of the authors Youtube channel for testing Tester’s Luggage. The channel released an episode about building a manual testing process from scratch. This article contains the main information from this issue – 2 general tips and 6 first steps for organizing the process.

Introduction

Imagine that you are on a new project. The only tester or in the QA team of engineers. Your task is to organize the process of manual testing. The project is currently in one of the following stages:

  • The project is just starting, the team is being formed, processes are being built from scratch;

  • The project is already developing, public releases are being issued. But there are quality issues.

Perhaps you feel like a hedgehog in a fog. Where to start?

Tip 1 – Start by clarifying the problems and expectations of testing

If the project is already under development, find out the main quality issues. To do this, conduct a survey among team members. You can start a survey with QA engineers and a project manager, and then connect development leads and other team members.

Don’t expect colleagues to enthusiastically jump in and describe problems in detail. It is better to prepare a list of the most common problems in advance and send it to the team in the form of a questionnaire. Google forms are well suited for such surveys.

Problem examples:

  • Errors in requirements are discovered at the stage of development or testing of features;

  • Significant time spent on communication between team members;

  • Bugs are often not reproduced according to the description. Developers have to spend time communicating with the tester to find out the details of the bug;

  • There are no criteria for releasing the current version of the app to the public;

  • etc.

Additionally, find out the expectations from testing. As opposed to a list of problems, offer to describe this information in a free form. Typically, expectations are closely related to the problems identified in the previous step.

Expectations from testing will indicate the direction from which to start building the testing process. For example, the expectation “Reduce by 2 times the percentage of return of bugs between QA and Dev” indicates that it is necessary to introduce templates for bugs and agree on the rules for working with bugs.

Tip 2 – Introduce improvements gradually

Based on the results of the team survey, you will receive a list of problems and determine expectations from testing. You don’t have to fix all problems at once. Sort the list in order of importance based on expectations from testing. Take one or two problems from the generated list. Make improvements, analyze results, and make process adjustments as needed. And move on to fixing the next problem. This is how you build the testing process step by step.


Next, consider 6 practical recommendations for organizing the testing process.

Implement a bug template

Develop a bug template and describe the bugs found on it. If the project uses a wiki system, create a separate section for testing in it and store document templates and regulations in it.

Having templates for bugs has the following benefits:

  • Saving time on reproducing bugs for both developers and testers. In the case of a short and uninformative description, not only the developer, but also the bug author himself may not remember what was discussed.

  • Reduction of communication time between dev and qa – this point follows from the previous one. Developers will not knock on your PM with the words – what was meant in this bug? And on what stand and test data is it reproduced?

  • Uniform style of bugs – it is pleasant and familiar to work with bugs for all team members.

Agree on a bug priority list

When designing a bug template, pay attention to the set of priorities. Priorities are responsible for the order in which bugs are fixed. The team needs to avoid situations where developers fix 10 low priority bugs instead of 1 critical.

With proper prioritization, the most important bugs get to work first. This is important because fixing them brings more business value. At the same time, you should not overdo it with the number of high priority bugs. In such situations, developers do not know which of the bugs to take into work in the first place.

You can set 5 bug priorities, for example:

  • Blocker – Blocker

  • Critical – Critical

  • Important – Major

  • Normal – Normal

  • Minor – Minor

Or get by with a simpler version of three priorities:

  • High – High

  • Medium – Normal

  • Low – Low

Agree on the rules for setting priorities, arrange them in the form of regulations and put them in the wiki.

Implement a bug-handling policy

A consistent bug lifecycle helps developers not miss reported bugs, and testers keep track of bug fixes.

The life cycle of a bug is a description of the bug states and the rules for moving through them in the project management system.

Follow these steps to create a regulation:

  • Think over a set of statuses for bugs.

  • Define the rules for transition between statuses and the order of assigning performers.

  • Coordinate the schedule with the project manager.

The regulation is presented in the form of a visual diagram or a text description. After agreeing on the regulations with the team, put it on the wiki and follow its implementation for the first time.

Coordinate the rules of work with tasks in the project management system

Well-established work with tasks in the project management system reduces the time for unnecessary communications and helps to get an overall picture of the implementation of tasks at any time. The project management system is one of the main tools for testers. You can’t constantly ask the developers – when will this task be ready? You track task statuses in the project management system.

The whole team must adhere to the rules for transferring tasks by status. QA engineers should pay special attention to statuses for testing tasks:

  • Ready for test – the task has been completed by the developers and is ready for testing;

  • Testing – the task is being tested by the tester;

  • Done – the task has been tested within the iteration;

  • etc.

Write test cases or checklists… as early as possible in the quality assurance process

One of the first skills that testers learn is test case design. This is the base. However, testers do not always create test scripts on paper.

One of the main reasons is called “no time”. This problem is solved by proper iteration planning and testing time estimation.

In the absence of checklists or test cases, you risk the quality of your product.

The 2 main tips for the test case design stage are as follows:

  • If there is no need for test cases, write checklists;

  • Write test cases or checklists as early as possible in the quality assurance process. Ideally, at the stage of requirements testing or before development.

Benefits of designing test cases or checklists early:

  • You take your time, are focused, and can think well about test cases;

  • Early detection of errors in requirements;

  • Ability to start testing immediately after submitting the task for testing.

Designing test cases after development is complete leads to the developer receiving feedback on the task later. If you find errors in the requirements, the price of their correction will be significantly higher, because the development has already been completed.

Cons of testing without test cases or checklists:

  • You come up with test situations on the go, while interrupting for testing, localization and introduction of bugs, communication;

  • Rechecking the same situations several times;

  • The risk of missing test cases is increased due to haste or lack of documented execution results;

  • There is a feeling that “you seem to have checked everything”, but “maybe you forgot something”.

The risk of missing bugs in this case is much higher than with cases. And the confidence in the quality of the product is lower.

Set release criteria for a release

How to determine when the current version is ready for release? Should we wait until the last bug is fixed or not?

To answer these questions, the criteria for releasing a release into production help. These are clear rules, under which you, as a quality specialist, can give the green light to a release.

You must agree on these criteria with the team and stick to them. Pick a few criteria to start with, try to release based on them, or just complete an iteration. After 1 or more releases, review how the selected criteria fit the process.

Criteria example:

  • All features have been tested;

  • For features, bugs of all priorities, except for low ones, have been fixed;

  • Regression testing was carried out;

  • etc.

As a result of testing, you provide the project manager with a decision about the readiness of the product for release. The criteria will help you move from the “it seems to work” option to a reasonable conclusion.

Conclusion

We covered 2 general tips and 6 first practical steps for building a manual testing process on a project.

Thank you for your attention and see you in the next article!

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *