In the circuit, there are 100 testers. At the end of last year, they invented the “Testers Calendar” - a cycle of 12 monthly articles with practitioners, secrets and life hacking about testing.

The first article was published in January on the website of the Yekaterinburg Testers Community . We transfer it to Habr so that more testers read it. The next article - in February - will be released tomorrow, and its announcement will be in the telegram channel .

The cycle is opened by Maxim Zakharov, the head of all contour testers and one of the testers of Retail . He will tell you why the bugs are piling up, how to disassemble the backlog and destroy 80 bugs with the help of pizza :)

Backlog is the log of the remaining work that the team needs to do. The term comes from the Agile family of methodologies, in particular from Scrum, where it is one of the main artifacts - a source of user stories.

I work as a tester in the office for about 8 hours, occasionally I work on weekends. There are big goals for half a year and small projects for several weeks or months. There is a mandatory routine. There is always an abundance of work, that is, there is no objective opportunity to do everything. In a year I don’t want to see that I am doing the same tasks and solving the same problems. I am not Dorofeev and not Arkhangelsk, the article will not have a recipe for happiness, but you can safely count on a couple of good tips and tricks.

My article will be useful for testers who manage the list of product bugs, prioritize and update defects. Those who have many one-time tasks to support the test system and the testing process. It is possible that for those who, apart from testing tasks, have a lot of additional work or even external to the team of projects.

Backdoor

My first mistake - I did not understand that I have several backlogs.

• Release 10 releases per month and check puzzles for them?
• Pass on the right for three months?
• Give tehdolg on autotests for two?

Individually, the projects are realizable, but I planned the time as if I would do only one backlog of several.

The second mistake - I considered the sources of tasks as backlogs. This led to the fact that I immediately began to engage in incoming tasks. Fresh tasks always seem more urgent, important and easy. And I stopped working on my goals and became a rake inbox.

Where do tasks for my backlogs come from?

• Features for testing: stored on the agile-board.
• Technical duty of the testing system: TODO in the code.
• The development of a test system: a new data model, screen testing, a library of assertions - complex improvements. Improvement ideas are stored on the wiki.
• The team’s problems: switch from one review system to another, stabilize the build with tests, draw stickers in the Telegraph, negotiate a release schedule. Stored in the form of green stickers on the board.
• Included in Micromiles todo application
• Personal projects: learn to write and understand JS tests, learn in regular expressions, do test design.
• Organizational duty: irrelevant checklists, a desire to tidy up the wiki, old non-repaired bugs.
• Everything else: from meetings, from meetings, from letters, from viewing reports, brilliant midnight insights.

So that these sources become a full-fledged backlog, we need a more or less formal act of processing them. Therefore, I daily review the features for testing and included in Micromiles. Once every 2-3 months, we with a group of testers think about technical improvements and technical duty, we are conducting a retro development team. And only after that incoming requests receive the status of reality, acquiring the most valuable resource - time.

Separation of sources and backlog is necessary to solve the biggest conflict: Work tasks vs the rest, important vs urgent. Well, you know. If you deal with the tasks of priority, then all the time will be hammered with urgent tasks from the board. If you only do projects, then a compulsory routine will follow. A few years ago I agreed on an SLA: work tasks can wait in a queue for no more than 3 days and there are no more than 5 for them in a queue. As long as this contract is respected, you can engage in projects.

Now I solve the problem like this:

• Four hours a day I book in a calendar with the text “I work on product tasks”. I try to devote this time to tasks from the board and protect this time from everything else. The goal is not to do all the tasks, the goal is to do these tasks at least 3 hours a day.
• Hour in day I give to small tasks from Micromiles. Write a letter, remind, read the text and think a little. For 1–5 minutes each.
• For the remaining 2-3 hours a day, I book projects and meetings. If the project is long - book a few pieces of time. If you have nowhere to book, I try not to take new projects.

It is very important to admit to yourself and the manager - I will not do EVERYTHING. But I will regularly do no less than so much.

How to cook backlog

The first thing we did was reduce backlog. A couple of stories about how we did it.

The story of one hundred closed bugs

Once there was a product and there were 300 open bugs in it. A lot of time was spent on their actualization. Testers suffered from the imperfections of the world, the manager did not allocate time, darkness reigned around.

The manager and tester gathered, sorted out the bugs by date of creation and closed the 100 oldest ones, without reading it with a sweep. It was judged that no one repairs the year, so this is not the worst problem. And it also means that they will never fix it.

Interested people came running and started loudly cursing that it was wrong, that this was rudeness, that these were important bugs, that they were wasting their time searching for them and that the client really needed all of them! The manager and tester did not argue and opened back all 5 bugs, about which interested persons came running.

Backlog became a third less.

Now, these manager and testers have known Zen and every six months (just not looking) they kill all the bugs and tasks over six months. There were no problems.

Morality. To be able to admit to yourself that the bug will never be fixed, just as important as understanding the price of owning each open bug.

Story about unnecessary bugtracker

Once upon a time there was another product in which 40 were opened per month, and 20 bugs were closed.

It was clear that we are moving towards the first story. But I did not want to, because the manager and tester were the same. The manager has agreed with the testers that only those bugs that will be repaired in the next 1-2 weeks will be started. And in order to fix them exactly, you must agree with the developer. Otherwise - do not start. Totally.

It is harder to negotiate than to get bugs in the tracker. However, there are now about ten open bugs in the product and this is the third year in a row.

- How to be, if to us again address with the same bug?
- Also. To repair or not to get.
“But you spend a lot of time re-examining?”
- It would seem that yes, but no, we do not spend.
- You have a buggy product!
- The number of bugs in the product before and after this measure has not changed. We just honestly admitted to ourselves that we can and what not.

The sensations from the absence of a huge list of open defects are specific. Now the manager and testers have learned Zen and refused to use the defect tracker for three or seven open bugs.

Morality. We get bugs to fix them. And if you can’t fix it anymore, we’re starting up less. The result is the same, and the disputes are less and calmer.

Cooking backlog further

Thrown out too much, the rest just need to do. But there is no time. How to be? Properly prepared backlog allows you to find the time. We have plenty of time sources that we can learn to use.

Interns

In the summer, interns come to our team as programmers. In addition to familiarizing with the product, the mandatory part of the training is familiarity with the testing system. The mentor and the manager easily agree that the intern takes up the task of improving the test system. The main thing is that this task be formulated, understood and final.

So a data generator appeared in our testing system.

We also have such a practice in our company - once a year each tester has the right to go to work for a team of another product for a month. To teach and learn, to see the world and to show yourself. If such a tester came to my team, then I suggest he make an improvement, which I didn’t reach. I am getting better; he has the opportunity not to do routine work for a month.

So we raised coverage modular tests.

Free time programmers

The programmer goes on vacation from March 10, and he completed his tasks for the seventh and would not like to take anything big. It is important to grab this moment by the scruff of the neck and slip a small puzzle into it.

So our tests have become a bit more stable.

The programmer gave 2 tasks to testing and does not want to take the third one into work until he releases the first two into battle. It's time to improve the testing system, which he uses!

So our browser tests began to go twice as fast because of some shamanism with caches. (And let's be honest, the programmer invented the task himself.)

Command Movements

A month ago, our team rented a house in the village and for three days worked hard to drag in a new fashionable distributed tracing system. The tester did not know how to drag in the distributed tracing system, but could not do the usual daily tasks.

So in our testing system, there are fewer TODOs.

Remember the manager from the first story (there are 205 more from 300 bugs)? The New Year is near, and in the last couple of working days before the New Year, the entire CIS has not put anything serious. But you can take 20 programmers, give a couple to each tester or analyst and arrange a competition - who will fix more bugs?

You take any defect, if in 15 minutes the essence is clear - you repair, the tester (or the analyst in his role) checks for you, commits and takes the next one. If the bug is complex, skip it and go further. A big board with progress, the atmosphere of the competition, the New Year and the mess, the pizza at the end and the feeling of some dashing.

So open bugs was another 80 less in just one day.

Those who want to help

Product implementers want to be the first to know about new features? Or maybe they will find some bugs in the process? While the task is waiting for the queue, we roll it out to the test stand and write about this to the guys from the implementation.

This is how the “Club of Adherents of the Second Testing” appeared, where you can touch the new products in advance and report bugs.

The designer is interested in how his interface prototype looks like in reality? You can even before testing begin to show him a test stand. And at the same time to clarify: "By the way, all the layout bugs can be written here, and it’s better to discuss with the programmer directly."

This is how the “author's control” of the task appeared, significantly reducing the number of layout defects.

Analyst, can you write how to demo features? Programmer, I have one ready test case, encode an end-to-end test while waiting for the first test results.

So each task to the beginning of testing appeared coded end-to-end autotest.

Why all these examples?

There are many possibilities, they can even be created. To do this, you need to be able to use these capabilities by preparing backlog:

• Prepare virtuals
• Request all access
• Set up stands and be able to quickly deploy to them
• Write clear test requirements
• Create prototype enhancements
• Clear and tasty articulate tehdolgi
• Keep the tasks up-to-date and on hand, so that at the right moment you should be the first to shout “I have an interesting task here!”
• Cut it all into small pieces.

I hope that my advice and stories will help to work without fuss and not to make unnecessary movements. And if you have your own original ideas on the topic, share them in the comments!

List of calendar articles:
Try a different approach
Reasonable pair testing
Feedback: as it happens
Optimize tests
Read the book
Analytics testing
The tester must catch the bug, read Kaner and organize a move.
Load service
Metrics in QA service
Test security
Know your customer
Disassemble backlog