Бэклог — журнал оставшейся работы, которую необходимо выполнить команде. Термин пришел из семейства методологий Agile, в частности из Scrum, где он является одним из основных артефактов — источником пользовательских историй. Я работаю тестировщиком в офисе примерно по 8 часов, изредка работаю в выходные. Есть большие цели на полгода и небольшие проекты на несколько недель или месяцев. Есть и обязательная рутина. Работы всегда с избытком, то есть нет объективной возможности сделать всю. Через год я не хочу увидеть, что делаю те же задачи и решаю те же проблемы. Я не Дорофеев и не Архангельский, рецепта счастья в статье не будет, но можно смело рассчитывать на пару неплохих советов и приемов. Моя статья будет полезна тестировщикам, которые управляют списком багов продукта, занимаются приоритезацией и актуализацией дефектов. Тем, у кого много разовых задач по поддержке системы тестов и процесса тестирования. Возможно, тем, у кого кроме задач по тестированию, есть немало дополнительной работы или даже внешних по отношению к команде проектов. Моя первая ошибка — я не понимал, что бэклогов у меня несколько. По отдельности проекты реализуемы, но я планировал время так, будто буду заниматься только одним бэклогом из нескольких. Вторая ошибка — я считал бэклогами источники задач. Это вело к тому, что я сразу же начинал заниматься входящими задачами. Свежие задачи всегда кажутся более срочными, важными и легкими. И я переставал работать на свои цели и становился разгребателем входящих. Чтоб эти источники стали полноценным бэклогом, нужен более или менее формальный акт их обработки. Поэтому я ежедневно пересматриваю фичи к тестированию и входящие в Micromiles. Раз в 2–3 месяца мы с группой тестировщиков думаем о технических улучшениях и техническом долге, проводим ретро команды разработки. И только после этого входящие запросы получают статус реальности, приобретая самый ценный ресурс — время. Разделение источников и бэклогов необходимо, чтоб решить самую большую коллизию: Рабочие задачи vs остальное, важное vs срочное. Ну вы знаете. Если заниматься задачами по приоритету, то все время будет забиваться срочными задачами с доски. Если делать только проекты, то просядет обязательная рутина. Несколько лет назад я договаривался о SLA: рабочие задачи могут ждать в очереди не больше 3 дней и их в очереди не больше 5 штук. Пока этот контракт соблюдается, можно заниматься проектами. Сейчас я решаю вопрос так: Очень важно признаться себе и руководителю — я не сделаю ВСЕ. Но я буду регулярно делать не меньше, чем столько-то. Первое, что мы делали — уменьшали бэклог. Пара историй о том, как нам это удалось. Жил-был продукт и было в нем 300 открытых багов. Очень много времени тратилось на их актуализацию. Тестировщики страдали от несовершенства мира, менеджер не выделял времени, вокруг царила тьма. Собрались менеджер и тестировщик, отсортировали баги по дате создания и закрыли 100 самых старых, с размаху не читая. Рассудили, что раз год никто не чинит, значит, это не самая страшная проблема. А еще это значит, что не починят никогда. Прибежали заинтересованные лица и начали громко ругаться, что так нельзя, что это хамство, что это важные баги, что они тратили время на их поиск и все они очень нужны клиенту исправленными! Менеджер и тестировщик не спорили и открыли назад все 5 багов, по поводу которых прибежали заинтересованные лица. Бэклог стал на треть меньше. Сейчас эти менеджер и тестировщик познали дзен и раз в полгода (так же не глядя) убивают все баги и таски старше полугода. Проблем не было. Жил-был другой продукт, в котором в месяц открывалось 40, а закрывалось 20 багов. Было понятно, что мы движемся к первой истории. А не хотелось, потому что менеджер и тестировщик были те же самые. Менеджер договорился с тестировщиками, что заводить будут только те баги, которые точно починят в ближайшие 1-2 недели. А чтоб их точно починили, надо договориться с разработчиком. Иначе — не заводить. Совсем. Договариваться сложнее, чем заводить баги в трекер. Однако открытых багов в продукте теперь около десяти и так — третий год подряд. — Как же быть, если к нам опять обратятся с тем же багом?
— Так же. Починить или не заводить.
— Но вы же тратите много времени на переисследования?
— Казалось бы, что да, но нет, мы не тратим.
— У вас забагованный продукт!
— Количество багов в продукте до и после этой меры не поменялось. Просто мы честно признались себе в том, что мы можем, а что нет. Ощущения от отсутствия огромного списка открытых дефектов — специфические. Сейчас менеджер и тестировщики познали дзен и отказались от использования дефект-трекера ради трех-семи открытых багов. Выкинули лишнее, оставшееся точно нужно делать. Но нет времени. Как быть? Правильно подготовленный бэклог позволяет найти время. У нас есть масса источников времени, которыми можно научиться пользоваться. Летом в нашу команду приходят стажеры-программисты. Кроме знакомства с продуктом, обязательная часть обучения — знакомство с тестирующей системой. Наставник и менеджер легко соглашаются, чтоб стажер занялся задачей по улучшению системы тестов. Главное, чтоб эта задача была сформулирована, понятна и конечна. Так в нашей тестирующей системе появился генератор данных. А еще у нас в компании есть такая практика — раз в год каждый тестировщик имеет право на месяц перейти поработать в команду другого продукта. Поучить и поучиться, на мир посмотреть да себя показать. Если ко мне в команду пришел такой тестер, то я предлагаю ему сделать улучшение, до которого у меня не доходили руки. Мне — улучшение, ему возможность месяц не заниматься рутиной. Так мы поднимали покрытие модульными тестами. Программист с десятого марта уходит в отпуск, а все свои задачи он доделал уже седьмого и не хотел бы брать ничего большого. Важно ухватить этот момент за загривок и подсунуть ему небольшую задачку. Так наши тесты стали немного стабильней. Программист отдал в тестирование 2 задачи и не хочет брать в работу третью, пока не выпустит в бой первые две. Самое время заняться улучшением тестирующей системы, которой он пользуется! Так наши браузерные тесты стали ходить вдвое быстрей из-за некоторого шаманства с кешами. (И будем честны, задачу программист придумал себе сам.) Месяц назад наша команда сняла домик в деревне и три дня усиленно работала над втаскиванием новой модной системы распределенной трассировки. Тестировщик не умел втаскивать систему распределенной трассировки, но мог не делать обычные ежедневные таски. Так в нашей тестирующей системе стало на несколько TODO меньше. Помните менеджера из первой истории (там еще от 300 багов осталось 205)? Близился Новый год, а в последние пару рабочих дней перед Новым годом весь СНГ не деплоит ничего серьезного. Но можно взять 20 программистов, выдать в пару каждому тестировщика или аналитика и устроить соревнование — кто починит больше багов? Берешь любой дефект, если за 15 минут суть ясна — чинишь, тестировщик (или аналитик в его роли) при тебе проверяет, коммитишь и берешь следующий. Если баг сложный — пропускаешь и идешь дальше. Большая доска с прогрессом, атмосфера соревнования, Нового года и бардака, пицца в конце и ощущение некоторой лихости. Так открытых багов стало еще на 80 меньше всего за один день. Внедренцы продукта хотят первыми знать о новых фичах? А может, они и немного багов найдут в процессе? Пока задача ждет очереди, выкатим ее на тестовый стенд и напишем об этом ребятам из внедрения. Так появился «Клуб адептов второго тестинга», где можно заранее потрогать новинки продукта и сообщить о багах. Дизайнер интересуется, как выглядят в реальности его прототип интерфейса? Можно еще до начала тестирования показать ему тестовый стенд. А заодно пояснить: «Кстати, все баги верстки можно записать вот сюда, а лучше обсудить с программистом напрямую». Так появился «авторский контроль» задачи, значительно уменьшающий количество дефектов верстки. Аналитик, можешь писать в постановку how to demo фичи? Программист, у меня есть один готовый тест-кейс, закодируй end-to-end тест, пока ждешь первых результатов тестирования. Так у каждой задачи к началу тестирования появился закодированный end-to-end автотест. Возможностей много, их даже можно создавать. Для этого нужно уметь эти возможности использовать, подготовив бэклог: Надеюсь, что мои советы и истории помогут работать без суеты и не делать лишних движений. А если у вас есть свои оригинальные наработки по теме, поделитесь ими в комментариях! Список статей календаря:
Попробуй другой подход
Разумное парное тестирование
Обратная связь: как это бывает
Оптимизируй тесты
Прочти книгу
Тестирование аналитики
Тестировщик должен поймать баг, прочитать Канера и организовать движуху
Нагрузи сервис
Метрики на службе у QA
Протестируй безопасность
Узнай своего клиента
Разбери бэклог Редактор блога