Справочник по классификации: что за вид, зачем он нужен и когда его гоняют. Ищи по названию или фильтруй по признаку – русские и английские названия ищутся оба.
Классификация видов – это не один список, а несколько независимых признаков. Один и тот же прогон одновременно функциональный, ручной, негативный и регрессионный. Это не противоречие: просто его описали по четырём разным признакам. Верхний уровень – цель проверки.
Functional testing
Проверяешь, ЧТО система делает: выполняет ли она заявленные функции. Опора – требования, спецификация, пользовательские истории. Сюда попадает большая часть ручной работы.
Пример. С валидной парой логин и пароль пользователь попадает в личный кабинет, с неверной – видит ошибку и остаётся на форме.
Non-functional testing
Проверяешь, КАК система делает свою работу: быстро, безопасно, удобно, стабильно. Список характеристик качества берут из ISO/IEC 25010. В редакции 2023 года их девять: функциональная пригодность, производительность, совместимость, взаимодействие с пользователем, надёжность, безопасность, сопровождаемость, гибкость и безопасность жизни и здоровья (safety).
Пример. Каталог открывается за 2 секунды при 500 одновременных пользователях и не разваливается на планшете.
Smoke testing
Короткий набор проверок по ключевой функциональности: жив ли билд вообще. Не прошёл – билд разворачивают, дальше не тестируют. Иногда это называют сертификацией билда. Гоняют на каждой сборке, поэтому автоматизируют в первую очередь.
Пример. В магазине: логин, поиск товара, добавление в корзину, оплата – по одному сценарию на каждое, минут на десять.
Sanity testing
Узкая, но глубокая проверка одной области после точечного изменения: есть ли смысл запускать полный прогон. Термина нет в силлабусе ISTQB 4.0, это жаргон индустрии, и команды понимают его по-разному. Договорись на берегу, что вы называете sanity.
Как отличить от смоука. Смоук широкий и мелкий по всему билду, санити узкий и глубокий по одной функции.
Critical path testing
Сценарии, которыми типичный пользователь пользуется каждый день. Шире смоука, уже полного прогона. Список критических путей вытаскивают из аналитики продукта, а не выдумывают.
Пример. Не просто "оплата проходит", а оплата картой, бонусами, с промокодом и с последующим возвратом.
Extended testing
Вся заявленная в требованиях функциональность, включая низкоприоритетные и маловероятные сценарии. Дорого по времени, поэтому запускают перед крупным релизом или когда цена ошибки высокая.
Пример. Оплата картой другой страны, заказ на 999 позиций, отмена ровно в момент передачи в доставку.
Confirmation testing, retest
После фикса повторяешь ровно те шаги из баг-репорта, на той же конфигурации: дефект воспроизводится или нет. Не воспроизводится – двигаешь баг в Verified или Closed. Проверяешь только этот баг, не соседей.
Пример. Приложение падало при загрузке фото больше 10 МБ. Разработчик починил – повторяешь тот же файл, то же устройство, ту же сеть.
Regression testing
Проверяешь, что изменение не сломало то, что раньше работало. Повод – любое изменение: новая фича, фикс бага, обновление библиотеки, смена конфигурации сервера. Полный регресс дорогой, поэтому набор сокращают по зоне влияния и по риску.
Performance testing
Скорость и стабильность отклика под нагрузкой. Внутри – несколько разных задач:
Инструменты: JMeter, k6, Gatling, Locust.
Usability testing
Понятно ли, удобно ли, доходит ли пользователь до цели без инструкции. Измеряется, а не обсуждается на вкус: время на задачу, число ошибок, доля дошедших до конца. В ISO/IEC 25010 редакции 2023 года usability переименовали в interaction capability.
Пример. Дай пятерым людям задачу оформить возврат и молча смотри, где они застревают.
Security testing
Устойчивость к атакам и утечкам: SQL-инъекции, XSS, обход авторизации, небезопасные прямые ссылки на объекты. Ориентир для джуна – OWASP Top 10.
Пример. Подставь чужой id заказа в URL. Если увидел чужой заказ – это дефект контроля доступа, а не мелочь.
Compatibility testing
Работа в разном окружении: браузеры и их версии, ОС, разрешения экрана, устройства, версии внешних API. Кросс-браузерное и кросс-платформенное – частные случаи.
Пример. Матрицу окружений собирают из аналитики продукта: если 80% трафика с двух браузеров, остальные проверяют выборочно.
Installation testing
Установка, обновление, откат и удаление. Отдельно проверяют апгрейд с самой старой поддерживаемой версии – там чаще всего и ломается миграция данных.
Пример. Обновление с 1.2 на 2.0 не теряет данные пользователя, а удаление чистит за собой файлы и записи в реестре.
Accessibility testing, a11y
Пригодность продукта для людей с ограничениями: скринридер, навигация с клавиатуры, контраст текста, размер тап-целей, альтернативы для видео. Ориентир – WCAG 2.2.
Пример. Пройди оформление заказа только с клавиатуры, ни разу не тронув мышь. Если фокус потерялся – это баг.
Localization L10n, internationalization I18n
I18n – готовность к языкам вообще: строки вынесены из кода, есть поддержка юникода и письма справа налево, форматы не зашиты жёстко. L10n – качество конкретной локали: перевод, формат даты и валюты, длина строк в интерфейсе.
Пример. Немецкие строки длиннее русских на треть и вылезают за кнопку. Ловится переключением локали, а не чтением перевода.
Reliability, recoverability testing
Работает ли система заданное время без отказов и как возвращается в строй после сбоя. Рядом живут failover и disaster recovery – переключение на резерв и восстановление из бэкапа.
Пример. Погаси базу на минуту: приложение отдаёт внятную ошибку, а после подъёма работает дальше без ручного вмешательства.
Flexibility, portability, maintainability
Характеристики из ISO/IEC 25010, до которых ручной тестировщик доходит редко. Гибкость (до 2023 года – переносимость, portability): переезд на другое окружение, установка, замена компонента. Сопровождаемость: насколько дёшево вносить изменения – проверяется ревью и статическим анализом, а не кликами.
Static testing
Без запуска кода: ревью требований, ревью кода, разбор макетов, статический анализ линтерами и SonarQube. Самый дешёвый дефект – найденный в требованиях: там его правка стоит одну строку текста.
ISTQB выделяет формальность ревью: informal review, walkthrough, technical review, inspection.
Dynamic testing
С запуском: система работает, ты подаёшь данные и смотришь поведение. Всё, что ручной тестировщик делает руками в приложении, – динамическое тестирование.
Manual testing
Проверки выполняет человек. Выигрывает там, где нужны глаза и суждение: вёрстка, UX, новая нестабильная фича, исследование незнакомой области.
Automated testing
Проверки выполняет код. Выигрывает на повторяемых прогонах: регресс, смоук, API, нагрузка. Автотест почти не находит новые баги – он стережёт то, что уже работало, и орёт, когда это сломали.
Positive testing
Валидные данные, ожидаемый сценарий: система делает то, что обещано в требованиях. Это минимум, с которого начинают, и худшее место, чтобы на нём остановиться.
Negative testing
Неверные данные и нештатные действия: система не падает, не пускает лишнего и внятно объясняет, что не так. Большинство продовых инцидентов родом отсюда.
Пример. Буквы в поле суммы, двойная отправка формы, обрыв сети на середине оплаты, кнопка "Назад" в браузере после платежа.
Scripted testing
Прогон заранее написанных сценариев с шагами и ожидаемым результатом. Повторяемо, легко передать новичку, годится для отчётности. Находит только то, что кто-то заранее придумал.
Exploratory testing
Изучение продукта, проектирование и выполнение тестов идут одновременно. Не хаос: работа ведётся сессиями по хартии, с таймбоксом и записью находок. С этого начинают на новом проекте, пока тест-кейсов ещё нет.
Ad hoc testing
Без подготовки и записи, на опыте и интуиции. Годится как разминка перед серьёзной работой. Как отчётный артефакт не годится: результат не воспроизвести и не передать.