Наш стейджинг-контур одновременно является и сендбоксом для бордящихся кастомеров, и этого достаточно в плане клиентских данных.
В плане же интеграцией с платежными системами - они замоканы нашим мок-сервисом и/или сендбоксами этих платёжек. Моки не полностью отражают реакции продов, и поэтому иногда с продов прилетают баги, но их доля крайне мала - это как правило edge-кейсы, не дающие заметного импакта на конверсию платежей, а причина их как правило в неисчерпывающей документации или обновлениях.
Роли ратируем в команде тестирования. Обычно это анализ требований -> ручное -> покрытие автотестами. Иногда добавляется нагрузочное и секьюрити.
Да, разработка ведётся в мастере, из него собирается релизная ветка (в рамках каждого сервиса)
В день релиза релизная ветка деплоится на прод. Частичные реализации фич скрыты под флагами - разработка ведётся так, что сохранять обратную совместимость - новый код ничего не импактит, пока не будет явно активирован.
Пойду с конца)
У нас все конечно погружены в продукт - все понимают что и почему хотят в нем видеть кастомеры, и как это должно работать в качестве black box.
В первую очередь обращаем внимание то, что новая фича не должна повлиять на старые: как функционально, так и с точки зрения ИБ и производительности.
Во вторую очередь определяем основные юзкейсы, чтоб понять какие критичные моменты должны обязательно быть тщательно протестированы.
Все это и есть Тестирование требований, которое выполняется перед началом имплементации фичи.
Технически это происходит в нашем Confluence/Notion в виде комментов, дискуссий, по результатам которых аналитик корректирует Требования.
Наш стейджинг-контур одновременно является и сендбоксом для бордящихся кастомеров, и этого достаточно в плане клиентских данных.
В плане же интеграцией с платежными системами - они замоканы нашим мок-сервисом и/или сендбоксами этих платёжек. Моки не полностью отражают реакции продов, и поэтому иногда с продов прилетают баги, но их доля крайне мала - это как правило edge-кейсы, не дающие заметного импакта на конверсию платежей, а причина их как правило в неисчерпывающей документации или обновлениях.
Среди наших e2e-автотестов пока нет флаки) Будем решать эту проблему по мере поступления
Роли ратируем в команде тестирования. Обычно это анализ требований -> ручное -> покрытие автотестами. Иногда добавляется нагрузочное и секьюрити.
Да, разработка ведётся в мастере, из него собирается релизная ветка (в рамках каждого сервиса)
В день релиза релизная ветка деплоится на прод. Частичные реализации фич скрыты под флагами - разработка ведётся так, что сохранять обратную совместимость - новый код ничего не импактит, пока не будет явно активирован.
В разработке участвуют 10 разработчиков и 4 тестировшика