Тестирование приложений и сайтов

Подробно

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

Тестирование приложений

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

Что входит в мобильное тестирование у нас:

• функциональное тестирование: каждая функция работает по требованиям, от регистрации до оплаты;
• проверка на матрице устройств: iOS и Android, разные версии операционной системы, телефоны и планшеты, маленькие и большие экраны;
• прерывания: входящий звонок, сворачивание, блокировка экрана, смена ориентации;
• сеть: как приложение работает при переходе с Wi-Fi на мобильный интернет, в режиме полета, на медленном соединении;
• ошибки: что приложение показывает пользователю, если сервер не ответил или данные не загрузились;
• push-уведомления: приходят ли, открывают ли нужный экран, как ведут себя при выключенных разрешениях;
• тестирование производительности: время запуска, расход батареи и памяти, плавность прокрутки;
• тестирование безопасности: хранение токенов, передача данных, доступ к данным после выхода из аккаунта.

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

Тип мобильного приложения влияет на план проверок. Нативное приложение (написанное отдельно под каждую платформу на Swift или Kotlin) тестируем отдельно на Android и iOS. Кроссплатформенное на Flutter или React Native имеет общий код, но платформенные различия все равно проявляются: системные диалоги, жесты, клавиатура. Мобильное веб-приложение проверяем в браузерах смартфонов и в режиме установки на главный экран.

Перед публикацией сверяем сборку с правилами магазинов. В App Store приложение проходит ревью, и сборки с падениями, заглушками вместо контента или интерфейсом, который расходится с Human Interface Guidelines (правилами оформления интерфейсов для iOS), могут вернуть на доработку. Такие вещи дешевле найти до отправки.

Тестирование сайтов

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

• формы: проверка полей, отправка заявок в CRM и на почту, защита от спама;
• корзина и оплата в интернет-магазине, включая отмену и возврат;
• личный кабинет: регистрация, восстановление пароля, права ролей;
• верстка на мобильных устройствах, планшетах и десктопах;
• скорость загрузки страниц и работа под нагрузкой;
• базовая безопасность: SQL-инъекции, XSS (внедрение чужого скрипта на страницу), доступ к закрытым разделам по прямой ссылке.

Тестирование веб-приложений (сервисов, где пользователь работает с данными: CRM, кабинеты, конструкторы) ближе к тестированию программ, чем к проверке обычного сайта. Там больше состояний и ролей, поэтому без тест-кейсов не обойтись.

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

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

Тестирование сайта онлайн

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

Мы используем автоматические сервисы как первый фильтр, а затем проходим сайт руками по чек-листу и тест-кейсам.

Тестирование сайтов и приложений

Для каждого проекта собираем набор проверок под его риски. Основные виды тестирования, которые мы применяем:

• смоук-тест (быстрая проверка, что сборка запускается и основные функции живы) после каждой новой версии;
• функциональное тестирование по тест-кейсам;
• регрессионное тестирование: проверяем, что исправления не сломали то, что работало раньше;
• тестирование интерфейса и пользовательского опыта: понятно ли человеку, что делать на экране, совпадает ли верстка с макетами;
• интеграционное тестирование: обмен с платежами, CRM, картами, службами доставки;
• нагрузочное тестирование: сколько одновременных пользователей выдерживает система до замедления.

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

Автотесты пишем там, где сценарий повторяется от релиза к релизу: вход, регистрация, оплата, ключевые API. Ручное тестирование оставляем для нового функционала, верстки и проверок, где нужен взгляд человека.

Из инструментов мобильного тестирования используем Appium для кроссплатформенных автотестов, XCUITest и Espresso для нативных сценариев, Charles Proxy для анализа сетевых запросов, Postman для проверки API. Для веба берем Playwright, для нагрузки JMeter. Конкретный набор выбираем под стек проекта.

Разработка и тестирование программного обеспечения

Организация тестирования в команде разработчиков определяет, сколько ошибок доберется до пользователей. Мы подключаем QA-инженера (специалиста по обеспечению качества) с этапа ТЗ: он читает требования и находит противоречия до того, как по ним написан код. Дальше тестировщик пишет тест-кейсы параллельно с разработкой, проверяет каждую задачу перед слиянием в основную ветку и прогоняет регресс перед релизом.

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

Если у вас своя команда разработки, можем встроиться в нее: взять на себя тестирование, настроить баг-трекер, описать процесс приемки задач. На тестирование обычно приходится 10-15 процентов бюджета разработки приложения. Когда эту долю урезают, расходы переезжают в поддержку и исправления после релиза.

Процесс тестирования сайтов

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

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

В демо-проекте Капиталика, финансовом приложении из нашего портфолио, типичный цикл выглядел бы так: матрица телефонов на iOS и Android, отдельный блок проверок безопасности для платежей и хранения данных, автотесты на вход и перевод между счетами.

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

Как выглядит отчет о дефекте

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

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

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

Сколько времени занимает тестирование сайта?

Срок называем после изучения проекта. На него влияют число страниц и ролей, количество интеграций, список браузеров и устройств, наличие готовых тест-кейсов. Сайт-визитку с формой заявки проверить быстрее, чем интернет-магазин с оплатой, личными кабинетами и обменом с 1С. Если тестирование встроено в разработку, отдельного срока нет: QA проверяет каждую задачу по мере готовности, а перед релизом проходит полный регресс.

Тестирование сайта: цены

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

Сэкономить на тестировании помогает подготовка: актуальные требования или ТЗ, тестовый стенд с данными, доступы к админке и список устройств вашей аудитории из аналитики. Без этого тестировщик тратит часы на выяснение того, как продукт должен работать.

Сколько стоит тестирование приложения?

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