Одной из основных проблем, с которой мы столкнулись при разработке продукта - большое количество дефектов выявленных на интеграции компонентов (фронт - бэк - мобильное приложение - ОС). Причиной возникновения подобной проблемы являлось то, что разработка продукта производилась от частного к общему. При разработке фич подробно разбирались требования и тесткейсы к конкретным функциям системы, не к продукту в целом.  Для оперативного обнаружения подобных дефектов было принято решение автоматизировать сквозные тесты, или end-2-end. Ограничения состояли в том, что тестов должно быть немного, и они должны воспроизводить пользовательские сценарии, приближенные к реальным. 

В данном докладе я хочу рассказать про то, как в автоматизации end-2-end тестов может помочь аналитик, а именно, в создании сквозных пользовательских сценариев, опыту применения такого подхода. Также чем сквозные сценарии могут быть полезны для последующего определения и корректировки требований к функционалу системы. 

Одной из основных проблем, с которой сталкивается практически любая команда при переходе к гибким методологиям разработки, является отсутствие проработанных требований. Иными словами – проблема непонятного бэклога. В докладе я бы хотела рассказать о том, как мы улучшили процесс проработки требований  путем вовлечения всей команды в процесс анализа в рамках планирования спринта и встреч по уточнению бэклога продукта (PBR, grooming), а также об уточнении требований в ходе разработки. Доклад будет полезен аналитикам, менеджерам продукта, и любому участнику команды разработки в среде agile.