#рабочийпроцесс #релиз
Релиз менеджмент или управление релизами.
В каждой команде рано или поздно встаёт вопрос о том, как лучше релизиться - лучше и для команды и для пользователей и для бизнеса. Почему я решила об этом написать в канале про тестирование? Тестировщики, как правило, принимают непосредственное участие в релизных процессах и нередко берут на себя роль релиз-менеджера.
Расскажу об основных подходах, с которыми сталкивалась в работе или слышала от коллег и накопала материалов. Это будет серия постов с тегом #релиз, в каждом посте будет рассказано про один из подходов. Пишите в комментах про какие релизные подходы и практики вы слышали и/или хотели бы узнать подробнее.

#рабочийпроцесс #релиз

Релиз по расписанию.
Основной принцип: есть согласованный командой и бизнесом релизный календарь с определенной периодичностью релизов (раз в две недели, например). Задачи, которые войдут в релиз могут заранее планироваться с определенной вероятностью, но финальное решение по вхождению определенных задач в релиз принимается в день отсечки релизной ветки исходя из готовности задач.
Как выглядит процесс: есть определенные даты-отсечки (согласно тому же календарю), в которые решается, какой скоуп задач войдет в ближайший релиз, т.е. что уже готово к регрессу. В эти даты отсекается релизная ветка и туда больше никакие новые задачи не вносятся (даже если очень хочется, даже если прям очень-очень хочется, ну ладно, только маленькую срочную багулечку, так и быть). На этой ветке проводится регрессионное тестирование и если всё хорошо, в условленную дату ветка льётся в прод.
Подводные камни: бывает, что возникают какие-то неурядицы и релиз задерживается на день-два-неделю и тут нужны договорённости в команде что с такими ситуациями делать. Могут быть, например, такие варианты:
1. релиз во вторник, если не успеваем, то максимум в четверг. Если не успели к четвергу, то релиз сгорает и к следующей календарной релизной дате готовится уже новый релиз согласно релизному календарю
2. релиз во вторник, максимум в четверг. Если возникли сложности, то ищется задача, из-за которой они возникли и выпиливается из релиза, после чего проводится смоук и релиз едет в прод, а проблемная задача едет в следующий релиз
Задача тестировщика: вовремя давать обратную связь по задачам, которые планируются в релиз и вовремя давать обратную связь по регрессу
Задача релиз-менеджера (не технического):
1. следить, чтобы на запланированных в релиз задачах был проставлен соответствующий релиз
2. следить, чтобы задачи, выпадающие из релиза лишались отметки релиза/переносились в следующий релиз
3. следить, чтобы в назначенный день все готовые к релизу задачи были слиты в релизную ветку, а не готовые НЕ слиты!!
4. следить, чтобы в релизную ветку не добавлялись новые задачи после отсечки
5. отслеживать степень готовности релизной ветки к выпуску и вовремя предпринимать нужные действия, чтобы выпустить релиз в срок
6. при необходимости готовит материалы для оповещения бизнесу по релизнутым задачам и релиз ноутс для пользователей

P.S. привела примеры, когда релиз во вторник, потому что считаю этот день наиболее приемлемым по нескольким причинам:
1. до пятницы еще далеко, так что если релиз не получится во вторник, можно релизнуть в среду или даже в четверг
2. уже не понедельник, так что схема в идеале такая: регресс заканчивается в пятницу, в понедельник проводятся подготовительные тех.работы (и заканчиваются последние проверки, которые не успели в пятницу) и во вторник релиз
4. почему не стоит релизить в пятницу - думаю не надо объяснять, но если надо - напишите в комментариях 😊

#общее #собеседование

И снова статья с моим участием, на этот раз про собеседования джунов-тестировщиков: https://practicum.yandex.ru/blog/kak-proyti-sobesedovanie-na-testirovschika/

Есть вопросы-пожелания-предложения? Пиши в комменты! 😊

P.S. картинка традиционно странная 😅

#рабочийпроцесс #релиз

Релиз по скоупу задач.
Основной принцип: после/перед/во время каждого релиза происходит планирование следующего. Со всеми сторонами согласовывается чёткий список задач, которые будут выпущены в следующем релизе и очень примерные сроки этого релиза. Когда оговоренные задачи готовы, происходит отсечка релизной ветки и никакие другие задачи в неё не входят.
Как выглядит процесс: во время планирования релиза задачи набираются из беклога команды, обсуждаются, примерно оцениваются, исходя из этого даётся примерный срок выпуска релиза (тут лучше всего оговаривать три варианта: оптимистичный, пессимистичный и нормальный). Ко времени, когда все задачи готовы (разработаны и протестированы), отсекается релизная ветка. Важно, чтобы новые, не оговоренные задачи, не входили в релиз, чтобы не происходило раздувание скоупа и усложнение регресса. На релизной ветке проводится регресс, вносятся правки обнаруженных багов и если всё хорошо, ветка льётся в прод (тут хорошо бы проводить ретро по релизу и смотреть попали ли мы в оценки и сроки и если нет, то почему и как в следущий раз оценивать точнее).
Подводные камни: бывает, что возникают какие-то срочные задачи, которые не вошли в релиз и такие моменты стоит заранее проговорить и зафиксировать правила, например, золотое правило: "впихивая невпихуемое выпихивается ранее впихнутое", т.е если надо добавить срочную задачу, то какую-то другую, аналогичную по оценке задачу мы из скоупа убираем.
У этого подхода довольно высокий риск скатиться к хаотичным релизам (про них напишу позже).
Задача тестировщика: примерно такая же, как и всегда - вовремя давать обратную связь по задачам, которые планируются в релиз и вовремя давать обратную связь по регрессу.
Задача релиз-менеджера (не технического):
1. следить, чтобы на запланированных в релиз задачах был проставлен соответствующий релиз
2. следить, чтобы команда занималась только релизными задачами или техническими, если релизные закончились
3. договариваться с заказчиками про "внезапные срочные" задачи и вовремя выпихивать ещё не начатые задачи, добавляя на их место "срочные"
4. следить, чтобы в нужное время все релизные задачи были слиты в релизную ветку, а не релизные НЕ слиты!!
5. отслеживать степень готовности релизной ветки к выпуску и работать с рисками, угрожающими затянуть релиз.
6. при необходимости готовить материалы для оповещения бизнесу по релизнутым задачам и релиз ноутс для пользователей.

P.S. ещё раз напомню, что в пятницу и перед праздниками лучше не релизиться 😅
Ну и моё мнение - релизы по скоупу задач чаще всего превращаются в хаотичные, мне приятнее работать либо с календарными релизными, либо без релизов (позадачный выпуск в прод).

Не знаю такой ли славы я хотела, но это было неожиданно 😂

#рабочийпроцесс #бесплатное

По следам доклада из предыдущего поста написала статью: кому неудобно смотреть, можно прочитать 😊
https://habr.com/ru/companies/sportmaster_lab/articles/760576/

#общее #рабочийпроцесс

Удачная выдалась неделя! Выложили подкаст, в котором я приняла участие. Выпуск посвящен работе тестировщика и в частности моей работе куратора в Спортмастере, обсудили с Арсением разные интересные вопросы, было здорово, с удовольствием поучаствую и в других подкастах, мне понравилось! 😊
https://t.iss.one/RedBarn_ru/3807

#общее #рабочийпроцесс

А пока пишется следующий пост про релизы, вышло моё интервью у Лёши Пименова с нетипичными вопросами о тестировании и тестировщиках 😊
https://youtu.be/XqKsXKXyABA?si=dRLYJ5fwUJHVmLwS