«Ранее я рассказывала о проблемах позднего тестирования и других антипаттернах. Сейчас я подробнее расскажу о проблемах, поделившись примером из собственного опыта. В какой-то момент моей карьеры QA-команда, которой я руководила, начала цикл тестирования, отстающий от Dev-команды примерно на восемь недель. И то что начиналось как небольшое двухнедельное отставание, вскоре превратилось в большую проблему.
Что случилось
Когда мы переходили на Jira, вице-президент по инжинирингу хотел использовать спринты для отслеживания только задач по разработке. Ему нужны были красивые графики, показывающие, что его участок компании выполняет работу в срок.
Чтобы удовлетворить это пожелание, мы создали в Jira собственные QA-спринты. Как только команда разработчиков заканчивала двухнедельный спринт, они передавали нам релизный пакет. Мы проводили свой собственный двухнедельный QA-спринт, а затем код передавали в продакшен. Поскольку до этого у нас соблюдался более-менее регулярный ежемесячный график деплоя, все это казалось осуществимым. (Читатели, я уверен, что некоторые из вас уже видят у себя в компании подобные проблемы.)
Проблемы
Поначалу все было нормально, но со временем мы начали все больше и больше отставать. Это было связано с несколькими причинами, но основную роль сыграли релизы, которые требовали больше времени из-за трудности изменений и длительного ожидания багфиксов.
- Затраты труда на разработку и тестирование коррелируют часто, но не всегда. То, что можно написать за две недели, не всегда получается протестировать за две недели.
- После передачи кода разработчикам QA-отдел был вынужден долго ждать исправления багов, которые не были запланированы в текущем спринте разработки. Эти простои были непредвиденными для QA-команды.
- Остановка текущей работы для исправления багов в нескольких предыдущих релизах приводила к тому, что разработчикам приходилось переключать свой контекст.
- По мере увеличения этого разрыва, проходило все больше времени с тех пор как разработчик первоначально работал над данным кодом. Каждый баг требовал все больше времени на исправление, поскольку этот код уже не был свеж в памяти разработчика. Помните, чем раньше вы сможете выявить и исправить баг, тем меньше затрат он создаст (стоимость дефекта растет кратно по мере продвижения к релизу).
- А поскольку мы (QA) должны были осваивать также и будущие фичи, над которыми нам предстояло работать, нас часто прерывали для участия в дизайн-ревью того, над чем команда разработчиков работала в данный момент, даже если до тестирования должно было пройти больше месяца. Это означало много переключений контекста и для QA-команды.
- В их Определении «Готово» (DoD) отсутствовало тестирование! Что толку от диаграммы оставшейся работы, показывающей в Jira истории как Выполненные, если никто не проверил, что этот код действительно работает? Если этого кода не будет на проде еще восемь недель?
- За каждый двухнедельный спринт команда разработчиков создавала ветку релиза и развертываемый пакет релиза. Таким образом, когда мы отставали на восемь недель, это равнялось примерно четырем релизам. Если разработчики работали над версией N, QA-команда тестировала версию N-4. Когда требовалось исправить баг, разработчикам приходилось сливать исправление в каждую ветку релиза от N-4 до N. А для хотфикса требовалось еще одно слияние.
- Когда менеджеры по продукту совместно с руководством планировали, над чем работать дальше, эти функции не доходили до прода в течение 8-10 недель, даже если разработка могла быть выполнена в течение двухнедельного спринта.
Решение
Мы с руководителем команды разработчиков стремились сократить избыточность и неэффективность переключения контекста и быстрее доводить код до прода. Мы также хотели привести команды в соответствие с графиком выпуска мобильных релизов, которые выходили каждые две недели, а работы по разработке и QA проводить в рамках одного спринта.
Изменения, которые мы внедрили:
- Мы создали родительский спринт в Jira для каждого релиза, а спринты по разработке и QA — как дочерние спринты. Это позволило вице-президенту по инжинирингу вести свои графики отдельно для каждой из команд. (Примечание: это не оправдалось, и в конечном итоге мы отказались от него в пользу единого спринта с подзадачами разработки и QA).
- Мы начали добавлять QA-сторипойнты к каждой истории и проводить такое же планирование емкости как и со стороны разработки, для каждого спринта.
- К каждой истории были добавлены Критерии приемки.
- Мы изменили Определение «Готово» (DoD), включив в него тестирование. Если история не была протестирована, она не считалась готовой. Это означало, что история могла не попасть в релиз-пакет спринта, если тестирование не было завершено. Если такое случалось, ее пересматривали и включали в будущий спринт.
- Все скрам-ритуалы включали разработчиков и QA, а не только разработчиков. Мы ликвидировали отдельные стендапы и ретро для QA и объединили их с разработчиками.
Мы считали, что эти изменения необходимы для того, чтобы обе команды (разработчики и QA) работали вместе в одном спринте, выпуская релиз каждые две недели. Мы получили согласие техдиректора на эти изменения. Однако наверстать упущенное было сложно, пока мы отставали на четыре релиза. Чтобы это сработало, нам нужно было отправить последний релиз, над которым работали разработчики, а затем начать новый спринт с новым процессом.
Чтобы наверстать упущенное, целый спринт был выделен в основном на дизайн и ресерч со стороны разработчиков. Разработчики также должны были оперативно исправлять баги; мы даже попросили их принять участие в тестировании. Это было нелегко, но в итоге мы достигли цели.
Резюме
Как видите, многие проблемы в процессах приводили к тому, что тестирование опаздывало.
В конечном итоге наиболее заметными проблемами были плохое сотрудничество и плохая коммуникация между разработчиками и QA из-за отдельных спринтов, графиков и скрам-ритуалов, а также множество неэффективных действий, связанных с переключением контекста и временем между коммитом кода и его передачей в прод.
Вот некоторые метрики, которые мы потом использовали для измерения и отслеживания улучшений по мере итерации наших процессов:
- Время подготовки изменений (одна из ключевых метрик DORA): Раньше время подготовки изменений было очень высоким (восемь недель). Затем мы снизили этот показатель до менее чем двух недель, так как большинство кода развертывалось в конце спринта.
- Частота деплоя (также одна из метрик DORA): Раньше этот показатель был ниже желаемого (раз в месяц или реже). После этого мы постоянно выходили на целевое время развертывания каждые две недели, за несколькими (запланированными) исключениями.
- Время восстановления после неудачного деплоя (и еще одна метрика DORA): Хотя мы ранее не отслеживали этот показатель, по некоторым данным он стал лучше. Намного проще стало определить причину неудачного деплоя, если мы деплоили самый последний пакет релиза, а не отставали на много версий.
- Потенциал (емкость) спринта: После того как мы осуществили описанные выше изменения и привыкли к ним, мы увидели, что у нас увеличился объем работы в каждом спринте, как у разработчиков, так и у QA. Вероятно, это связано с меньшим количеством переключений контекста и меньшими усилиями по исправлению багов, обнаруженных ближе к моменту исправления.
- Процент отказов от изменений (также одна из метрик DORA): Еще один показатель, который мы изначально не отслеживали. Однако позже мы начали отслеживать его и использовать в качестве одной из метрик качества. У нас в офисе была большой дашборд со счетчиком «Days Since», который показывал количество дней, прошедших с момента возникновения серьезной проблемы/бага в продакшене. Нашей целью было поддерживать это число на высоком уровне.
А вам стоит обсудить:
- Приходилось ли вам работать в команде, где тестирование значительно задерживалось? Как это повлияло на ваш проект, и какие решения вы применяли для решения этой проблемы?
- Как ваша команда справляется с исправлениями багов из предыдущих релизов во время текущих спринтов? Какие методы вы использовали, чтобы минимизировать переключения контекста?
- Как ваша команда понимает Определение «Сделано» (DoD) для истории или задачи? Включаете ли вы в это определение тестирование, и если да, то как оно повлияло на ваш рабочий процесс?
