Как вы организуете процесс выпуска с учетом тестирования
Что проверяют
Представляете ли вы релиз мобильного приложения целиком, от ветки до процента пользователей в Google Play. Главное отличие от веба: откатить установленную версию нельзя, поэтому проверки и постепенная раскатка важнее, чем где-либо. Следом спрашивают, что вы делаете, если после релиза вырос crash rate.
Как отвечать
Это вопрос про ваш опыт, поэтому опишите процесс своей команды по шагам и приведите свои цифры: частоту релизов, долю раскатки, длительность регресса. Если процесс выстраивали не вы, так и скажите и расскажите, за какую часть отвечали. Каркас:
- ветки: trunk-based разработка с короткими ветками или релизная ветка с заморозкой на время регресса. Незаконченные фичи закрыты флагами (Firebase Remote Config или свой сервис);
- CI на каждый merge request:
./gradlew lint, detekt или ktlint, юнит-тесты (testDebugUnitTest), по возможности скриншотные тесты (Paparazzi, Roborazzi). Инструментальные тесты на Espresso гоняют на эмуляторах через Gradle Managed Devices или в Firebase Test Lab; - релизная сборка: AAB с включённым R8 проверяется отдельно, потому что минификация ломает рефлексию и сериализацию, а в debug её нет;
- сборки для QA: Firebase App Distribution или внутренний трек Play Console, ручной регресс по чек-листу критичных сценариев;
- выпуск: закрытое тестирование, затем staged rollout с небольшого процента и расширение, пока Crashlytics и Android vitals спокойны;
- реакция: при росте падений раскатку останавливают в Play Console, фичу выключают флагом, исправление выходит хотфиксом с большим
versionCode.
Где спотыкаются
Тестируют только debug сборку. Падения из-за R8, другого applicationId или отсутствующих ключей всплывают уже у пользователей.
Выпускают сразу на 100%. Вернуть прошлую версию на телефоны нельзя, остаётся только догонять хотфиксом.
Рассказывают шаблонную историю с «ускорили релизы на 40%» и не могут объяснить, как это считали. Лучше меньше цифр, но свои, и конкретика по инструментам, которыми вы пользовались сами.