В статье про виды тестирования мы разделили проверки на функциональные («делает ли то, что нужно») и нефункциональные («насколько хорошо»). Нефункциональных видов много, и на проекте вы будете слышать их названия постоянно: «прогони smoke по юзабилити», «нужен нагрузочный», «проверь совместимость». Эта статья — карта, чтобы понимать, что именно от вас просят и что за каждым названием стоит.
Хорошая новость: ручному тестировщику не нужно уметь проводить все эти виды — часть требует инструментов и отдельной специализации. Но понимать, что проверяет каждый вид, обязан любой член команды.
Удобство использования ≠ работающий интерфейс
Самая частая путаница — между тестированием удобства (usability) и проверкой интерфейса (GUI testing). Это разные вещи:
- Проверка интерфейса отвечает на вопрос «работает ли»: кнопка нажимается, форма отправляется, вёрстка не разъехалась.
- Тестирование удобства — на вопрос «удобно ли»: понятно ли пользователю, что делать, находит ли он нужное без подсказок, не раздражает ли продукт.
Корректно работающий интерфейс может быть чудовищно неудобным — и наоборот: красивый и понятный экран может не работать. Полноценное usability-тестирование — это наблюдение за реальными пользователями, но тестировщик вносит вклад ежедневно: замечает и заводит как баги места, где «работает, но пользоваться невозможно».
Рядом стоит тестирование доступности (accessibility) — пригодность продукта для людей с ограниченными возможностями: работа с экранным диктором, достаточный контраст, управление с клавиатуры без мыши. Во многих странах это требование закона, а не пожелание.
Безопасность, совместимость, установка
Тестирование безопасности проверяет способность продукта противостоять попыткам получить доступ к данным или функциям без права на них. Глубокая безопасность — отдельная профессия, но базовые проверки доступны каждому: что чужой заказ не открывается подстановкой id в адресе, что после выхода из системы кнопка «назад» не показывает личные данные, что пароль не виден в адресной строке.
Тестирование совместимости — способность работать в разных окружениях. Его главные подвиды вы уже встречали: кросс-браузерное и мобильное (разные браузеры, устройства, размеры экранов) и конфигурационное (разные ОС, версии, настройки).
Инсталляционное тестирование проверяет установку, обновление и удаление продукта: ставится ли на чистую систему, обновляется ли со старой версии без потери данных, что остаётся после удаления. Для веб-продуктов это звучит экзотично, но для мобильных и настольных приложений — обязательная программа (обновление приложения с потерей данных пользователя — классика неприятных релизов).
Производительность и её подвиды
Тестирование производительности исследует, как продукт ведёт себя под нагрузкой. Внутри различают:
- Нагрузочное (load) — выдерживает ли продукт ожидаемую нагрузку: «1000 пользователей одновременно — время ответа не более 2 секунд».
- Стрессовое (stress) — что происходит за пределами расчётной нагрузки: продукт деградирует плавно (медленнее, но работает) или падает целиком? А восстанавливается после пика сам?
- Объёмное (volume) — как продукт работает с большими объёмами данных: таблица на десять миллионов строк, отчёт за пять лет.
- Масштабируемости (scalability) — растёт ли производительность при добавлении ресурсов: если серверов вдвое больше, выдержим ли вдвое больше пользователей?
Проводят такие проверки инструментами и обычно отдельные специалисты. Роль ручного тестировщика — замечать симптомы («поиск стал отвечать по десять секунд после загрузки каталога») и понимать формулировки требований: «система должна выдерживать 500 одновременных заказов» — это про load, «а что будет при 5000» — про stress.
Альфа, бета, гамма: подключаем настоящих пользователей
Отдельная ось — кто тестирует. Когда продукт готов настолько, что его не стыдно показать, к проверкам подключают людей извне команды:
- Альфа-тестирование — внутри компании: сотрудники, «дружественные» пользователи. Продукт ещё сырой, обратная связь идёт в команду напрямую.
- Бета-тестирование — снаружи: реальные пользователи добровольно пробуют почти готовый продукт и сообщают о проблемах. Знакомые вам «бета-версии» приложений — ровно это.
- Гамма-тестирование — финальная шлифовка перед выпуском: продукт почти готов, правятся последние мелочи по отзывам.
Ценность этих этапов в том, что реальные пользователи ведут себя не так, как команда: у них другие устройства, привычки и сценарии — и они находят то, что внутри не нашлось бы никогда.
Где это применяется
Эта карта нужна вам в двух ситуациях. Первая — понимать задачи: «проверь совместимость» или «посмотри юзабилити регистрации» должны вызывать конкретный план действий, а не ступор. Вторая — грамотно писать баги: «медленно работает» — плохой репорт; «поиск по каталогу из 2 млн товаров отвечает 12 секунд при норме 2» — хороший, и он явно относится к производительности.
Где спотыкаются начинающие:
- Смешивают «работает» и «удобно» — пропускают usability-проблемы, потому что «функционально всё корректно».
- Пугаются названий. За «конфигурационным тестированием» скрывается понятная вещь: проверить на разных настройках окружения. Термины — это ярлыки на простых идеях.
- Пытаются проверить производительность вручную — обновляя страницу двадцать раз подряд. Для этого есть инструменты и специалисты; ваша задача — замечать симптомы и точно их описывать.
Что учить дальше. Функциональная часть картины — в статье про виды тестирования; проверка на разных браузерах и устройствах — в статье про кросс-браузерное тестирование; как всё это ложится в план — в статье про тест-план.