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

Регрессионное тестирование на мобильном проекте — это комплексный процесс, сочетающий автоматизацию и ручные проверки для гарантии стабильности после изменений.

Типичный процесс:

1. Подготовка и стратегия:

   • Определение набора сценариев для регресса (критические пути: авторизация, платежи, основные экраны).
   • Подготовка тестового окружения: реальные устройства, эмуляторы (Android), симуляторы (iOS), облачные сервисы (BrowserStack, Sauce Labs).

2. Автоматизированный регресс (основа):

   • Ключевые E2E-сценарии автоматизируются с помощью фреймворков (Appium, Espresso, XCTest).
   • Автотесты интегрируются в CI/CD (Jenkins, GitLab CI, GitHub Actions) и запускаются на каждый билд или ночью (nightly build).

     // Пример теста на Appium + JUnit
     @Test
     public void testItemAddedToCart() {
     CatalogPage catalog = new CatalogPage(driver);
     catalog.selectItem("Coffee");
     catalog.addToCart();
     CartPage cart = catalog.goToCart();
     assertTrue(cart.isItemPresent("Coffee")); // Проверка
     }

3. Ручное регрессионное тестирование:

   • Проводится на пуле реальных устройств (разные ОС, версии, разрешения).
   • Используются чек-листы с приоритетами (P0-P2), хранящиеся в TestRail или Qase.
   • Особое внимание уделяется областям, затронутым изменениями, и смежному функционалу.

4. Нефункциональные проверки:

   • Производительность (запуск приложения, отклик).
   • Совместимость (работа на разных версиях ОС, размерах экрана).
   • Безопасность (хранение данных, передача по сети).

5. Анализ результатов и отчётность:

   • Все найденные дефекты заносятся в баг-трекер (Jira) с подробными логами, скриншотами и видео.
   • Результаты автоматических прогонов анализируются, при необходимости тесты дорабатываются.

Ключевые метрики: процент автоматизации критических путей, время выполнения регресса, количество обнаруженных регрессионных багов.