Как определить тип и качество теста: виды тестирования и ключевые характеристики
Определить тип и качество теста можно, классифицировав его по цели и уровню, а тест-кейс оценив по критериям воспроизводимости, изолированности, прослеживаемости, демонстративности и понятности.
Оглавление
Основные группы и уровни тестирования
Для построения эффективной стратегии проверки продукта тестирование классифицируется по нескольким направлениям:
- Функциональное: проверяет, «что» делает система.
- Нефункциональное: проверяет, «как» она работает (производительность, безопасность, удобство).
- Связанное с изменениями: включает регрессионное и дымовое тестирование.
Важное отличие: дымовое тестирование (Smoke) — это быстрая проверка критического пути после новой сборки, чтобы решить, можно ли вообще запускать глубокое тестирование. Его не нужно путать с регрессионным, которое проверяет, что новые изменения не сломали старый функционал.
Уровни тестирования:
- Модульное (Unit)
- Интеграционное
- Системное
- Приемочное (UAT)
Исчерпывающее тестирование (проверка всех возможных комбинаций входных данных) невозможно на практике, поэтому приоритеты всегда расставляются на основе анализа рисков.
Критерии качества тест-кейса
Риски при проектировании и выполнении тестов Написание тестов с размытыми ожидаемыми результатами приводит к тому, что разные исполнители трактуют их по-разному, и критичные баги пропускаются в продакшен. Включение в тест-кейс «разрушительных» действий (удаление записей, изменение конфигурации) без описания постусловий для восстановления среды может повредить тестовый стенд или данные.
Признаки хорошего теста:
- Воспроизводимость: тест должен давать одинаковый результат при многократном запуске в тех же условиях.
- Изолированность (независимость): тест не должен зависеть от результатов других тестов и не должен оставлять систему в необратимом состоянии без описанных постусловий.
- Прослеживаемость: из текста теста должно быть явно понятно, какое конкретное требование или функцию он проверяет.
- Демонстративность: ожидаемый результат сформулирован так, что любое отклонение делает ошибку очевидной.
- Понятность и лаконичность: использование четкого технического языка, отсутствие размытых формулировок (например, «проверить, что всё работает»).
Метрики и российский контекст
Главная метрика качества тестирования — тестовое покрытие (Test Coverage), которое отражает плотность покрытия тестами требований или исполняемого кода.
Универсальных числовых порогов «идеального» тестового покрытия (например, «надо стремиться к 80%») не существует. Этот показатель сильно зависит от типа проекта, критичности системы и зрелости процессов.
Российский контекст:
- Теоретическая база в России полностью опирается на международный стандарт ISTQB, глоссарий и принципы которого официально переведены и адаптированы (в том числе Русским советом по квалификациям в области тестирования, RSTQB).
- Из-за ограничений на оплату или ухода некоторых зарубежных вендоров, в российских командах для управления тест-кейсами и баг-трекинга всё чаще используются отечественные или локально развертываемые решения: Yandex Tracker, Kaiten, TestIT, Allure TestOps.
Частые ошибки
- «Мигающие» (flaky) тесты. Чаще всего возникают из-за нарушения критерия изолированности: тесты зависят друг от друга, от времени или от состояния базы данных.
- Неконкретный ожидаемый результат. Если тест не работает, первым делом проверьте предусловия (окружение, версия ПО, тестовые данные) и убедитесь, что ожидаемый результат описан конкретно (например, «появится сообщение "Ошибка ввода"», а не «система отреагирует»).
FAQ
Можно ли протестировать все возможные комбинации входных данных?
Нет, исчерпывающее тестирование невозможно на практике. Приоритеты всегда расставляются на основе анализа рисков.
Какое тестовое покрытие считается идеальным?
Универсальных числовых порогов не существует. Этот показатель сильно зависит от типа проекта, критичности системы и зрелости процессов компании.
В чем главное отличие дымового тестирования от регрессионного?
Дымовое тестирование — это быстрая проверка критического пути после новой сборки, чтобы решить, можно ли запускать глубокое тестирование. Регрессионное проверяет, что новые изменения не сломали старый функционал.