tgoop.com/QA_with_a_spoon/9
Last Update:
Контроль качества в FinTech - 3
Как с этим можно справиться? Если очень коротко, то примерно так.
На стадии работы с требованиями и тест-анализа:
Подходим как со стороны пользовательских сценариев и ценности для пользователя, так и со стороны ценности для бизнеса (эти две ценности могут отличаться:) . Обязательно лезем под капот. Помогают вопросы для самопроверки: могу ли я определить, какие риски могут сработать после доставки на продакшен? Как это будет проявляться? Если что-то случится, как я буду это исследовать? Как эти риски можно закрыть или смягчить?
На стадии тестирования:
Фичи в типовом случае тестируются ин-бранч и мержатся только после подтверждения со стороны QA. Это, позволяет взять фичу в тестирование максимально быстро. Также это помогает избегать возни с откатыванием изменений, если фича оказалась совсем уж плохо сделанной или вообще все сломала.
Идеальный “сдвиг влево” может не получиться в конкретном контексте. Например, если по каким-то причинам накопилась большая очередь задач. Но это то, к чему мы фоново стремимся.
Регрессионное тестирование строится на анализе рисков. На моем текущем проекте, например, около 20 000 тестов. Гонять полный регресс для каждого релиза просто невозможно, поэтому сначала оцениваем риски, затем выбираем тесты для регрессионного тестирования, которые эти риски покрывают. Автоматизированного тестирования это тоже касается. Коллега в прошлом году делал доклад на эту тему Switchboard: QAOps Swiss Knife in Action!
Обычно во время тестирования вскрываются дополнительные риски, которые могут сработать на продакшен системе - соответственно, с этими новыми рисками тоже надо что-то делать. Подсвечивать, обсуждать и в итоге закрывать / смягчать.
Когда релиз готов к доставке?
- Тестирование завершено, блокеры для доставки найдены и пофикшены
- Есть список рисков для продакшен системы
- Есть план, что делать, если тот или иной риск сработает
Конечно, это еще не все. Дальше наступает фаза саппорта, и лично я считаю ее самым большим вызовом. Только после доставки становится ясно, насколько мы действительно сделали хорошую работу. Во время анализа инцидентов наступает понимание, насколько глубоким и точным был тест-анализ, все ли мы поняли про фичу или упустили что-то важное.
Это осознание может быть довольно болезненным, но я предпочитаю смотреть это как на боли роста:)
BY Ужасно медленная QA с крайне неэффективными инструментами в поисках Грааля
Share with your friend now:
tgoop.com/QA_with_a_spoon/9