Всем привет, я Карим Аминов, Head of QA в компании Test IT. Компания является частью одного холдинга Yoonion, который объединяет под общим брендом цифровые продукты для удобства работы бизнеса. Наши команды разработали два известных инструмента - это Test IT и TeamStorm.
Цель моей статьи — помочь наладить вывод релизов качественно и в срок всем, кто так или иначе связан с обеспечением качества на проекте. Также я надеюсь, что мой рассказ найдет отклик у всех, кто занимается релизами.
Это не регламент и не призыв к действию, а набор рекомендаций, который упростит вам жизнь. В конце статьи делюсь чек-листом для тестировщиков и предлагаю вместе подумать над шаблонами для других команд.
Треугольник успеха
Как тестировщику понять, что релиз успешный? Тут всё просто — надо сравнить ожидаемый и фактический результаты. Чтобы эти результаты были максимально приближены друг к другу, в первую очередь понадобится проработать треугольник успеха, а именно ответить на вопросы: Что? Где? Когда?
Как ответить на вопрос «Что?»
Определить зоны ответственности. Самая частая формулировка в любой команде: за релиз отвечают все участники. Здорово, что мы дружные, но такой подход замедляет рабочие процессы. При решении вопросов вся команда отвлекается на их обсуждение и теряет драгоценное время. А ведь проблемы решаются намного быстрее, когда понятно, кто за что отвечает.
⭑ Важно определить границы ответственности каждого члена команды, чтобы не тратить время на споры и советы «экспертов сбоку».
Составить четкий flow для работы над релизом. Каждому релизу нужна подробная дорожная карта: откуда появляются задачи, как берутся в работу, как выполняются и уходят на прод, какими инструментами и на каких средах выполняется тестирование, исправление критических ошибок и т. д. Это позволит команде увидеть, что происходит с релизом в каждый промежуток времени, и не задавать вопросов, почему мы делаем именно так.
Начните с верхнеуровневой схемы и далее углубляйтесь в детали, прописывая каждый шаг, пока ваш flow по работе с релизом не станет полным.
Я сталкивался с ситуацией, когда QA решали проводить регресс на стенде Dev, так как Regress не работал. У команды не было понимания, почему такое решение неправильное и что о такой проблеме как минимум нужно сообщить коллегам.
Еще один подобный пример: команда тестирования стартовала регресс на два дня раньше, так как хотела скорее освободиться от этих работ. Но при этом никто не думал, что перед регрессом должна быть готова финальная релизная ветка. Не было никакого понимания что за чем идёт.
Преимущества оформленного flow:
Детальный путь от появления задачи до прощания с ней.
Все части взаимосвязаны и выстраиваются в логическую последовательность действий.
Чем лучше декомпозирован путь, тем легче выявлять, на каком шаге появляется проблема.
Если что-то пойдет не так, детализацию не придется делать в процессе.
Детальная декомпозиция позволяет лучше понять, что мы упускаем и что можно оптимизировать.
Убедиться, что команда всё понимает однозначно. Часто участники команды видят проект, задачу или релиз по-своему: то, что для одного баг, для другого может казаться улучшением. Например, если вдруг выясняется, что ограничение длины логина для авторизации в 12 символов на самом деле не требование клиента, а простая ошибка.
⭑ Важно всей командой пройтись по flow, обсудить зоны ответственности и убедиться, что все всё понимают одинаково. С иноверцами разбираемся сразу.
Выделить ресурсы на подготовку. Бывает, что при планировании релиза не учитываются или просто забываются подготовительные работы: подготовка и проверка доступов, подготовка стендов, лицензий, закупка высококачественного зернового кофе для команды.
Важно понимать, что на реализацию этих работ тоже нужны временные и человеческие ресурсы — как вашей команды, так и смежных подразделений.
⭑ Все пункты подготовки должны быть выполнены до старта работ, иначе сдвинется итоговая дата релиза. Контроль этого поля поможет понять, что финальная дата релиза под угрозой.
Донести команде, что происходит после вывода релиза в продуктовую среду. На кодинге и тестировании релиз не заканчивается. Бывает так, что команда разработки, передав релиз, совершенно не понимает, что происходит дальше.
⭑ Это не значит, что вы должны отвечать за вывод релиза (смотрим пункт про зону ответственности), но каждый должен понимать, как он проводится и в какой момент что-то может пойти не так, к чему нужно быть готовым.
На моей практике часто не все участники релизной команды знали дату и время вывода релиза на прод. А успешен он или нет, и где это посмотреть, для таких людей и вовсе загадка.
Поработать с приоритетами. Необходимо научить команду не только грамотно работать с высокоприоритетными задачами, но и грамотно эти приоритеты расставлять. Чаще всего это касается именно команды QA, для которой все ошибки критичны и всё нужно исправить здесь и сейчас.
⭑ Нужно понимать, что у разработки и бизнеса могут быть разные приоритеты. О них лучше договориться заранее, а также следить, чтобы критичные и важные задачи выполнялись в первую очередь.
Как ответить на вопрос «Где?»
Понять, где разрабатываем и где тестируем (приёмка, регресс, нагрузка). Этот пункт ясен, но его не стоит игнорировать. Очень грустно, когда релиз подходит к концу, а ты продолжаешь получать вопросы, где проверить ту или иную задачу, какой стенд сейчас актуален, где раскатали релизную ветку и т. д.
Определить, какие инструменты используем. Все инструменты, которые дают реальную и актуальную картину по состоянию задач, должны быть доступны всем участникам релиза. Это позволяет сначала самостоятельно понять, что происходит, а следующим шагом сформировать конкретные вопросы коллегам.
Научить команду работе с инструментами. На каждом проекте есть система учета задач и ошибок, но единицы умеют пользоваться простыми фильтрами и доской. В итоге теряется общий взгляд на проблему и сразу становится понятно, кто заинтересован в успехе релиза, а кто нет.
Не молчать, но и не ныть. Прозрачность даёт возможность принимать правильные и быстрые решения по устранению проблем. Многие молчат до последнего, надеясь, что всё решится само собой или кто-то будет тем самым первым, кто принесет плохую весть.
⭑ Лучше горькая правда, чем никакой. Не замалчивайте проблемы, предлагайте свои варианты выхода из сложившейся ситуации или просто подсвечивайте свои опасения. Паника в таких вопросах никому не нужна.
Руководителям команд и релиз-менеджерам нужно адекватно реагировать на проблемы и вовремя уметь останавливать панику.
Как ответить на вопрос «Когда?»
Не забывать про релизный календарь. Он точно есть на проекте, и место его расположения должна знать вся команда.
Как ни странно, на моей практике чаще всего именно разработчики не знали даты релиза. Точнее, когда его следует отдать на приемку. В итоге приходилось выкручиваться за счет сокращения времени на тестирование.
⭑ Если команда не знает даты релиза — это плохой знак, который говорит о том, что нет четкой цели, есть только путь, как у самураев.
Понять, в какой момент начинается твоя работа. Не жди своих задач — требуй их, если они не готовы вовремя.
Начать работать с первого дня релизного цикла. Поделюсь цитатой от бывшего топ-менеджера «АвтоВАЗа»:
«Если в Европе менеджеру для выполнения задания нужна неделя, то здесь с работой справляются за один день. Потому что если дать русскому ту же неделю, он все равно сделает всё в последний день».
(c) Бу Андерссон
Выполнив пункты выше, на выходе вы получите как минимум ожидаемый по результатам релиз. Добавим еще три, чтобы закрепить наш успех.
Планирование
Определить сроки и ответственных за каждую задачу. Если у задачи нет срока, она будет выполнена «никогда». Если у задачи нет исполнителя или ответственного, ее выполнит «никто».
У всех задач должны быть сроки, на них ориентируются ответственные. Даже у гибких команд есть дедлайн, пусть и общий для всех задач. Это конец спринта.
Обсудить сроки до старта работ над релизом. Этот пункт важен для менеджера проекта или любого другого менеджера. Прежде чем что-то обещать, убедитесь, что команда согласна с вашим расписанием.
⭑ Совет команде: не бойтесь выразить свои опасения по срокам, если рискуете не успеть выполнить работу до дедлайна.
Выделить резервное время. Проблемы возможны, с ними сталкиваются все. Нужно лишь понять, сколько времени понадобится на их решение. Закладывайте время на риски — это не раз вас спасет.
⭑ Обращаясь к замечательным коллегам из QA, которые всегда полны оптимизма: оценки потенциальных проблем в задачах умножайте на два.
«Мы верим, что сделаем» VS «Мы сделаем». Есть разница между «сможем» и «реально сделаем». Позитив, постоянные вызовы и отсутствие грусти в глазах релизного менеджера — это хорошо, но старайтесь давать выполнимые обещания.
Составить четкий план действий. Все задачи связаны между собой, а все участники команды должны понимать последовательность выполнения работ.
⭑ Можно сделать чек-лист: отметить пункты, которые необходимо выполнить, и определить, в какой промежуток времени это нужно сделать.
На случай, если что-то пойдет не так, составьте отдельный план. Например, не лишним будет спланировать, как откатывать изменения на прод-среде, если это возможно.
Пример подобного чек-листа: Release Checklist
Проверить сроки связанных задач. Желательно проверить не только срок своей задачи, но и сроки связанных задач до и после (слева и справа). Это не контроль за коллегами, это свежий взгляд на задачу.
Daily
Ежедневные встречи с командой — ритуал, который съедает немалую часть рабочего времени, но иногда перестает приносить реальную пользу. Вот как, по моему мнению, выглядят хороший и плохой варианты проведения ежедневного командного митинга:
Неэффективный подход: что я делал вчера на работе, чем планирую заняться сегодня.
Эффективный подход: что я делаю для релиза сегодня и что мешает мне выполнить свою работу.
⭑ Важно донести до всех участников команды, что дейли — не единственный способ задавать вопросы и получать ответы. Ничто не мешает в течение дня назначить встречу и пригласить на нее необходимых людей.
Цель дейли — рассказать, что ты делаешь, что мешает и подсветить проблемы. Не надо постоянно рассказывать историю "Как я провёл прошлое лето". Для проверки что было вчера и чем всё закончилось есть много других инструментов.
О Качестве
Тяжело заставить других участников команды помимо QA смотреть на релиз не только через призму «успеваем или нет», но и через уровень необходимого качества на проекте. Нужно согласовать этот уровень качества со всеми участниками проекта и придерживаться его.
Помните, что тестировщик помогает вывести релиз: то есть ищет причину, почему это можно сделать, а не наоборот.
⭑ Тестирование не должно выступать в роли препятствия — оно является гарантом соответствующего уровня качества. Основная цель тестирования — предоставить информацию о состоянии релиза и дать объективную оценку, готов он или нет.
Иногда тестировщики настолько перегружены, что начинают выискивать ошибки лишь для того, чтобы выиграть время: пока разработчики будут исправлять баги, у тестировщика появится время проверить остальную функциональность.
В результате складывается впечатление, что ребята стремятся к идеальному релизу, но на самом деле просто не успевают сделать свою работу в срок.
Чек-лист для проверки
В данной статье я перечислил основные моменты, которые стоит учитывать при работе с релизами. Это не идеальный шаблон, а скорее минимальный набор действий, который доступен каждому для успешной работы.
Пройдитесь по всем пунктам моей статьи вместе с командой. Уверен, чем больше вопросов вы зададите друг другу и чем больше ответов найдете, тем успешнее будет ваш релиз.
Отдельно хочу поделиться чек-листом для тестировщиков. Сверяйтесь с ним перед каждым ежедневным митингом с командой, чтобы держать фокус во время любого релиза.
Чек-лист релиза для QA
✓ Я знаю, что должен делать сегодня.
✓ У меня есть пул задач/ошибок, которыми я могу заняться, если нет основной работы.
✓ Я знаю, когда мне отдадут задачу/ошибку в работу.
✓ Я знаю, когда и кому должен передать свою задачу/ошибку дальше.
✓ Ничто не мешает мне выполнить свою работу.
Мне хочется расширить этот список, сформировать универсальный алгоритм или даже найти более эффективный подход.
Предлагаю всем, у кого есть полезные мысли на этот счет, предложить свои чек-листы и релизные истории в комментариях. А я постараюсь сделать набор шаблонов под разные компании и команды.
