рост не обязан быть вертикальным :) в данном контексте это накопление специфических навыков, позволяющих перейти в другую роль

у нас это Program Manager :))

Оу... Такого я еще не слышала)

Интересно, теперь я хоть понял что это за горизонтальные росты такие.😅

Посмотрел доклад от Leroy Merlen про тестирование микросервиса.

Сразу отмечу, что Leroy Merlen использует отдельных автоматизаторов, что уже является плохой практикой.
Подтверждается фразой "у сервиса всего 17 end-point'ов, половина не покрыта тестами", на этой фразе прикольно было следить за участливым покер-фейсом Ерошенко :-)

нет shift-left, тестирование отдельно от задачи, сначала сделали сервис, потом передали в тестирование подтверждается тем что
- Фaктически пришлось делать reverse engineering
- после reverse engineering выяснили что реализация имеет проблемы, пришлось переделывать и сервис, и тесты

Сервис - прокси без логики.

В докладе замечено что
- ад сервисов
- нет мониторинга
- нет трейсинга
- нет обсервабилити

Из доклада не известно как часто этот сервис должен релизиться.

Сразу взялись за end to end тесты, можно было радикально упростить тестирование используя тест "среднего" уровня, как например Laravel Feature Tests или Symfony Functional Tests

Не подумали о времени выполнения тестов.

Использовали кастомный фреймворк на базе TestNG и wiremock
Использовали техники Control Flow Testing.
Используют моки ответов от других сервисов. Опять же, уже давно не новость, что эта практика плохая, потому что тесты будут тестировать моки, а не интеграцию.
Не понятно проверяют ли что были запросы в моки когда нужно и не было когда не нужно, надеюсь wiremock умеет это по-умолчанию из коробки и свалит тест в этих случаях.
Двигаются в сторону контрактного тестирования, но что мешало делать контрактное тестирование сразу?

Проблему Ада микросервисов никак не решили, делают документацию которая завтра устареет.
Можно было использовать TLC/PlusCal для моделирования работы сервиса и поиска проблемных edge-cases.

Подход к тестированию описанный в докладе не масштабируется, уже через 2, 3, 4 новых сервиса это всё встанет колом. И боттлнеком будет тестирование!

Вопрос из зала вскрыл что уже намечается проблема с масштабированием и подход с моками подложит хорошую свинью, когда все команды тестируют какие-то свои моки и рели одного сервиса, накроет медным тазом всю систему.

В целом отрадно, что Leroy Merlen отбил у французиков бюджет на отдельный IT департамент. Всё в дом. :-)

Пардоньте за флуд, но может кто знает, айтишечка в Иркутске жива вообще? хоть 1 сообщество или митапы имеются?

О, мне тоже интересно

Я как то искал какие-то митапы, все было довольно грустно

@oneumyvakin Привет) а можешь накинуть какую-нибудь статью про контрактное тестирование или может доклад какой хороший есть? а то гуглится оно как-то тяжеловато

@onhorou https://www.youtube.com/watch?v=OCoKgXeNSS8

не видел, спасибо)

Ссылка есть?

Посмотрел доклад от 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

Спасибо за изложение!
Интересно, как у них работает отдельная консультирующая QA команда.

> чтобы у команды хватало ресурсов на выполнение тестирования, команды были доукомплектованы разработчиками (!)
вот это топ, я б тоже так делал)

"Старый процесс (shift-right)"
разве shift right - это не про мониторинг/тестирование и вообще проверку гипотез по данным с прода? Типа часть "усилий по тестированию" уходит налево и это shift left, часть - направо - и это shift right.

Тебе просто интересно или прям надо найти кого-нибудь? Если найти, то есть чат https://t.me/it_events_organizers и ещё DevRel Community, куда нет ссылки, но я могу инвайт кинуть.

@rseek я про это думаю так, если мониторингом новой фичи которую только что выкатили занимаются разработчики, то для меня в 2020 году это всё еще shift-left. По сути мы не знаем готова фича или нет и из разработки она еще не вышла.

shift-left? Что-то у меня не сходится

Спасибо. Ну я как бы тут и плесенью покрываться не хочется

всё относительно и меняется во времени, для меня (лично для меня) это всё еще left, потому что я считаю что фича которая только что уехала в прод канареечным релизом и активно мониторится разработкой еще не готова.