Beware, newbie! How to maintain the quality of testing with the arrival of a new specialist

background

There were two of us, testers, on the project – understandable, stable; but after some time, my colleague decided to leave the project, and I was left alone to test the product. The “weather cleared up” pretty quickly: a new employee was found, and it would seem that there is no cause for concern. But in fact, as often happens, with the advent of a new tester, my workload has doubled. The story is as old as the world – you need to adapt the person who came to the project itself, whatever it may be – always try to answer questions, show how to perform this or that operation in the software product being tested, provide transparent and accessible information for a beginner and at the same time have time to test the software.

Something had to be done, and this kind of assimilation was ordered to be fast, timely and productive for each participant in the process. But did it turn out that I wanted to translate it into reality, and what results I got from the experience of implementing the microproject for adapting a new tester, I will tell at the end of this article.

The first phase of work: Analyzing the situation

First stage. Scheduling work for a new tester

At the first stages, it was decided to analyze what information needs to be provided and what tasks are necessary for the employee to complete so that he quickly gets up to speed.

But even though it was the wrong decision (because the task was completed before the beginnings of thoughts about the microproject), my first document for a new employee was the organizational instruction, which contains the following steps:

  1. Provide the employee with the necessary access to tools, documentation, task and bug tracking systems, to the tested product itself, to the calendar of calls and conferences, and so on to work in the project;

  2. Acquaintance with the team of project participants (name of the employee, position and area of ​​responsibility);

  3. Familiarity with tools: time logging, bug trackers, assigning tasks in a task tracker, Kanban board, testing tools, etc.;

  4. Briefing: how to open a test environment for a software product (there are also features in this);

  5. Getting started with the software under test;

  6. Actions if the software under test does not start;

  7. Functionality in a software product that often needs to be checked in regression testing;

  8. Answers on technical questions with software;

  9. Communication in case of difficulties on the project and in the organizational process.

And yet, I returned to the right track – it was decided to draw up a task plan for a microproject, the executor of which is a new employee, and after it to build up with the necessary materials, which will help him adapt to the project. So, the beginning of such a plan was the creation of a task to adapt the tester in the task tracker. Here the tester had to:

  1. Get the access you need for the current project;

  2. Get to know the development team

  3. Get to know the employees outside the team that are needed during application testing;

  4. Learn more about the project management methodology that is used within the team;

  5. Get briefings, user manual, requirements, test cases and other documents for working with the tested software product;

  6. Start learning on priority operations in the software, using instructions, functional test cases;

  7. Get a list of test data for software testing;

  8. Find out about workarounds in the absence of instructions for working with the program;

  9. Start testing the software product according to the priority functionality of the application, based on functional test cases;

  10. Compile top-level tests according to the requirements (without a detailed description of the steps inside the tests);

  11. Update existing tests, if any are outdated;

  12. Make a list of questions for the curator-tester on working with the software product;

  13. Make a list of questions for the test supervisor and / or project manager on the organizational process.

It was important to remember: a new employee with such a task is provided with work for two or three weeks for sure – but the adaptation of the tester does not end there.

Second stage: deepening

It was decided to complicate the work of the employee with a new task with new activities and with a deeper immersion in the project. Therefore, the tester should:

  • Test the software product, including internal modular integration;

  • Compose tests for modular integration (and this is already a description of the steps and what follows inside the test);

  • Test the software, including system integration between other related software;

  • Write tests for system integration;

  • Make a list of questions that have arisen for the curator-tester in working with the software product;

  • Make a list of questions that have arisen for the curator-tester on the organizational process.

But at the same time, it was necessary to understand: a new tester with a fresh look can see the subtleties or flaws in the adaptation project. Therefore, the main thing is to rely on the development of not only a new project, but also the testing itself.

Third stage: Useful contribution from a new employee

This is where the more immersed and experienced tester should contribute to both the testing of the software product and the tailoring project. The newcomer must:

  • Draw up missing or update existing organizational instructions and various materials that help to better understand the software under test;

  • Take a survey – which tests should be optimized for better testing.

So, the plan for the beginner is drawn up, but this is just the beginning – after all, our adaptation project needs to be replenished with materials. It turned out that there was a task for the tester, but there was no information to replenish the project knowledge of that very employee.

The second phase of work: Everything according to the scenario

Of course, I first of all paid attention to the briefings of the project. But are they so relevant, and how often do we all look into the world of “endless letters”? And it would be worth.

As a true tester, I decided not to dive into the scribbling of volumes, but to make small video tutorials with instructions. Decided! Need to do! But quickly came the realization that the task was not an easy one. Who knows, maybe in the video tutorials it will take me away to explain everything along the chain? Therefore, here I leaned towards drawing up a script, on which I will continue to rely.

In these video tutorials, I did not write down how to work with the software product, but what actions should be taken so that the tests pass successfully (not a bug but a feature).

If we remember about modular integration within the application, then we can understand that some tests depend on each other – and what will happen if one integration link is not configured, then the second, related one, no longer works.

Accordingly, the solution of problems that will help eliminate obstacles in testing was described: for example, the required function is missing in the program’s graphical interface – and how to display this function, what steps need to be taken to make the functionality appear.

Third phase of work: Documentation

I did not forget about the instructions for the software product themselves. To do this, I asked the project manager about the existing instructions – as it turned out, there were not all of them, but those that exist are almost outdated. But let’s work with what we have..

There were a lot of files that contained information on sections in the tested software product. Some documents overlapped with each other in sections. It is logical to assume that such material should be streamlined among themselves, because it is more convenient for a new tester to adapt.

I created a page in Confluence, inside the page I added a table with headings for the functional areas of the sections and added instructions to the necessary cells of the tables. As a result, the documents are displayed on the page in Confluence (which can be viewed by other team members) in the required areas, corresponding to the functionality in the instructions.

We should not forget about the problem of the lack of documentation for some of the functionality, and about the almost outdated status of materials. There is a way out – these are the answers to the questions that I asked analysts in the team throughout my experience on the project.

Fourth phase of work: Questions and Answers

I remember my first year working with software under test, when I asked 10 or more questions every day to analysts and other members and non-members of the product team. Their patience is to be envied. It is logical to think that this is the second solution in my microproject: “Answers to frequently asked questions.”

I set myself the task of sorting out all the questions asked by me and the previous tester and the answers from the team members in correspondence from instant messengers and e-mail. I created another page in Confluence, added the area headings for the relevant functionality in the form of expandable text (so that the new tester would not have to scroll through the page to find the right answer to the question), and started filling in the functional sections.

Scrolling through all the correspondence for 2.5 years was not easy. But I wrote out all the questions and answers on the above Confluence page. Of course, the team members and other project employees did not answer all the questions, and taking into account my experience on the project, I wrote down the solutions myself so that questions would not form without an answer.

Results and initiation

And the final phase of the work is myself, with the ideas, results and experience received. I can’t say that in the microproject for the adaptation of a newcomer to the project, I collected 100% of all the information. But the software product itself does not stand still, and, accordingly, the quarterly update makes it necessary to regularly update the project. If it is not possible to make new changes to the document, then the tester can freely ask questions of interest to a more experienced tester on the project (i.e. me).

By implementing such a project, I managed to save not only the time of analysts and developers, on whose shoulders the burden fell to answer all emerging questions, but also my own time – by more than 90%. And this is a great indicator.. Now I can be sure that the team members will allocate time for important tasks – and thereby the quality of the project itself will increase, because now no one distracts the specialists in the first place.

That’s all. I hope that my experience and the proposed solution can help your project not to “suffer” (sorry newbies!) from the inexperience of new employees. Good luck to all!

Similar Posts

Leave a Reply