Функциональное тестирование — это как страховка для продукта, способ убедиться, что приложение реально работает так, как задумано. Если тестирование проведено поверхностно, пользователи найдут баги быстрее, чем успеешь сказать «релиз». Сегодня разбираемся, как тестировать web и мобильные приложения так, чтобы не проспать критичные ошибки.
Начни с вопросов, а не с кликов
Перед тем как запускать тест-кейсы, стоит разобраться: а как вообще должен работать продукт? Бизнес-логика, крайние случаи, возможные сбои — если тестировщик этого не понимает, тестирование превращается в игру «угадай, что тут не так». Сначала важно понять, как всё должно работать. Для этого изучаем документацию, требования и мучаем аналитика. И, кстати, вопросы задавать — это не стыдно, а круто! Аналитика все-таки найдите 😁
А если требований нет?
Такое бывает, особенно на старте разработки или в хаотичных проектах. Либо они где-то в параллельной вселенной параллельно пишутся. В этом случае тестировщик превращается в детектива, сыщика, Пуаро, поросенка Фунтика, кто тут вам ближе… Что можем придумать, пока наших требований нет?
- Смотрим, как работает аналогичный функционал у конкурентов.
- Изучаем старые тикеты, дизайн-макеты, сообщения в чатах (времени уйдет — вагон! сочувствую).
- Общаемся с аналитиками, разработчиками и даже техподдержкой, если нужно.
Придумаем пример. Допустим, у вас интернет-магазин. Казалось бы, берем простой сценарий: пользователь добавляет товар в корзину, оплачивает, получает чек. Но что если платёж не прошёл? Что если товар кончился прямо в момент оформления? Или, может быть, платежная система не работает так, как должна? Не стоит забывать, что нам нужно тестировать не только положительные, но и негативные сценарии. Тут без уточнений не обойтись! Если в требованиях нет ответов, значит, их нужно добыть.
Не стесняйтесь задавать вопросы. Чем больше информации получите, тем легче будет найти ошибки на тестах. Будьте готовы влезть в детали и выяснить, какие именно сценарии критичны для пользователей. В идеале, на старте работы тестировщик должен понимать основные сценарии и логику работы продукта — это будет гораздо полезнее, чем просто «кликать по кнопочкам».
Тестируем в условиях, близких к реальным
Тестовая среда — это очень удобно, но в реальной жизни приложение работает в самых неожиданных условиях: плохой интернет, старые устройства, медленные сервера. Если тестировать только на флагманских смартфонах и с гигабитным Wi-Fi, можно пропустить кучу проблем.
Придумаем пример. Вы тестируете мобильное приложение для мессенджера. Оно ведь должно работать даже при слабом интернете, правильно? Поэтому проверяем всё возможное:
- Переключаемся с Wi-Fi на мобильную сеть прямо в момент отправки сообщения. Эмулируем слабый сигнал и загружаем устройство фоновыми процессами, чтобы проверить, как оно себя ведёт.
- Включаем режим энергосбережения, который ограничивает фоновую активность.
- Эмулируем слабый сигнал через специальные инструменты (например, Network Link Conditioner в iOS). В реальной жизни пользователи любят перемещаться в местах, где качество связи оставляет желать лучшего. Если приложение не сможет грамотно с этим справиться — это будет сразу заметно.
Автотесты не спасут от всего
Автоматизация — мощная вещь, но даже самые крутые автотесты не заменят ручное тестирование. Особенно когда речь идет о юзабилити или сложных сценариях с динамическими изменениями интерфейса. Автотесты быстро могут проверять стабильность и базовые вещи. Но вот всю логику поведения в реальных ситуациях они проверять не могут. Никакой автоматизированный тест не скажет, насколько интуитивно понятен интерфейс или насколько пользователю удобно выполнить сложную задачу.
Придумаем пример. Оформление подписки в приложении. Всем знакомая процедура. Если пользователь отменяет её на последнем шаге, как отреагирует интерфейс? Покажет понятное сообщение или просто выкинет на главный экран? Автотесты, безусловно, пройдут сценарий, но они не скажут, насколько это удобно и логично с точки зрения пользователя. А вот ручной тестировщик сможет это оценить — и, возможно, предложит доработать интерфейс.
Где все-таки нужны автотесты?
- При регрессии: тут проверяем, что старый функционал не сломался.
- В API-тестировании (работаем с Postman, RestAssured, SoapUI).
- При UI-автоматизации (используем Selenium, Appium, Playwright).
Проверяем, как работают интеграции (а точнее, что будет, если они не работают)
Современные приложения — это сложные многокомпонентные системы, которые зависят от множества интеграций: API, платёжных систем, баз данных. И эти штуки могут внезапно сломаться все или частично. Вопрос в том, как ваше приложение это переживёт. Если приложение не умеет грамотно работать с ошибками интеграций, то это сразу проявится на проде, и последствия могут быть совсем нехорошими.
Придумаем пример. Сервис доставки еды. GPS отвалился, что произойдет? Курьер пропадет в неизвестности или приложение честно сообщит пользователю, что не может отследить заказ? Тестируем сценарии отказа! Эмулируем медленные или некорректные ответы от API. А что происходит, если платежный сервис недоступен? И как приложение обрабатывает таймауты? Словом, проверяем, как приложение ведёт себя при сбоях в GPS, сети или в другой внешней интеграции.
Безопасность — не отдельный этап, а встроенная привычка
Функциональные тесты должны учитывать безопасность, иначе можно случайно пропустить дыру, через которую утекут пользовательские данные. И это та ошибка, которую точно не стоит делать. В мире, где безопасность на каждом шагу под угрозой, важно сразу закладывать защиту от потенциальных угроз в процессе тестирования.
Придумаем пример. Мы все пользуемся формой ввода банковской карты. Протестируем ее… Можно ли вставить в поле вредоносный JavaScript? Что если начать отправлять 1000 запросов подряд? Что будем проверять:
- Валидацию данных на клиенте и сервере.
- Ограничение количества запросов (Rate Limiting).
- Хранение и передачу чувствительных данных (HTTPS, шифрование).
Если не продумать безопасность изначально, потом исправить её будет очень трудно и дорого.
Итог
Функциональное тестирование — это искусство задавать правильные вопросы, имитировать реальные условия и искать слабые места, это комплексный процесс. Нужно думать как пользователь, как разработчик и даже как мошенник. Чем глубже копаешь, тем меньше сюрпризов будет на проде. И самое главное — тестировщики и разработчики должны работать вместе. Тогда приложение станет стабильным, а пользователи не будут бесплатными тестировщиками.
P.S. Хотите быстро проверить, насколько ваше приложение готово к реальным пользователям и нужно ли ему ручное тестирование? Проверьте с помощью нашего чек-листа диагностики приложений.
