Технологии TMS: самая полная классификация методов тестирования ПО

Хотите разобраться в многообразии методов тестирования программного обеспечения и научиться выбирать лучшие подходы для ваших проектов?

В этой статье мы подробно рассмотрим основные классификации методов тестирования: от классического деления на white-box и black-box до современного поведенческого и нагрузочного тестирования.

Ручное и автоматическое тестирование

Ручные тесты и автотесты — это два основных способа проверки качества программного обеспечения, которые дополняют друг друга и применяются в разных ситуациях. Оба вида входят в базовые функции TMS-систем.

Федор Алексеев, владелец продукта Сфера.Функциональное тестирование:

Когда выбирать автотесты:

1. Повторяемость. Если один и тот же сценарий нужно проверять десятки или сотни раз (например, после каждого обновления продукта) — его стоит автоматизировать. Машина сделает это быстрее, стабильнее и без человеческой усталости.
   Пример: проверка оформления заказа в интернет-магазине при каждом релизе.
2. Критичность для бизнеса. Сценарии, сбой в которых дорого обойдётся компании (например, оплата, вход в систему, безопасность), нужно проверять автоматически и регулярно.
   Пример: автотест, который каждую ночь проверяет, что платёж проходит от начала до конца.
3. Техническая стабильность. Очень важно обращать внимание на стабильность функциональности и требования. Если они не меняются каждую неделю или спринт, то автотест будет жить долго и приносить пользу, а не «ломаться» после каждого релиза. В противном случае, покрывая даже критичную для бизнеса функциональность, команды будет тратить много ресурсов и времени не постоянную актуализацию и анализ причин падения такого автотеста.
   Пример: вход в систему через логин и пароль.

Когда выбирать ручное тестирование

1. Тестирование новых фичей. Если функционал только что разработан и ещё непонятно, как им будут пользоваться — ручное тестирование помогает «пощупать» систему, найти неожиданные сценарии и проблемы, которые сложно заранее запрограммировать.
   Пример: новый интерфейс для поиска товаров, где важно почувствовать удобство глазами реального человека.
2. Удобство использования (usability) и субъективные факторы. Автотест не скажет: «эта кнопка неудобная» или «цвет сливается с фоном». Здесь нужна человеческая оценка.
   Пример: проверка того, насколько интерфейс доступен людям с разным зрением.
3. Разовые или редкие проверки. Если сценарий используется очень редко и не критичен для бизнеса, дешевле проверить его вручную, чем тратить время на написание и поддержку автотеста.
   Пример: раз в квартал проверяется отчётность для внутреннего аудита.

Кстати, интеграция с CI/CD-конвейерами и пайплайнами — одна из тенденций на рынке TMS-систем.

Ручные тесты (Manual Testing)

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

Когда применяются?

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

Преимущества:

• Высокая гибкость и адаптивность к неожиданным ситуациям.
• Возможность исследовать нефункциональные аспекты (юзабилити, стиль, эстетика).

Недостатки:

• Медленное выполнение.
• Трудоемкость, высокая вероятность человеческой ошибки.
• Повторяемость действий утомляет, снижается внимательность.

Автотесты (Automated Testing)

Автотесты — это тесты, которые выполняются автоматически с помощью программного обеспечения и скриптов. Они предназначены для проверки определенных сегментов кода, поведения системы или интеграции компонентов.

Когда применяются?

• Регрессионное тестирование: автоматическое подтверждение работоспособности старой функциональности после внесения изменений в код.
• Интерфейсные и API-тесты: проверка поведения системы на основании протоколов HTTP, RESTful API и иных интерфейсов.
• Параллельные и массовые тесты: выполнение огромного количества тестов одновременно, что позволило бы человеку потратить дни и недели.
• Частые изменения в коде: если код меняется часто, автотесты помогут быстро выявить нарушения в логике.

Преимущества:

• Высокая скорость выполнения.
• Надежность и точность повторяемых тестов.
• Возможность параллельного запуска и масштабирования.

Недостатки:

• Нужно сначала написать тесты и поддерживать их актуальность.
• Ограничены в оценке субъективных моментов (например, удобство использования, впечатления пользователя).
• Сложность в настройке и автоматизации редких и необычных сценариев.

Проблема согласованности

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

Стабильные и нестабильные тесты

В зависимости от результатов многократно проведенного тестирования формируется список стабильных и нестабильных тестов.

Федор Алексеев, владелец продукта Сфера.Функциональное тестирование:

Неустойчивый или нестабильный (flaky) тест — это тест, который иногда падает, иногда проходит успешно, хотя код продукта не менялся. Обычно он путает команду и снижает доверие к автотестам.

Признаки:

1. Результаты «через раз». Один и тот же тест в одинаковых условиях может быть успешно пройденным или проваленным.
2. Зависимость от внешних факторов. Например: нестабильная сеть, случайные тайминги, порядок запуска других тестов.
3. История прогонов. Если посмотреть на статистику теста, видно, что он падает в 10–20% случаев без видимых изменений в продукте.

Возможности TMS уже давно вышли за рамки простого хранения тест-кейсов. Они становятся центром аналитики качества, и могут помочь тестировщикам с определением и исправлением нестабильных тестов.

1. Сбор статистики. TMS фиксирует историю запусков: сколько раз тест выполнялся и сколько раз упал. На основе этих данных легко считать показатель «flakiness rate» — процент нестабильных запусков.
2. Автоматическая пометка. Если тест три раза подряд дал разные результаты, TMS может пометить его как «нестабильный» и исключить из блокирующих проверок в процессе CI/CD, чтобы они не тормозили релиз.
3. Помощь в анализе. TMS хранит логи, скриншоты и видео, что облегчает поиск причины падения. Дополнительно система может подсвечивать закономерности: например, что тест чаще всего падает только в одном браузере или при высокой нагрузке.
4. «Карантин» для нестабильных тестов. TMS может отправлять flaky-тесты в отдельный пул. Они не мешают основным проверкам, но продолжают запускаться и собирать статистику, пока команда работает над их исправлением.

Стабильный тест (Stable Test)

Стабильным называется тест, который гарантированно проходит или не проходит при одних и тех же входных данных и окружении. Результат такого теста остается постоянным при многократном повторении.

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

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

Нестабильный (Flaky) тест

Термином Flaky tests обозначают тесты, которые проходят успешно или терпят неудачу непредсказуемым образом при повторных запусках. Причинами flaky тестов могут быть:

• Временные интервалы или тайминги (таймауты, пауза в ожидании события);
• Зависимость от внешних факторов (например, сетевые задержки, сбои инфраструктуры);
• Параллельное выполнение тестов, приводящее к взаимному влиянию;
• Изменчивость окружающей среды (сервер, база данных, API);
• Ошибки в самом тестовом коде (логические ошибки, неверные предположения).

Такие тесты создают серьезные проблемы для команд разработчиков и тестировщиков, так как приводят к:

• Ложным тревогам и лишним действиям по расследованию проблем;
• Недоверию к самому процессу тестирования;
• Затратам времени и ресурсов на постоянную переорганизацию тестов.

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

Сколько раз проводить тест, чтобы узнать его стабильность

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

Минимум 10–20 повторений подряд

Запустите тест минимум 10–20 раз подряд в идентичной среде и условиях. Если тест стабильно проходит все попытки, высока вероятность, что он надежный. Если возникают ошибки хотя бы в одном запуске, тест считается нестабильным («flaky»).

Несколько сеансов тестирования

Лучше провести несколько серий запусков, состоящих из упомянутых выше 10–20 попыток. Это даст дополнительную уверенность в стабильности теста. Рекомендуемый диапазон — около 4-6 сессий.

Симуляция реальных условий

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

Итоговая формула

Минимальное рекомендуемое количество запусков — 100 и более последовательных запусков, распределенных на несколько сеансов. Если в течение этого периода тест ни разу не показал ошибку, велика вероятность, что он стабилен.

Белые и черные ящики

Тестирование белого ящика (White Box Testing)

Тестирование белого ящика (White Box Testing) — это метод тестирования, при котором тестировщику доступен внутренний код программы или компоненты. Главная идея заключается в проверке внутренней логики и структуры приложения. Этот подход фокусируется на проверке внутренних путей выполнения кода, правильности расчетов, граничных значений переменных и логической целостности. Белое тестирование называют также структурным или функциональным тестированием, так как оно основано на понимании внутреннего устройства программы.

Типичные техники белого тестирования:

• Coverage Testing (покрытие кода): проверка всех путей выполнения, ветвей, условий и функций.
• Data Flow Testing: анализ потока данных внутри программы.
• Error Guessing: выявление вероятных ошибок на основе опыта и интуиции.

Белое тестирование применяют на этапе разработки, чтобы подтвердить внутреннюю корректность и надёжность программы.

Тестирование черного ящика (Black Box Testing) 

Тестирование черного ящика (Black Box Testing) — противоположный подход, при котором внутренняя структура и устройство программы неизвестны тестировщику. Здесь оценивается только внешняя функциональность и реакция программы на входные данные. Этот метод направлен на проверку соответствия требованиям, спецификациям и ожидаемому поведению.

Типичные техники черного тестирования:

• Boundary Value Analysis: проверка граничных значений входных данных.
• Equivalence Partitioning: разделение диапазона входных данных на эквивалентные классы.
• Decision Table Testing: проверка реакций программы на комбинации условий.
• State Transition Testing: проверка состояний и переходов системы.

Черное тестирование проводят ближе к концу разработки, когда нужно убедиться, что приложение функционирует правильно и надежно в реальных условиях.

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

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

Тест-кейс (Test Case)

Тест-кейс (Test Case) — это отдельное действие или последовательность действий, предназначенных для проверки определенного аспекта функциональности программного обеспечения. Тест-кейс описывает конкретные шаги, которые нужно выполнить, ожидаемые результаты и входные данные. Задача тест-кейса — убедиться, что конкретная функция или часть системы работает корректно.

Пример тест-кейса:

Название: Вход в аккаунт
Шаг 1: Открыть страницу входа
Шаг 2: Ввести корректные логин и пароль
Шаг 3: Нажать кнопку "Войти"
Ожидаемый результат: Пользователь успешно вошел в аккаунт

Тестовый сценарий (Test Scenario)

Тестовый сценарий (Test Scenario) — это высокоуровневое описание последовательности действий, которые охватывают целую рабочую задачу или процесс. Тестовый сценарий обычно включает несколько тест-кейсов и охватывает более крупную область системы. Сценарий задаёт общую схему тестирования и описывает, какие именно аспекты продукта необходимо проверить.

Пример тестового сценария:

Название: Оформление заказа
Описание: Проверка процесса покупки товара
Сценарий:
1. Зарегистрироваться на сайте
2. Найти товар и добавить его в корзину
3. Перейти к оформлению заказа
4. Проверить корректность расчета суммы заказа
5. Завершить покупку
Результат: Заказ успешно оформлен

Основное различие

• Тест-кейс — это мелкая единица тестирования, проверяющая одну деталь (функцию).
• Тестовый сценарий — это крупная схема, охватывающая целый процесс или бизнес-операцию и включающая несколько тест-кейсов.

Сначала сценарий, потом кейс

Тест-кейсы и тестовые сценарии применяются одновременно, но не в буквальном смысле «параллельно». Порядок работы выглядит так:

1. Сначала создается тестовый сценарий, который описывает высокоуровневую последовательность действий для проверки целой рабочей задачи или процесса (например, покупка товара, регистрация пользователя и т.д.).
2. Затем для каждого шага сценария разрабатываются детализированные тест-кейсы, уточняющие конкретные действия, входные данные и ожидаемые результаты. Тест-кейсы нацелены на проверку конкретных функций и условий.

Таким образом, сначала формируется каркас сценария, а потом наполняется деталями в виде отдельных тест-кейсов. Вместе они образуют целостную систему тестирования, охватывающую как низкоуровневые детали, так и общую функциональность продукта.

Тест-планы

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

• мастер-тест-план задаёт направление и рамки тестирования на высоком уровне,
• детальный тест-план раскрывает подробности и глубину проработки конкретных направлений тестирования.

Далее разберемся, как правильно составить и использовать оба типа тест-планов, чтобы повысить качество вашего ПО.

Мастер-тест-план (Master Test Plan)

Мастер-тест-план — это основной документ, содержащий общую концепцию и руководство по проведению тестирования проекта. Он охватывает всю программу тестирования и устанавливает рамки, цели, стратегию и организационные аспекты. Мастер-тест-план охватывает следующие аспекты:

• Цели и задачи тестирования.
• Ресурсы и бюджет.
• График тестирования и расписание работ.
• Уровень рисков и меры по их контролю.
• Стратегии тестирования (white box, black box, smoke, regression и т.д.).
• Ответственность и полномочия участников процесса.
• Политики приемки и критерии завершения тестирования.

Его главная цель — служить руководством для всех участников процесса тестирования, формируя единое видение и стандарты работы.

Детальный тест-план (Detailed Test Plan)

Детальный тест-план (также называемый тест-планом низкого уровня) сосредотачивается на конкретном компоненте или подмножестве функций продукта. Он строится на основе мастер-тест-плана и касается конкретных аспектов тестирования:

• Специфические задачи и процедуры тестирования.
• Набор тест-кейсов и тестовых сценариев.
• Методы и инструменты тестирования.
• Критерии оценки успешности и допустимые отклонения.
• Альтернативные варианты действий в случае возникновения непредвиденных ситуаций.

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

Различия

• Мастер-тест-план формирует общую стратегию и руководство для всего проекта.
• Детальный тест-план углубленно рассматривает отдельные компоненты и детали тестирования.

Эти документы обеспечивают структурированную и организованную процедуру тестирования, повышая качество конечного продукта.

Agile и Waterfall методологии в тестировании

Методологии разработки программного обеспечения Agile и Waterfall радикально отличаются друг от друга и существенно влияют на подход к тестированию. Развитие TMS-систем позволяет учесть эти нюансы.

Waterfall (Каскадная модель)

Модель Waterfall характеризуется последовательным прохождением стадий разработки: анализ требований → проектирование → реализация → тестирование → внедрение. Каждая стадия начинается только после полного завершения предыдущей.

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

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

Плюсы и минусы

Плюсы:

• Ясность и четкость процесса.
• Глубокая подготовка и детализация тест-планов.

Минусы:

• Длительная продолжительность цикла тестирования.
• Проблема позднего обнаружения дефектов, что удорожает исправления.
• Жёсткость модели: тяжело вносить изменения.

Agile (Гибкая методология)

Agile-методология основана на коротких итерациях (спринтах), когда разработка и тестирование идут параллельно, а изменения вносятся по ходу процесса. В Agile принято работать небольшими шагами, стремясь выпустить MVP (Minimum Viable Product) и постоянно его улучшать.

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

• Тестирование идёт параллельно с разработкой, тесты пишутся одновременно с кодом.
• Используются методы TDD (Test-Driven Development) и BDD (Behavior-Driven Development), когда тесты пишут до реализации функционала.
• Тестирование распространяется на всех участников команды, включая разработчиков.
• Этап тестирования короче, но он повторяется в каждой итерации, что позволяет быстро находить и исправлять ошибки.

Плюсы и минусы

Плюсы:

• Быстрый отклик на изменения.
• Раннее выявление дефектов.
• Участие команды в целом процессе разработки.

Минусы:

• Больше нагрузки на разработчиков и тестировщиков.
• Может потребоваться дополнительная дисциплина и организация для поддержания постоянного качества.

Какой подход выбрать

• Waterfall хорош для проектов с чётко определёнными требованиями и жесткими сроками.
• Agile идеален для проектов с меняющимися требованиями, когда важнее быстро показать результат и оперативно адаптироваться к изменениям.

Итак, выбор между Agile и Waterfall зависит от специфики проекта, команды и культуры организации. В современных проектах в условиях переменных условий, особенно в ИТ-проектах, всё чаще применяется Agile.

Тесты на контроль и обеспечение качества

Качество программного продукта — это результат комплексной работы, включающей не только тестирование готового продукта, но и организацию системы, предотвращающей появление дефектов. Два ключевых процесса, обеспечивающих высокое качество ПО:

• Quality Assurance (QA) — направлена на профилактику и предупреждение дефектов
• Quality Control (QC) — занимается непосредственной проверкой готового продукта на соответствие требованиям

Они действуют в тесной взаимосвязи, дополняя друг друга: Рассмотрим подробнее, как устроены и как взаимодействуют эти процессы.