Опишите процесс проведения регрессионного тестирования на мобильном проекте.

О, регрессионное тестирование на мобилках, да? Ну это ж святое дело, блядь! Это когда ты уже всё сделал, выпустил новую фичу, а потом сидишь и боишься, что твой же код, как пьяный слон в посудной лавке, наебнул всё, что работало до этого. Задача — не дать этому слону разгуляться, вот и весь процесс, ёпта.

Как мы это обычно делаем, или «Танец с бубном вокруг телефона»:

1. Сначала думаем головой (редко, но бывает):

   • Решаем, что будем проверять. Не всё подряд, блядь, а самое важное — чтобы пользователь мог залогиниться, купить что-нибудь и не послать тебя нахуй из-за вылетающего главного экрана. Это и есть «критические пути».
   • Готовим «полигон»: настоящие телефоны (куча их, разных), эмуляторы (для андроида) и симуляторы (для этих ваших яблочных). А если своих девайсов дохуя, то гоняем в облаках типа BrowserStack — удобно, но иногда медленно, как черепаха в патоках.

2. Автоматизируем, чтобы не сойти с ума:

   • Самые важные сценарии пишем в автотесты. Используем Appium, Espresso, XCTest — кому что ближе. Потом эти тесты встраиваем в пайплайн (Jenkins, GitLab CI) и они сами запускаются на каждый новый билд. Ночные прогоны — вообще маст хэв, утром приходишь, а тебе уже отчёт: «Всё ок» или «Иди сюда, мудак, тут пиздец».

     // Вот смотри, как это примерно выглядит. Просто и понятно.
     @Test
     public void testItemAddedToCart() {
     CatalogPage catalog = new CatalogPage(driver);
     catalog.selectItem("Coffee"); // Выбрали кофе
     catalog.addToCart(); // Добавили в корзину
     CartPage cart = catalog.goToCart(); // Перешли в корзину
     assertTrue(cart.isItemPresent("Coffee")); // А он там? Если нет — тест провален, иди ищи баг.
     }

3. Ручные проверки, или «Доверяй, но проверяй своими руками»:

   • Автотесты — это круто, но они не всё видят. Поэтому берём в руки реальные телефоны — старые, новые, большие, маленькие — и начинаем тыкать. По чек-листам, которые лежат в TestRail. Особенно тыкаем туда, где что-то меняли, и вокруг этого места. Потому что баги, они как тараканы — любят вылезать из-под плинтуса соседней комнаты.

4. Проверяем, не тормозит ли и не разваливается ли:

   • Смотришь, чтобы приложение запускалось не за три века. Чтобы на старом андроиде не глючило. Чтобы данные не светились всем подряд в сети. Это называется нефункциональное тестирование, и его тоже забывать нельзя, а то пользователи разбегутся, блядь.

5. Разбор полётов:

   • Если что-то сломалось — не просто орем «Работай, сука!», а пишем баг в Jira. Обязательно со скринами, видео, логами — чтобы разработчик не пришёл и не сказал «А это у тебя на девайсе глючит, иди перепрошейся».
   • Смотрим на отчёты автотестов. Если они начали падать как мухи — значит, пора их чинить или переписывать. Цикл жизни, блядь.

А в итоге смотрим на цифры: сколько у нас главных тестов автоматизировано, сколько времени весь этот регресс жрёт, и сколько новых багов мы нашли ТОЛЬКО из-за того, что кто-то «чуть-чуть поправил» код. Вот тогда и понимаешь, что оно того стоило, и можно идти пить кофе. Или виски. Зависит от количества найденных багов.