«Календарь тестировщика». Разбери бэклог
В Контуре работают 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 автотест.
К чему все эти примеры?
Возможностей много, их даже можно создавать. Для этого нужно уметь эти возможности использовать, подготовив бэклог:
- Заготовить виртуалки
- Запросить все доступы
- Настроить стенды и уметь быстро деплоить на них
- Написать понятные требования к тестам
- Создать прототипы улучшений
- Понятно и вкусно сформулировать техдолги
- Держать задачи актуальными и под рукой, чтобы в нужный момент первым крикнуть «У меня тут как раз есть интересная задачка!»
- Нарезать все это на мелкие части
Надеюсь, что мои советы и истории помогут работать без суеты и не делать лишних движений. А если у вас есть свои оригинальные наработки по теме, поделитесь ими в комментариях!
