«Календарь тестировщика» за январь. Разбери бэклог

В Контуре работают 100 тестировщиков. В конце прошлого года они придумали «Календарь тестировщика» — цикл из 12 ежемесячных статей с практиками, секретами и лайфхаками о тестировании.

Первая статья была опубликована в январе на сайте «Сообщества тестировщиков Екатеринбурга». Мы переносим её на Хабр, чтобы её прочло больше тестировщиков. Следующая статья — за февраль — выйдет завтра, а её анонс будет в телеграм-канале.

Открывает цикл Максим Захаров, руководитель всех тестировщиков Контура и один из тестировщиков Ритейла. Он расскажет, почему копятся баги, как разобрать бэклог и уничтожить 80 багов с помощью пиццы :)

Бэклог — журнал оставшейся работы, которую необходимо выполнить команде. Термин пришел из семейства методологий Agile, в частности из Scrum, где он является одним из основных артефактов — источником пользовательских историй.

Я работаю тестировщиком в офисе примерно по 8 часов, изредка работаю в выходные. Есть большие цели на полгода и небольшие проекты на несколько недель или месяцев. Есть и обязательная рутина. Работы всегда с избытком, то есть нет объективной возможности сделать всю. Через год я не хочу увидеть, что делаю те же задачи и решаю те же проблемы. Я не Дорофеев и не Архангельский, рецепта счастья в статье не будет, но можно смело рассчитывать на пару неплохих советов и приемов.

Моя статья будет полезна тестировщикам, которые управляют списком багов продукта, занимаются приоритезацией и актуализацией дефектов. Тем, у кого много разовых задач по поддержке системы тестов и процесса тестирования. Возможно, тем, у кого кроме задач по тестированию, есть немало дополнительной работы или даже внешних по отношению к команде проектов.

Разобрать бэклог

Моя первая ошибка — я не понимал, что бэклогов у меня несколько.

• Выпустить 10 релизов в месяц и проверить задачки к ним?
• Сдать на права за три месяца?
• Отдать техдолг по автотестам за два?

По отдельности проекты реализуемы, но я планировал время так, будто буду заниматься только одним бэклогом из нескольких.

Вторая ошибка — я считал бэклогами источники задач. Это вело к тому, что я сразу же начинал заниматься входящими задачами. Свежие задачи всегда кажутся более срочными, важными и легкими. И я переставал работать на свои цели и становился разгребателем входящих.

Откуда берутся задачи для моих бэклогов?

• Фичи к тестированию: хранятся на agile-доске.
• Технический долг тестирующей системы: TODO в коде.
• Развитие системы тестов: новая модель данных, скриншотное тестирование, библиотека ассертов — сложные улучшения. Идеи улучшений хранятся в вики.
• Проблемы команды: перейти с одной системы ревью на другую, стабилизировать сборку с тестами, нарисовать стикеры в Телеграме, передоговориться о регламенте релиза. Хранятся в виде зеленых стикеров на доске.
• Входящие в todo-приложении Micromiles
• Личные проекты: научиться писать и понимать JS-тесты, научиться в регулярные выражения, заняться тест-дизайном.
• Организационный долг: неактуальные чек-листы, желание прибраться в вики, старые непочиненные баги.
• Все остальное: с совещаний, со встреч, из писем, с просмотра докладов, гениальные полуночные озарения.

Чтоб эти источники стали полноценным бэклогом, нужен более или менее формальный акт их обработки. Поэтому я ежедневно пересматриваю фичи к тестированию и входящие в Micromiles. Раз в 2–3 месяца мы с группой тестировщиков думаем о технических улучшениях и техническом долге, проводим ретро команды разработки. И только после этого входящие запросы получают статус реальности, приобретая самый ценный ресурс — время.

Разделение источников и бэклогов необходимо, чтоб решить самую большую коллизию: Рабочие задачи vs остальное, важное vs срочное. Ну вы знаете. Если заниматься задачами по приоритету, то все время будет забиваться срочными задачами с доски. Если делать только проекты, то просядет обязательная рутина. Несколько лет назад я договаривался о SLA: рабочие задачи могут ждать в очереди не больше 3 дней и их в очереди не больше 5 штук. Пока этот контракт соблюдается, можно заниматься проектами.

Сейчас я решаю вопрос так:

• Четыре часа в день я бронирую в календаре с текстом “Работаю над задачами продукта”. Это время стараюсь посвятить таскам с доски и защищаю это время от всего остального. Цель — не сделать все задачи, цель — не менее 3 часов в день делать эти задачи.
• Час в день отдаю мелким задачами из Micromiles. Написать письмо, напомнить, прочитать текст и немного подумать. На 1–5 минут каждая.
• На оставшиеся 2–3 часа в день я бронирую проекты и встречи. Если проект длительный — бронирую несколько кусков времени. Если бронировать уже некуда, то стараюсь не брать новые проекты.

Очень важно признаться себе и руководителю — я не сделаю ВСЕ. Но я буду регулярно делать не меньше, чем столько-то.

Как готовить бэклог

Первое, что мы делали — уменьшали бэклог. Пара историй о том, как нам это удалось.

История про сто закрытых багов

Жил-был продукт и было в нем 300 открытых багов. Очень много времени тратилось на их актуализацию. Тестировщики страдали от несовершенства мира, менеджер не выделял времени, вокруг царила тьма.

Собрались менеджер и тестировщик, отсортировали баги по дате создания и закрыли 100 самых старых, с размаху не читая. Рассудили, что раз год никто не чинит, значит, это не самая страшная проблема. А еще это значит, что не починят никогда.

Прибежали заинтересованные лица и начали громко ругаться, что так нельзя, что это хамство, что это важные баги, что они тратили время на их поиск и все они очень нужны клиенту исправленными! Менеджер и тестировщик не спорили и открыли назад все 5 багов, по поводу которых прибежали заинтересованные лица.

Бэклог стал на треть меньше.

Сейчас эти менеджер и тестировщик познали дзен и раз в полгода (так же не глядя) убивают все баги и таски старше полугода. Проблем не было.

История про ненужный багтрекер

Жил-был другой продукт, в котором в месяц открывалось 40, а закрывалось 20 багов.

Было понятно, что мы движемся к первой истории. А не хотелось, потому что менеджер и тестировщик были те же самые. Менеджер договорился с тестировщиками, что заводить будут только те баги, которые точно починят в ближайшие 1-2 недели. А чтоб их точно починили, надо договориться с разработчиком. Иначе — не заводить. Совсем.

Договариваться сложнее, чем заводить баги в трекер. Однако открытых багов в продукте теперь около десяти и так — третий год подряд.

— Как же быть, если к нам опять обратятся с тем же багом? — Так же. Починить или не заводить. — Но вы же тратите много времени на переисследования? — Казалось бы, что да, но нет, мы не тратим. — У вас забагованный продукт! — Количество багов в продукте до и после этой меры не поменялось. Просто мы честно признались себе в том, что мы можем, а что нет.

Ощущения от отсутствия огромного списка открытых дефектов — специфические. Сейчас менеджер и тестировщики познали дзен и отказались от использования дефект-трекера ради трех-семи открытых багов.

Готовим бэклог дальше

Выкинули лишнее, оставшееся точно нужно делать. Но нет времени. Как быть? Правильно подготовленный бэклог позволяет найти время. У нас есть масса источников времени, которыми можно научиться пользоваться.

Летом в нашу команду приходят стажеры-программисты. Кроме знакомства с продуктом, обязательная часть обучения — знакомство с тестирующей системой. Наставник и менеджер легко соглашаются, чтоб стажер занялся задачей по улучшению системы тестов. Главное, чтоб эта задача была сформулирована, понятна и конечна.

Так в нашей тестирующей системе появился генератор данных.

А еще у нас в компании есть такая практика — раз в год каждый тестировщик имеет право на месяц перейти поработать в команду другого продукта. Поучить и поучиться, на мир посмотреть да себя показать. Если ко мне в команду пришел такой тестер, то я предлагаю ему сделать улучшение, до которого у меня не доходили руки. Мне — улучшение, ему возможность месяц не заниматься рутиной.

Так мы поднимали покрытие модульными тестами.

Программист с десятого марта уходит в отпуск, а все свои задачи он доделал уже седьмого и не хотел бы брать ничего большого. Важно ухватить этот момент за загривок и подсунуть ему небольшую задачку.

Так наши тесты стали немного стабильней.

Программист отдал в тестирование 2 задачи и не хочет брать в работу третью, пока не выпустит в бой первые две. Самое время заняться улучшением тестирующей системы, которой он пользуется!

Так наши браузерные тесты стали ходить вдвое быстрей из-за некоторого шаманства с кешами. (И будем честны, задачу программист придумал себе сам.)

Месяц назад наша команда сняла домик в деревне и три дня усиленно работала над втаскиванием новой модной системы распределенной трассировки. Тестировщик не умел втаскивать систему распределенной трассировки, но мог не делать обычные ежедневные таски.

Так в нашей тестирующей системе стало на несколько TODO меньше.

Помните менеджера из первой истории (там еще от 300 багов осталось 205)? Близился Новый год, а в последние пару рабочих дней перед Новым годом весь СНГ не деплоит ничего серьезного. Но можно взять 20 программистов, выдать в пару каждому тестировщика или аналитика и устроить соревнование — кто починит больше багов?

Берешь любой дефект, если за 15 минут суть ясна — чинишь, тестировщик (или аналитик в его роли) при тебе проверяет, коммитишь и берешь следующий. Если баг сложный — пропускаешь и идешь дальше. Большая доска с прогрессом, атмосфера соревнования, Нового года и бардака, пицца в конце и ощущение некоторой лихости.

Так открытых багов стало еще на 80 меньше всего за один день.

Внедренцы продукта хотят первыми знать о новых фичах? А может, они и немного багов найдут в процессе? Пока задача ждет очереди, выкатим ее на тестовый стенд и напишем об этом ребятам из внедрения.

Так появился «Клуб адептов второго тестинга», где можно заранее потрогать новинки продукта и сообщить о багах.

Дизайнер интересуется, как выглядят в реальности его прототип интерфейса? Можно еще до начала тестирования показать ему тестовый стенд. А заодно пояснить: «Кстати, все баги верстки можно записать вот сюда, а лучше обсудить с программистом напрямую».

Так появился «авторский контроль» задачи, значительно уменьшающий количество дефектов верстки.

Аналитик, можешь писать в постановку how to demo фичи? Программист, у меня есть один готовый тест-кейс, закодируй end-to-end тест, пока ждешь первых результатов тестирования.

Так у каждой задачи к началу тестирования появился закодированный end-to-end автотест.

К чему все эти примеры?

Возможностей много, их даже можно создавать. Для этого нужно уметь эти возможности использовать, подготовив бэклог:

• Заготовить виртуалки
• Запросить все доступы
• Настроить стенды и уметь быстро деплоить на них
• Написать понятные требования к тестам
• Создать прототипы улучшений
• Понятно и вкусно сформулировать техдолги
• Держать задачи актуальными и под рукой, чтобы в нужный момент первым крикнуть «У меня тут как раз есть интересная задачка!»
• Нарезать все это на мелкие части

Надеюсь, что мои советы и истории помогут работать без суеты и не делать лишних движений. А если у вас есть свои оригинальные наработки по теме, поделитесь ими в комментариях!