Тестирование мобильных приложений

Используется, когда провести тестирование программно дешевле и быстрее, чем вручную. Подходит не всем проектам, мы оказываем такую услугу нашим самым крупным клиентам. Например, автоматизировали тестирование DMV Genie (в семейство входит 14 приложений). Автоматизация была необходимым шагом на этом проекте, чтобы снизить стоимость тестирования в дальнейшем.

Цель: оптимизировать бюджет на тестирование и освободить время тестировщика для работы над более сложными кейсами.

Название намекает, что этот вид тестирования предполагает много ручной работы. Действительно, большинство сценариев тестировщики проходят руками. Так мы можем очень быстро получить данные о состоянии продукта и оперативно на них влиять.

Цель: получить полную картину о работоспособности продукта и вовремя отследить опасные места.

Этап проходит перед стартом разработки. Изучаем документацию и требования, проводим техническое ревью макетов.

Цель: найти ошибки в спроектированной логике до начала разработки и исправить их.

Тестирование без проектирования кейсов, на основе вводной информации по функциональности.

Цель: оперативно протестировать продукт без документации.

Составляем список тест‑кейсов по продукту. Они должны покрывать бизнес‑логику, переходные состояния, обработку ошибок.

Цель: полностью покрыть проект проверками с понятными ожидаемыми результатами, оцифровать базу знаний по проекту.

Глубинное тестирование функциональности продукта. Может понадобиться, если был сделан рефакторинг проекта.

Цель: прогон по всему проекту, по всем описанным кейсам.

Быстрый прогон по основной функциональности проекта после внесения изменений в код.

Цель: убедиться, что все базовые функции работают и новые изменения ничего не сломали.

Проверяем каждую платформу на отображение и корректный сбор аналитики и ивентов.

Цель: быстро понять, в каком именно разделе приложение работает некорректно.

Тестирование применяется, если произошли существенные изменения в базе данных и требуется проверить накат — посмотреть, как релиз-сборка ложится на ту, что опубликована в магазине приложений.

Цель: убедиться в том, что приложение способно обрабатывать информацию из новой базы данных.

Pixel Perfect — особая техника верстки, при которой сверстанные экраны на 100% повторяют макет. Сравниваем скриншоты с реальных устройств с файлом в Figma и при мельчайших расхождениях бьем тревогу.

Цель: добиться идеального совпадения макета и разработанного приложения.

Этот вид тестирования подойдет, если нет четко оформленных кейсов.

Цель: как можно быстрее протестировать продукт на предмет работоспособности.

Проверка приложения на стресс‑нагрузку.

Цель: поиск предела, после которого приложение перестаёт нормально работать.

Перед релизом проводим ревью текстов, чтобы не упустить опечатки. Проверка локализации, корректности перевода и отображения текстов.

Цель: очистить приложение от обидно сделанных опечаток и туманных формулировок.

Ревью сборки, сравниваем макеты и фактическое состояние экранов.

Цель: проверка сборки на разных устройствах на соответствие макетам.

Проверка продукта на соответствие документации API и дизайна.

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

Наблюдение за работоспособностью сервера.

Цель: убедиться что реализация API работает без ошибок.

Контроль корректного клиент‑серверного взаимодействия.

Цель: убедиться что обмен данными между клиентом и сервером происходит так, как задумано.

Проверяется вся функциональность, которая могла быть задета изменениями в продукте.

Цель: проверить, что исправление ошибок в приложении не привело к появлению других ошибок в смежных частях приложения.

Проверяем основную функциональность, которая должна работать априори.

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