Разбери бэклог

Написал статью для календаря тестировщиков, первый выпуск.
Лежит вот тут, ниже ее текст.

Разбери бэклог

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

Итоги 2017 года мы подвели пару недель назад и самое время подумать о том, что мы запишем себе в итоги в конце 2018.

Кто я и для кого пишу статью

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

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

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

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

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

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

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

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

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

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

Чтоб эти источники стали полноценным бэклогом, нужен более или менее формальный акт их обработки. Итак, я:

• Ежедневно пересматриваю
• Фичи к тестированию
• Входящие в Micromiles
• Раз в 2-3 месяца
• Группой тестировщиков думаем о технических улучшениях и техническом долге
• Проводим ретро команды разработки

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

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

Если заниматься задачами по приоритету, то все время будет забиваться срочными задачами с доски. Если делать только проекты, то просядет рутина, которую не делать нельзя.

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

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

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

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

Итак:

• Время на рабочие задачи займут:
• TODO в коде
• Фичи к тестированию
• Идеи из вики с техническим улучшением
• Проблемы команды из ретро
• Время на проекты и встречи потратится на:
• Проблемы команды на ретродоске
• Идеи из вики с техническими улучшениями (редко, обычно код)
• Задачки из Micromiles
• Сделается за утренний час разбора всякой херни
• Задачки из Micromiles

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

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

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

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

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

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

Менеджер и тестировщик не спорили и открыли назад все 5 багов, по поводу которых прибежали заинтересованные лица.

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

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

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

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

Жил был другой продукт и в месяц открывалось 40, а закрывалось 20 багов.
Было понятно, что мы движемся к первой истории. А не хотелось, потому что менеджер и тестировщик были те же самые.

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

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

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

    — Но вы же тратите много времени на переисследования?
    — Казалось бы, но нет, мы не тратим.

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

Ощущения от отсутствия огромного списка открытых дефектов — специфические.

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

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

Выводы из первых двух историй

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

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

Выкинули лишнее, оставшееся точно нужно делать. Но нет времени. Как быть?

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

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

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

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

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

Свободное время программистов

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

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

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

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

Командные движухи

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

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

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

Но можно взять 20 программистов, выдать в пару каждому тестировщика или аналитика и устроить соревнование — кто починит больше багов?

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

Большая доска с прогрессом, атмосфера соревнования, нового года и бардака, пицца в конце и ощущение некоторой лихости.

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

Желающие помочь

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

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

Проектировщик (или дизайнер) интересуется, как выглядят в реальности его прототип? Можно еще до начала тестирования предоставить ему стенд. Кстати, все баги верстки можно записать вот сюда, а лучше обсудить с программистом напрямую…

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

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

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

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

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

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

А что дальше?

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

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