Виды тестирования делят по тому, что проверяют, на каком уровне системы и каким способом: функциональное и нефункциональное, модульное и системное, ручное и автоматизированное. Классификаций много, и они пересекаются: одна и та же проверка может быть одновременно функциональной, регрессионной и автоматизированной. Ниже разбираем основные типы тестирования, объясняем, какие из них нужны сайту, веб-сервису и мобильному приложению, и показываем, где тестирование стоит в этапах разработки.
Что такое тестирование приложений
Тестирование приложений это проверка того, что программа делает обещанное в требованиях и не делает того, чего не должна. Тестировщик сравнивает фактическое поведение с ожидаемым, записывает расхождения в баг-трекер и проверяет исправления. Тестирование программного обеспечения не доказывает, что ошибок нет. Оно снижает риск, что их первыми найдут пользователи.
Тестирование проверяет продукт с разных сторон. Функции работают по ТЗ? Система работает быстро под нагрузкой? Интерфейс понятен? Данные защищены? Приложение открывается на старом Android и в Safari? На каждый вопрос есть свой вид проверки, и набор зависит от продукта и рисков бизнеса.
Чем раньше найдена ошибка, тем дешевле ее исправить. Ошибку в требованиях на раннем этапе разработки правят в документе. Та же ошибка в опубликованном приложении требует исправления кода, повторного тестирования и новой публикации в сторах. Поэтому QA (quality assurance, обеспечение качества) в хорошей команде начинается с чтения ТЗ, а не с готовой сборки.
Виды тестирования программного обеспечения
По цели. Функциональное тестирование проверяет, что система делает: регистрация, поиск, оплата, расчеты. Нефункциональное тестирование проверяет, как она это делает: скорость, надежность, безопасность, удобство использования, совместимость. К видам функционального тестирования относят проверку бизнес-логики, пользовательских сценариев, интеграций и прав доступа.
По уровню системы:
- Модульное (unit) тестирование: разработчик проверяет отдельную функцию или класс в отрыве от остального кода.
- Интеграционное тестирование: проверяем, как модули и внешние сервисы работают вместе, например приложение, сервер, база данных и платежный шлюз.
- Системное тестирование: проверяем продукт целиком в окружении, близком к рабочему.
- Приемочное тестирование: заказчик или конечный пользователь подтверждает, что продукт решает его задачу и соответствует ТЗ.
По знанию кода различают три метода тестирования. Черный ящик: тестировщик не смотрит в исходный код и проверяет систему через интерфейс, как пользователь. Белый ящик: тесты пишут с учетом внутренней логики, чтобы пройти все ветки условий. Серый ящик сочетает оба подхода: тестировщик знает архитектуру и схему базы, но работает через интерфейс.
По способу выполнения. При ручном тестировании человек проходит тест-кейсы (пошаговые сценарии проверки с ожидаемым результатом) и исследует продукт сам. При автоматизированном тестировании проверки выполняют скрипты. Автотесты окупаются на повторяющихся проверках, ручные незаменимы там, где нужна оценка человека: удобство, внешний вид, неожиданные сценарии.
По моменту и задаче:
- Дымовое тестирование (smoke): быстрая проверка, что сборка вообще запускается и основные функции живы. Если smoke не прошел, дальше не тестируем.
- Регрессионное тестирование: повторная проверка старых функций после изменений, чтобы новое не сломало работающее.
- Исследовательское тестирование: тестировщик изучает продукт без заранее написанных сценариев и ищет неочевидные ошибки.
- Альфа- и бета-тестирование: альфа проходит внутри команды, бета выходит к ограниченному кругу реальных пользователей до публичного релиза.
Нефункциональные виды тоже делятся на группы: нагрузочное тестирование, тестирование совместимости с устройствами и браузерами, тестирование безопасности, проверка удобства использования (юзабилити), тестирование локализации.
Этапы разработки сайта: тестирование
Тестирование встроено в каждый этап разработки и не стоит одним пунктом перед запуском. Вот как это выглядит на проекте сайта или веб-сервиса:
- Анализ и ТЗ: тестировщик читает требования и ищет противоречия и пробелы. Здесь исправление обходится дешевле всего.
- Дизайн: проверяем макеты на полноту состояний: ошибки, пустые списки, длинные тексты, мобильная версия.
- Разработка: разработчики пишут модульные тесты, тестировщик готовит тест-кейсы и проверяет каждую задачу после сдачи.
- Стабилизация перед релизом: smoke-тестирование, регрессионное тестирование, проверка совместимости и нагрузки.
- Приемка: заказчик проходит основные сценарии на тестовом стенде.
- После запуска: smoke на рабочем сервере, мониторинг ошибок, регрессия перед каждым обновлением.
Если этап тестирования сайта вынесен в самый конец и сжат под дедлайн, часть ошибок почти наверняка найдут посетители.
Что такое тестирование сайта
Тестирование сайта это проверка того, что страницы открываются, формы отправляются, оплата проходит, а сайт одинаково работает в разных браузерах и на телефоне. У сайта есть проверки, которых нет у мобильного приложения: адаптивная верстка на десятках разрешений, скорость загрузки, корректность мета-тегов и редиректов, доступность страниц для поисковых роботов.
Тестирование сайтов это еще и проверка контента: битые ссылки, опечатки в ценах, картинки без описаний, пустые разделы каталога. Такие ошибки не ломают код, но портят впечатление и позиции в поиске.
Что за тестирование сайта нужно перед запуском?
Минимальный набор проверок перед публикацией:
- функциональные: все формы, корзина, оплата, личный кабинет, поиск, фильтры;
- кроссбраузерные: актуальные версии Chrome, Safari, Firefox и других браузеров на движке Chromium;
- адаптивность: смартфоны с маленьким и большим экраном, планшет, широкий монитор;
- скорость: время загрузки ключевых страниц, вес изображений;
- SEO-техника: robots.txt, карта сайта, коды ответов, канонические адреса, отсутствие дублей;
- безопасность: HTTPS, защита форм от спама, закрытые служебные разделы;
- юридические требования: политика обработки персональных данных и согласие в формах.
Тестирование сайтов: какие виды выбрать
Набор зависит от типа сайта. Лендингу хватает функциональной проверки форм, кроссбраузерности и скорости. Корпоративному сайту добавляем проверку CMS: может ли менеджер сам поменять текст и не сломать верстку. Интернет-магазину нужны интеграционное тестирование с 1С или складом, проверка оплаты и доставки, нагрузочные тесты перед распродажами. Веб-сервису с личными кабинетами нужны все виды выше, плюс проверка ролей доступа, безопасности и регрессионные автотесты, потому что он обновляется часто.
Как сделать тестирование сайта?
- Соберите требования: что сайт должен делать, в каких браузерах и на каких устройствах работать.
- Составьте чек-лист или тест-кейсы по каждой странице и сценарию.
- Разверните тестовую копию сайта, чтобы не ломать рабочую версию и не создавать настоящие заказы.
- Пройдите проверки вручную. Ошибки записывайте с шагами воспроизведения, скриншотом и описанием ожидаемого результата.
- Повторяемые проверки автоматизируйте, например с помощью Playwright, Cypress или Selenium.
- После исправлений проведите регрессию и только потом выкладывайте изменения.
Небольшой сайт можно проверить своими силами по чек-листу. Для магазина или сервиса с интеграциями процесс тестирования лучше отдать отдельному специалисту. Разработчик плохо находит ошибки в собственном коде, потому что проверяет те сценарии, которые сам и задумал.
QA web приложений
QA web приложений отличается от тестирования сайта объемом логики. В веб-приложении много ролей, сложные формы, расчеты, отчеты, интеграции через API. Поэтому проверки строим слоями:
- модульные тесты разработчиков на бизнес-логику;
- автотесты API: проверяем ответы сервера, коды ошибок и права доступа без интерфейса;
- интеграционные тесты с базой данных и внешними сервисами;
- автотесты интерфейса на основные сценарии;
- ручное исследовательское тестирование новых функций.
В хорошем QA-процессе ручное тестирование, автоматизированное тестирование и мониторинг после релиза дополняют друг друга. Автотесты ловят регрессию за минуты после каждого изменения кода. Человек находит то, что скрипту не придет в голову: неудобный порядок полей, двусмысленную формулировку, сценарий, который забыли описать в ТЗ.
Что такое тестирование мобильного приложения?
Тестирование мобильного приложения это проверка функций, интерфейса и стабильности приложения на реальных устройствах и версиях iOS и Android. К общим видам проверок добавляются мобильные:
- совместимость с разными моделями, размерами экранов и версиями операционных систем;
- прерывания: входящий звонок, уведомление, сворачивание и возврат в приложение;
- работа при плохой сети и без нее, переключение между Wi-Fi и мобильным интернетом;
- расход батареи и памяти;
- разрешения на камеру, геолокацию, уведомления;
- обновление с прошлой версии без потери данных;
- соответствие правилам App Store и Google Play, чтобы приложение прошло модерацию.
Эмуляторы подходят для первых проверок, но финальный прогон делаем на физических устройствах: жесты, камера, датчики и производительность на эмуляторе ведут себя иначе. Как мы строим такие проверки для iOS и Android, описано на странице услуги тестирование мобильных приложений.
Как сделать приложение для тестирования?
Под этим вопросом обычно имеют в виду тестовую сборку: версию приложения, которую раздают тестировщикам и бета-пользователям до публикации. Для iOS используют TestFlight: сборку загружают в App Store Connect и приглашают тестировщиков по почте или публичной ссылке. В Google Play Console для Android есть треки внутреннего, закрытого и открытого тестирования, а для быстрых проверок внутри команды можно раздать APK-файл напрямую.
Чтобы приложение было удобно тестировать, закладываем это в разработку заранее:
- отдельные окружения: тестовый сервер и тестовая база данных, чтобы не задевать реальных пользователей;
- переключатель окружений в тестовой сборке;
- логи и отчеты о сбоях, например через Firebase Crashlytics;
- идентификаторы у элементов интерфейса, по которым автотесты находят кнопки и поля;
- тестовые аккаунты с разными ролями и данными.
На демо-проектах Капиталика, Грядка и Трассер мы показываем заказчикам, как выглядит такая инфраструктура: тестовые сборки, баг-трекер, отчеты о прогонах. Это демонстрационные проекты, по ним удобно договориться, какой уровень проверок нужен вашему продукту. Ориентировочный бюджет можно прикинуть в калькуляторе.
Услуга студии
Тестирование приложений и сайтов
Тестирование мобильных приложений и сайтов на реальных устройствах: ручные проверки, автотесты, нагрузка и безопасность перед релизом.
