:)

Посмотрел доклад от Miro: Качество релизов - ответственность команды

В этом докладе описан лучший процесс разработки и тестирования, который я когда либо видел, поэтому я рекомендую его посмотреть всем.
https://youtu.be/H8nnlOOlNI0?t=17998


Старый процесс (shift-right):
- QA тестирует каждый Jira issue
- QA релизит в прод
Минусы:
- работает только в маленькой команде
- работает если релизы редко

Новый процесс:
- команда разработки: 5-6 человек, из них 1 QA
- новые задачи документируются перед разработкой, в т.ч. как будет разрабатываться, тестироваться и деплоиться
- новые задачи разбирается с помощью Example Mapping'a
- review задачи всей командой а-ля три амиго
- по Example Mapping'a пишутся тест-кейсы
- тесты пишут сразу(!) специально планируют под это время(кстати зачем? есть какая-то неуверенность нужно это делать или нет?)
- тесты всех уровней, юниты, интеграционные, e2e
- разработчик выполняет простые проверки
- чтобы у команды хватало ресурсов на выполнение тестирования, команды были доукомплектованы разработчиками (!)
- разработчик запрашивает помощь QA только при необходимости
- тестирование в команде распределено между всеми участниками:
-- Example Mapping (QA, PO)
-- Test Cases (QA)
-- Test Methods (QA)
-- Test Cases (QA)
-- Create Tests (DEV)
-- Run manual test cases (DEV)
-- Exploratory testing (QA)
-- UX-testing (UX/UI designer) (а в каждой команде есть дизайнер?)
-- Task compliance (PO) (Соответствие реализации и постановки задачи)
- по выполнению задачи команда проводит демо в два этапа: внутреннее(1) потом для PO(2)
- PO проверяет позитивные сценарии (а у него время для этого есть?), QA проверяет негативные сценарии
- задача релизится и мониторится командой
- автоматизировали ручной регрес чтобы релизить быстрее с помощью e2e тестов
- релевантные автотесты выполняются на каждую ветку на каждый Pull Request
- все автотесты выполняются только на master
- можно запустить кастомный набор тестов на ветку (e2e тесты медленные, да?)
- e2e всё таки очень медленные, поэтому увеличиваем количество железа
- все автотесты выполняются за 25-30 минут 600-700 тестов
- используют Allure EE

Имплементация нового процесса заняла 6-12 месяцев.

Сравнение старого и нового процесса разработки:
Фича1 сделанная по старому процессу
- 15 багов за 4 месяца после релиза: 8 Major, 8 Minor, 1 trivial
- Lead Time ~6 месяцев
Фича2 сделанная по новому процессу
- 7 багов за 4 месяца после релиза: 4 MAjor, 3 Minor
- Lead Time ~3 месяца
Фича1 и Фича2 примерно одинаковаые по размеру и сложности.


Описание инфраструктуры Miro:
- более 200 серверов в AWS
-- из них 50-100 серверов с java-приложением

Есть отдельная QA команда, которая консультирует как сделать тесты более эффективными

Описание процесса релиза
- релизы делятся на бекендовые и фронтендовые
- релизы каждый день
- релизы бесшовные
- канареечные релизы
- скорость выкатки канареечного релиза после мержа 5-6 часов
- используется GitLabFlow для Hotfix'ов
- команда сама может инициировать канареечный или обычный релиз
- активный мониторинг канареечного релиза дежурным инженером 4 часа после релиза в Grafana и Sentry
- нотификации в Slack релевантным командам о начале и статусе релиза
- саппорт скидывает проблемы в Slack-каналы команды
- статистика собирается в Jira и Bamboo и анализируется в Looker

Dogfooding
- есть внутренний инстанс  Miro для сотрудников, который обновляется после каждого мержа в master

Очень круто, спасибо! Правда зачем теперь смотреть доклад :)

Там девочка рассказывает, можно на девочку посмотреть :)

🧐 Звучит как сексизм

Да, я смотрю со своей колокольни

Мда, пожалуй... Ладно, тогда серьезно: исходный источник информации всегда лучше, чем чей-то пересказ. Олег ведь обращает внимание на те моменты, которые интересны ему.

А вообще, наверное, взгрустну, что у кого-то в очередной раз получился шифт лэфт, а я тем временем прошу разрабов декомпозировать задачи в 3 дня и занимаюсь "реверс-инженерингом" каждой задачи, после того как она прилетает мне на тестирование 😢

А вообще, наверное, взгрустну, что у кого-то в очередной раз получился шифт лэфт, а я тем временем прошу разрабов декомпозировать задачи в 3 дня и занимаюсь "реверс-инженерингом" каждой задачи, после того как она прилетает мне на тестирование 😢

Хм... Я наверное, слишком наглый тестировщик, но я приходила к разрабам всегда и спрашивала "расскажи как это работает у тебя там внутри?" И они рассказывали 🤔

Да я тоже хочу и выуживаю эту инфу, но по-моему это тоже неправильно :)

А вообще, наверное, взгрустну, что у кого-то в очередной раз получился шифт лэфт, а я тем временем прошу разрабов декомпозировать задачи в 3 дня и занимаюсь "реверс-инженерингом" каждой задачи, после того как она прилетает мне на тестирование 😢

Да я тоже хочу и выуживаю эту инфу, но по-моему это тоже неправильно :)

/to do плакать

а они не оставляют никаких DoD, в задаче никакого описания?