Тестирование без сюрпризов в проде

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

• Функциональное тестирование. Проверяем, что продукт делает то, что описано в требованиях: регистрация, оплата, заявки, роли и права. Нужно всегда — с этого начинается любой процесс контроля качества.
• Регрессионное тестирование. После каждого изменения проверяем, что не сломалось то, что раньше работало. Становится критичным, когда релизы выходят часто, а продукт разросся настолько, что никто не помнит все связи между модулями.
• Нагрузочное тестирование. Выясняем, сколько пользователей и операций выдержит система и что сломается первым. Нужно перед запуском, рекламной кампанией, стартом продаж или переездом на новую инфраструктуру.
• Тестирование производительности. Смотрим на скорость: время ответа сервера, загрузку экранов, расход памяти и батареи в мобильном приложении. Медленный продукт теряет пользователей так же, как сломанный.
• Тестирование интеграций и API. Проверяем обмен с CRM, 1С, платёжными и внешними сервисами: корректные данные, обработку ошибок, повторные запросы. Именно здесь чаще всего прячутся ошибки, которые не видны в интерфейсе.
• Тестирование мобильных приложений. Разные версии iOS и Android, размеры экранов, плохая связь, сворачивание приложения посреди сценария, обновление со старой версии. Набор устройств согласуем под вашу аудиторию.
• Автоматизированное тестирование. Повторяющиеся проверки переводим в автотесты, которые запускаются при каждом изменении кода. Окупается, когда продукт живёт долго и регулярно обновляется.

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

Дальше процесс выглядит так:

1. Составляем тест-план: что тестируем, какими видами проверок, на каких окружениях и устройствах, по каким критериям считаем релиз готовым.
2. Пишем тест-кейсы и чек-листы на ключевые сценарии — так проверки повторяемы и не зависят от памяти конкретного человека.
3. Тестируем каждую задачу перед тем, как она попадёт в релиз, и заводим дефекты в вашем трекере с шагами воспроизведения, ожидаемым и фактическим результатом, скриншотами и логами.
4. Перед релизом проводим регрессию по критичным сценариям, после выкладки — быструю проверку, что основные функции работают в бою.
5. По итогам релиза даём короткий отчёт: что проверено, какие дефекты открыты и насколько они критичны.

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

Нагрузочное тестирование начинается не с инструментов, а с вопроса бизнеса: какой наплыв пользователей ожидается и что для вас считается провалом. Старт продаж, рассылка по всей базе клиентов, рекламная кампания — у каждого события свой профиль нагрузки.

• Профиль нагрузки. Вместе с вами описываем сценарии пользователей и их долю: сколько просматривают каталог, сколько оформляют заказ, сколько заходят в личный кабинет.
• Отдельное окружение. Нагружаем тестовый стенд, максимально похожий на боевой, чтобы не уронить работающий продукт. Если тест нужен на продакшене — согласуем окно и сценарий отката.
• Поиск узких мест. Смотрим, что ломается первым: база данных, внешние API, очереди, кэш, сервер приложений.
• Отчёт. При какой нагрузке начинаются ошибки и замедления, где узкое место, что исправить в коде и инфраструктуре и как проверить результат повторным тестом.

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

• Автоматизируем стабильные и критичные сценарии: вход, оплату, оформление заявки, расчёты, обмен данными с внешними системами.
• Оставляем ручным то, что быстро меняется, и то, где нужен человеческий взгляд: новый интерфейс, удобство сценариев, вёрстку на редких устройствах.
• Строим пирамиду тестов: больше быстрых проверок на уровне логики и API, меньше медленных сквозных тестов через интерфейс.
• Встраиваем в CI/CD: автотесты запускаются при каждом изменении кода, и сломанная сборка не доходит до релиза.

Код автотестов хранится в вашем репозитории и передаётся вам вместе с документацией — поддерживать его сможет любая команда.

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

• Прерывания. Входящий звонок, сворачивание, блокировка экрана посреди оплаты или заполнения формы — данные не должны теряться.
• Связь. Медленный интернет, переход с Wi-Fi на мобильную сеть, полное отсутствие сети: приложение должно понятно сообщать, что происходит, и не дублировать операции при повторной отправке.
• Разрешения. Что будет, если пользователь запретил доступ к камере, геолокации или уведомлениям, а потом передумал.
• Обновления. Установка новой версии поверх старой без потери входа и локальных данных, работа с принудительным обновлением.
• Уведомления и глубокие ссылки. Пуш открывает нужный экран, ссылка из письма или мессенджера ведёт в приложение, а не на главную.
• Требования магазинов. Перед отправкой на модерацию в App Store, Google Play и RuStore проверяем то, из-за чего сборки чаще всего возвращают: тексты о данных пользователя, тестовый доступ для модераторов, корректные описания разрешений.

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

Отдельный тестировщик нужен не каждому продукту с первого дня. Но есть признаки, по которым понятно, что проверки силами разработчиков больше не справляются:

• о дефектах вы узнаёте от пользователей, из отзывов в магазинах приложений или от службы поддержки;
• после каждого релиза что-то ломается в местах, которые никто не трогал;
• команда боится выпускать обновления и откладывает релизы, чтобы «ещё раз всё посмотреть»;
• продукт работает с деньгами, персональными данными или юридически значимыми документами;
• впереди событие с наплывом пользователей: запуск, старт продаж, рекламная кампания;
• над продуктом работают несколько команд или подрядчиков, и никто не отвечает за качество целиком.

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

Спор «можно выпускать или нет» снимается, когда критерии готовности записаны заранее. Вместе с вами фиксируем, какие сценарии обязаны пройти проверку, дефекты какой критичности блокируют релиз, а какие можно исправить в следующем обновлении.

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

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

Каждый дефект описываем так, чтобы разработчик мог воспроизвести его без вопросов: окружение и устройство, шаги, ожидаемый и фактический результат, скриншот или запись экрана, фрагмент логов. После исправления проверяем дефект повторно и закрываем его только тогда, когда он действительно не воспроизводится.

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

• тест-план и стратегия тестирования продукта;
• тест-кейсы и чек-листы на ключевые сценарии;
• дефекты в вашем трекере с понятными шагами воспроизведения;
• отчёты о готовности релизов;
• отчёт нагрузочного тестирования с узкими местами и рекомендациями;
• автотесты в вашем репозитории и инструкция по их запуску.

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