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