Тестирование. Находим проблемы до релиза, а не в отзывах пользователей

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

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

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

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

Прототип, насыщенный контентом, мы тестируем на людях из вашей аудитории до начала основной разработки. Смотрим, где человек останавливается, что понимает не так и какой шаг пропускает.

Правка на этом этапе стоит изменения одного экрана в прототипе. Та же правка после релиза стоит доработки, повторного тестирования и нового выката.

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

Результат — перечень найденных слабых мест с приоритетом и понятным описанием: что именно удалось сделать и к чему это привело бы.

• Ручное функциональное тестирование новой функциональности и пограничных случаев, которые не имеет смысла автоматизировать.
• Проверка по чек-листам — единый набор проверок, который проходит каждый проект, чтобы результат не зависел от того, кто именно тестировал.
• Тестирование интеграций: поведение продукта, когда внешняя система отвечает с задержкой, отдаёт ошибку или недоступна.
• Совместная работа с разработкой: на части проектов тесты пишутся до кода, по подходу TDD.
• Тестирование мобильных приложений на реальных устройствах, а не только в эмуляторе.

• Регресс перед релизом занимает несколько дней, и релизы из-за этого выходят реже, чем нужно бизнесу.
• После каждого обновления ломается что-то из старой функциональности, и находят это пользователи.
• Впереди рекламная кампания, а запас прочности системы никто не измерял.
• Автотесты когда-то написали, но они потеряли актуальность и команда давно перестала на них смотреть.
• Продукт разрабатывала другая команда и непонятно, что там вообще покрыто проверками.
• Служба безопасности требует подтверждения, что продукт проверяли на проникновение.

Разработкой и архитектурой занимается направление разработки, инфраструктурой и доставкой релизов — DevOps, приложениями — мобильная разработка. Если после тестирования нужно чинить найденное, соберём общую команду.

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