Инженерное тестирование программного обеспечения

Введение в тестирование: цели, принципы и место в SDLC

Добро пожаловать в курс «Инженерное тестирование программного обеспечения». Это первая статья, которая заложит фундамент для всего дальнейшего обучения. Многие новички ошибочно полагают, что тестирование — это просто поиск ошибок или хаотичное нажатие кнопок в надежде «сломать» программу. На самом деле, это строгая инженерная дисциплина, требующая аналитического склада ума, понимания архитектуры и знания процессов разработки.

В этой статье мы разберем, чем тестирование отличается от обеспечения качества (QA), зачем оно на самом деле нужно бизнесу, на каких семи принципах оно строится и какое место занимает в жизненном цикле разработки ПО (SDLC).

Что такое тестирование?

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

Важно понимать, что тестирование — это не только запуск программы и проверка ее работы. Это также проверка документации, анализ требований и предотвращение дефектов еще до написания первой строчки кода.

Иерархия понятий: QA, QC и Testing

В индустрии часто путают термины QA, QC и Тестирование. Давайте разграничим их, так как это критически важно для понимания вашей будущей роли.

!Схема, показывающая вложенность понятий: Тестирование является частью QC, а QC является частью QA.

Quality Assurance (QA — Обеспечение качества): Это совокупность активностей, направленных на выстраивание процессов, которые гарантируют качество. QA отвечает на вопрос: «Как и что мы делаем, чтобы не допустить ошибок?». Это превентивная мера.

Quality Control (QC — Контроль качества): Это совокупность активностей, направленных на проверку готовности продукта соответствовать требованиям. QC отвечает на вопрос: «Соответствует ли результат ожиданиям?». Это мера проверки.

Testing (Тестирование): Это конкретный технический процесс проверки системы, часть QC. Тестирование отвечает на вопрос: «Где в системе есть несоответствия?».

Простой пример из жизни: * QA: Создание инструкции по сборке автомобиля и обучение рабочих. * QC: Проверка собранного автомобиля на конвейере перед отправкой в салон. * Testing: Тест-драйв автомобиля для проверки тормозов и двигателя.

Цели тестирования

Глобальная цель тестирования — не «найти все баги» (это невозможно, как мы узнаем позже), а предоставить информацию о рисках и снизить вероятность сбоя в промышленной эксплуатации.

Основные цели включают:

* Обнаружение дефектов: Найти проблемы до того, как их найдут пользователи. * Предотвращение дефектов: Анализ требований на ранних этапах позволяет избежать ошибок в логике еще до начала разработки. * Повышение уверенности в качестве: Если тесты прошли успешно, мы можем с большей уверенностью выпускать релиз. * Предоставление информации: Бизнес должен знать, в каком состоянии находится продукт, чтобы принимать решения (например, перенести дату релиза).

Верификация и Валидация

В контексте целей часто используются два термина, которые звучат похоже, но имеют разный смысл:

* Верификация (Verification): Проверка того, что продукт соответствует задокументированным требованиям. > «Делаем ли мы продукт правильно?» * Валидация (Validation): Проверка того, что продукт соответствует реальным потребностям и ожиданиям пользователя. > «Делаем ли мы правильный продукт?»

Можно создать идеально работающую программу без багов (успешная верификация), которая будет абсолютно бесполезна для пользователя (проваленная валидация).

Семь принципов тестирования

Международный совет по квалификации тестировщиков (ISTQB) выделяет 7 фундаментальных принципов, которые являются «заповедями» для любого инженера по качеству.

1. Тестирование демонстрирует наличие дефектов

Тестирование может показать, что дефекты есть, но не может доказать, что их нет. Даже если все тесты прошли успешно, это не гарантия отсутствия багов. Это лишь означает, что наши текущие тесты их не нашли. Мы снижаем вероятность наличия дефектов, но никогда не сводим её к нулю.

2. Исчерпывающее тестирование невозможно

Проверить все возможные комбинации входных данных, сценариев и условий невозможно, за исключением тривиальных случаев. Вместо попыток проверить «всё», мы используем анализ рисков и приоритеты.

Рассмотрим пример. Допустим, у нас есть поле для ввода пароля длиной 10 символов, где можно использовать только строчные английские буквы (26 символов).

Количество комбинаций рассчитывается по формуле:

Где: * — общее количество возможных комбинаций. * — размер алфавита (количество доступных символов, в нашем случае 26). * — длина строки (в нашем случае 10).

Подставим значения:

Где — это 26 в 10-й степени, что приблизительно равно 141 триллиону комбинаций. Если проверка одной комбинации занимает 1 миллисекунду, на проверку всего поля уйдут тысячи лет. Поэтому мы используем техники тест-дизайна (о которых поговорим в следующих статьях), чтобы выбрать минимальный набор проверок с максимальной эффективностью.

3. Раннее тестирование

Активности по тестированию должны начинаться как можно раньше в жизненном цикле разработки. Ошибка, найденная на этапе требований, стоит копейки (нужно просто переписать текст). Ошибка, найденная в продакшене, может стоить миллионы (репутация, суды, срочные патчи).

!График, демонстрирующий экспоненциальный рост стоимости исправления ошибки: на этапе требований это 1000+.

4. Скопление дефектов (Кластеризация)

Обычно небольшое количество модулей содержит большинство дефектов, обнаруженных перед выпуском. Это проявление принципа Парето: 80% дефектов скрыты в 20% кода. Если вы нашли баг в определенном модуле, велика вероятность, что рядом есть еще.

5. Парадокс пестицида

Если одни и те же тесты повторять много раз, в какой-то момент они перестанут находить новые дефекты. Система «вырабатывает иммунитет» к проверкам, потому что разработчики исправляют именно те места, которые проверяются. Чтобы преодолеть этот парадокс, тестовые наборы нужно регулярно пересматривать и обновлять.

6. Тестирование зависит от контекста

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

7. Заблуждение об отсутствии ошибок

Нахождение и исправление дефектов не поможет, если созданная система не подходит пользователю. Отсутствие багов не гарантирует успешность продукта. Это возвращает нас к разнице между верификацией и валидацией.

Место тестирования в SDLC

SDLC (Software Development Life Cycle) — это жизненный цикл разработки ПО. Это путь, который проходит программа от идеи до вывода из эксплуатации.

Классические этапы SDLC:

Сбор и анализ требований.

Дизайн и проектирование.

Разработка (кодинг).

Тестирование.

Развертывание и поддержка.

Сдвиг влево (Shift Left)

В старых моделях (например, «Водопад») тестирование начиналось только после того, как код полностью написан. Это приводило к тому, что ошибки проектирования обнаруживались слишком поздно.

Современный подход, называемый Shift Left, подразумевает вовлечение тестировщиков на самых ранних этапах. Тестировщики: * Проверяют требования на полноту и непротиворечивость. * Участвуют в обсуждении архитектуры. * Пишут тесты параллельно с написанием кода разработчиками.

Таким образом, тестирование — это не «этап перед релизом», а непрерывная активность, пронизывающая весь жизненный цикл разработки.

Резюме

Инженерное тестирование — это сложный процесс, направленный на снижение рисков и обеспечение качества. Помните, что ваша задача — не просто искать баги, а предоставлять информацию о качестве продукта. Опираясь на 7 принципов тестирования и понимая разницу между QA и QC, вы сможете выстроить эффективную стратегию проверок в любом проекте.

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

Техники тест-дизайна: классы эквивалентности и граничные значения

В предыдущей статье мы разобрали один из семи принципов тестирования: исчерпывающее тестирование невозможно. Мы выяснили, что проверить все возможные комбинации входных данных физически нереально из-за их астрономического количества. Но как тогда выбрать те самые проверки, которые с наибольшей вероятностью найдут дефекты, не тратя на это столетия?

Здесь на сцену выходят техники тест-дизайна. Это набор правил и алгоритмов, которые помогают инженеру создавать эффективные тест-кейсы. Сегодня мы изучим две фундаментальные техники, которые используются в 99% задач: Классы эквивалентности и Граничные значения.

Классы эквивалентности (Equivalence Partitioning)

Представьте, что вы тестируете поле ввода возраста при регистрации на сайте знакомств. Допустимый возраст: от 18 до 99 лет. Нужно ли нам проверять ввод числа 19? А 20? А 21? А 45?

С точки зрения кода, обработка числа 19 и числа 45, скорее всего, будет абсолютно одинаковой. Если система пропускает 19, она пропустит и 45. Эти данные эквивалентны.

Классы эквивалентности — это техника, при которой мы разделяем весь набор возможных входных данных на группы (классы). Данные внутри одной группы обрабатываются системой одинаково. Идея проста: если тест проходит для одного значения из класса, он, скорее всего, пройдет и для всех остальных значений этого класса.

Как это работает?

Мы делим данные на две большие категории:

Валидные классы (Valid): Данные, которые система должна принять (позитивное тестирование).

Невалидные классы (Invalid): Данные, которые система должна отвергнуть или обработать как ошибку (негативное тестирование).

!Схематичное изображение разделения входных данных на классы эквивалентности для поля возраста.

Для нашего примера с возрастом (18–99) классы будут выглядеть так:

* Класс 1 (Невалидный): Числа меньше 18 (например, 10, -5). * Класс 2 (Валидный): Числа от 18 до 99 включительно (например, 25, 50, 99). * Класс 3 (Невалидный): Числа больше 99 (например, 100, 500).

Математическое обоснование

С точки зрения теории множеств, классы эквивалентности должны удовлетворять условию покрытия всего диапазона возможных значений. Если — это всё множество возможных входных данных, а — отдельные классы, то:

Где: * — полная область всех возможных входных данных (Domain). * — отдельные классы эквивалентности. * — знак объединения множеств (сумма всех элементов).

Это означает, что мы не должны «потерять» ни одного возможного значения. Любое число, которое может ввести пользователь, должно попадать в один из классов.

Правило выбора тестов

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

Вместо проверки всех чисел от 18 до 99, мы берем, например, число 35. Если 35 работает, мы считаем, что и 18, и 99 тоже работают (с оговоркой, о которой мы поговорим в следующем разделе).

Итог по классам эквивалентности: Техника позволяет сократить количество тестов с миллионов до нескольких штук, сохраняя при этом высокий уровень покрытия логики.

Анализ граничных значений (Boundary Value Analysis)

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

Почему? Потому что разработчики — люди, и они часто ошибаются в знаках сравнения.

Представьте код:

Разработчик хотел пустить пользователей от 18 лет, но написал > 18 вместо >= 18. В итоге пользователь, которому ровно 18 лет, не сможет войти. Это классическая ошибка «на единицу» (off-by-one error).

Анализ граничных значений — это техника проверки поведения системы на границах классов эквивалентности.

Где искать границы?

Границы находятся там, где один класс переходит в другой. Для диапазона 18–99 границами являются числа 18 и 99.

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

На самой границе.

Сразу перед границей.

Сразу после границы.

!Визуализация проверки нижней границы диапазона: проверяем точку границы и соседние значения.

Для нашего примера (18–99):

Нижняя граница (18): * 17 (Boundary - 1): Ожидаем отказ. Проверяет, не слишком ли «широко» открыта граница. * 18 (Boundary): Ожидаем успех. Проверяет, включена ли граница в диапазон. * 19 (Boundary + 1): Ожидаем успех. Подтверждает, что мы вошли в валидный диапазон.

Верхняя граница (99): * 98 (Boundary - 1): Ожидаем успех. * 99 (Boundary): Ожидаем успех. * 100 (Boundary + 1): Ожидаем отказ.

Формула проверки границ

Если — минимальное допустимое значение, а — максимальное, то полный набор тестов для границ выглядит так:

Где: * — множество тестовых значений. * — нижняя граница диапазона. * — верхняя граница диапазона. * и — шаг минимального приращения (для целых чисел это 1, для денег это может быть 0.01).

> Важно: Иногда используют упрощенный подход (2 значения на границу), но для надежности рекомендуется проверять 3 значения, особенно в критически важных системах.

Комплексный пример: Система скидок

Давайте объединим обе техники на реальной задаче.

ТЗ: Интернет-магазин предоставляет скидку в зависимости от суммы заказа: * От 0 до 1000 рублей — скидка 0%. * От 1001 до 5000 рублей — скидка 5%. * Свыше 5000 рублей — скидка 10%. * Отрицательные суммы недопустимы.

Шаг 1: Выделяем классы эквивалентности

Невалидный: Сумма < 0.

Валидный 1 (0%): 0 – 1000.

Валидный 2 (5%): 1001 – 5000.

Валидный 3 (10%): > 5000 (например, до 1 000 000, если есть техническое ограничение поля).

Шаг 2: Определяем граничные значения

Нам нужно проверить стыки между этими классами.

Граница 0 (Начало): * -1 (Невалидный) * 0 (Валидный, 0%)

Граница 1000/1001 (Переход 0% -> 5%): * 1000 (Валидный, 0%) * 1001 (Валидный, 5%)

Граница 5000/5001 (Переход 5% -> 10%): * 5000 (Валидный, 5%) * 5001 (Валидный, 10%)

Итоговый набор тестов

Вместо того чтобы тестировать тысячи значений, мы выбираем минимально необходимый набор:

-1 (Проверка защиты от дурака)

0 (Нижняя граница первого диапазона)

500 (Представитель класса 0–1000 — тест внутри класса)

1000 (Верхняя граница 0%)

1001 (Нижняя граница 5%)

3000 (Представитель класса 1001–5000)

5000 (Верхняя граница 5%)

5001 (Нижняя граница 10%)

10000 (Представитель класса >5000)

Всего 9 тестов покрывают всю логику начисления скидок с высокой надежностью.

Частые ошибки новичков

Забытые невалидные классы. Часто тестируют только то, что «должно работать», забывая проверить ввод букв, спецсимволов или отрицательных чисел.

Скрытые границы. Границы не всегда очевидны из ТЗ. Например, в поле ввода имени может быть скрытое ограничение базы данных в 255 символов. Это тоже граница.

Зависимость от типа данных. Для целых чисел шаг границы — 1. Но если вы тестируете время (секунды), то границей для 12:00 может быть 11:59:59, а не 11:00.

Резюме

* Классы эквивалентности помогают нам не делать лишнюю работу, группируя похожие данные. * Граничные значения помогают найти самые коварные баги, которые прячутся на стыках условий. * Эти две техники всегда идут рука об руку. Сначала мы нарезаем «пирог» данных на куски (классы), а потом внимательно осматриваем места разрезов (границы).

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

Уровни и типы тестирования: пирамида тестирования на практике

В предыдущих статьях мы заложили фундамент: разобрались с целями тестирования, изучили SDLC и освоили техники тест-дизайна (классы эквивалентности и граничные значения). Теперь у нас есть понимание как создавать тесты. Но возникает следующий логичный вопрос: что именно мы тестируем и на каком этапе?

Представьте, что мы строим автомобиль. Техники тест-дизайна помогают нам проверить, правильно ли работает педаль тормоза (граничные значения нажатия). Но достаточно ли проверить только педаль? Нужно ли проверять тормозную систему в сборе? А как машина ведет себя на трассе? А удобно ли водителю?

В этой статье мы структурируем хаос проверок, разделив их на уровни и типы, а также познакомимся с концепцией Пирамиды тестирования — главной стратегией распределения усилий в инженерном тестировании.

Уровни тестирования (Levels of Testing)

Уровни тестирования определяют, над чем производится действие и насколько глубоко мы погружаемся в систему. Традиционно выделяют четыре основных уровня, которые идут последовательно в процессе разработки (модель V-model).

1. Модульное тестирование (Unit Testing)

Это самый низкий уровень. Здесь объектом тестирования является наименьшая неделимая часть кода — модуль, функция, класс или метод.

* Кто делает: Обычно сами разработчики. * Цель: Убедиться, что конкретный «кирпичик» системы работает изолированно от остальных. * Особенности: Эти тесты очень быстрые, дешевые в написании и выполняются автоматически.

Пример: У нас есть функция calculate_discount(price), которая считает скидку. Юнит-тест просто подает на вход число 1000 и проверяет, что на выходе вернулось 950. База данных и интерфейс при этом не затрагиваются.

2. Интеграционное тестирование (Integration Testing)

Даже если все детали двигателя идеальны, это не гарантирует, что собранный двигатель заведется. Интеграционное тестирование проверяет взаимодействие между компонентами.

* Кто делает: Разработчики или автоматизаторы тестирования (SDET). * Цель: Найти ошибки в стыковке модулей (неверный формат данных, ошибки API, проблемы с базой данных).

Типы интеграции: * Компонентная интеграция: Взаимодействие между двумя классами кода. * Системная интеграция: Взаимодействие нашей системы с внешним сервисом (например, платежным шлюзом банка).

3. Системное тестирование (System Testing)

На этом уровне мы проверяем систему целиком, как единый продукт. Именно здесь чаще всего работают функциональные тестировщики (Manual QA).

* Кто делает: QA-инженеры. * Цель: Проверить соответствие готового продукта функциональным и нефункциональным требованиям. * Особенности: Тесты проводятся в окружении, максимально приближенном к боевому (Production). Мы проверяем сценарии от начала до конца (End-to-End).

4. Приемочное тестирование (Acceptance Testing)

Финальный этап перед релизом. Здесь решается вопрос: «Готов ли продукт к использованию реальными людьми?».

* Кто делает: Заказчик, продукт-менеджер или группа реальных пользователей (бета-тестирование). * Цель: Валидация продукта (вспоминаем разницу между верификацией и валидацией из первой статьи).

Пирамида тестирования

Одна из главных проблем в тестировании — ограниченность ресурсов (времени и денег). Мы не можем проверять всё вручную на системном уровне — это слишком долго.

Майк Кон (Mike Cohn) предложил концепцию Пирамиды тестирования, которая показывает оптимальное соотношение количества тестов на разных уровнях.

!Классическая пирамида тестирования, демонстрирующая, что дешевых модульных тестов должно быть много, а дорогих системных — мало.

Логика пирамиды

Основание (Unit Tests): Их должно быть больше всего (70-80%). Они выполняются за миллисекунды и сразу показывают место поломки.

Середина (Integration Tests): Их меньше (15-20%). Они медленнее, так как требуют поднятия контекста (БД, сервисы).

Верхушка (UI / E2E Tests): Их должно быть минимум (5-10%). Это тесты, которые кликают по кнопкам в браузере. Они самые медленные, хрупкие (верстка поехала — тест упал) и дорогие в поддержке.

Математика эффективности

Давайте посчитаем, почему пирамида выгодна, используя упрощенную формулу общего времени выполнения тестов:

Где: * — общее время прохождения всех тестов. * — количество модульных тестов. * — время выполнения одного модульного теста (обычно сек). * — количество UI тестов. * — время выполнения одного UI теста (обычно сек).

Если у нас 1000 проверок, и мы сделаем их все через UI (антипаттерн «Перевернутая пирамида» или «Рожок мороженого»), то:

Если мы распределим их по пирамиде (900 unit, 100 UI):

Разница колоссальная: 3 часа против 17 минут на каждый прогон тестов.

Типы тестирования (Types of Testing)

Если уровни отвечают на вопрос «Где?», то типы отвечают на вопрос «Что проверяем?».

Функциональное тестирование

Проверяет функции системы. Отвечает на вопрос: «Что делает система?». * Корректность вычислений. * Обработка данных. * Взаимодействие интерфейса.

Нефункциональное тестирование

Проверяет атрибуты качества системы. Отвечает на вопрос: «Как работает система?».

Основные виды:

Тестирование производительности (Performance Testing):

Load Testing:* Выдержит ли система ожидаемую нагрузку (1000 пользователей)? Stress Testing:* При какой нагрузке система упадет (поиск предела)?

Тестирование удобства использования (Usability Testing): Понятен ли интерфейс пользователю?

Тестирование безопасности (Security Testing): Защищена ли система от взлома и утечек данных?

Тестирование совместимости (Compatibility Testing): Работает ли сайт в Chrome, Safari и на мобильных устройствах?

Связанные с изменениями

Когда в код вносятся правки, нам нужны два специфических типа проверок:

Re-testing (Подтверждающее тестирование): Проверка того, что конкретный баг, найденный ранее, действительно исправлен. Мы проверяем только то место, где была ошибка.

Regression Testing (Регрессионное тестирование): Проверка того, что исправление бага или новая фича не сломали старый работающий функционал. Это гарантия того, что мы не сделали «шаг вперед, два назад».

Резюме

Инженерный подход к тестированию требует стратегии. Нельзя просто «тестировать всё подряд».

Мы используем уровни тестирования (Unit -> Integration -> System -> Acceptance), чтобы ловить ошибки как можно раньше и дешевле.

Мы строим пирамиду тестирования, делая упор на быстрые модульные тесты и минимизируя медленные UI-тесты.

Мы различаем функциональные (что делает) и нефункциональные (как работает) проверки, чтобы обеспечить комплексное качество продукта.

В следующей статье мы перейдем к практике и разберем жизненный цикл дефекта (Bug Lifecycle): как правильно документировать баги, чтобы разработчики их исправляли, а не закрывали со статусом "Won't Fix".

Основы автоматизации: выбор инструментов и построение фреймворка

В предыдущей статье мы подробно разобрали пирамиду тестирования и выяснили, что ручная проверка всего функционала на системном уровне (UI) — это долго, дорого и неэффективно. Мы пришли к выводу, что основание пирамиды должны составлять быстрые и стабильные модульные тесты. Но как именно перейти от теории к практике? Как заставить компьютер выполнять рутинную работу за нас?

В этой статье мы погрузимся в мир автоматизированного тестирования. Мы разберем, когда автоматизация выгодна, а когда — убыточна, как выбрать правильные инструменты из зоопарка технологий и что такое Test Automation Framework (фреймворк автоматизации тестирования).

Что такое автоматизация тестирования?

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

Важно понимать: автоматизация — это разработка. Автотест — это такой же программный код, как и само приложение. Он требует проектирования, поддержки, рефакторинга и версионирования. Если вы думаете, что автоматизация — это просто «запись и воспроизведение» (Record & Playback) действий мыши, то вы застряли в начале 2000-х годов.

ROI: Когда стоит автоматизировать?

Не все тесты нужно автоматизировать. Главный критерий принятия решения — ROI (Return on Investment), или возврат инвестиций. Автоматизация требует времени на написание кода, но экономит время при каждом последующем запуске.

Формула расчета ROI для автоматизации выглядит следующим образом:

Где: * — коэффициент возврата инвестиций (в процентах). * — выгода (время, сэкономленное на ручном тестировании за определенный период). * — затраты (время на разработку, поддержку и инфраструктуру автотестов).

!График, показывающий точку окупаемости автоматизации: сначала она дороже ручного труда, но со временем становится значительно выгоднее.

Что стоит автоматизировать:

Регрессионные тесты: Сценарии, которые запускаются перед каждым релизом и не меняются годами.

Smoke-тесты: Критически важный функционал (логин, оплата), который проверяется ежедневно.

Сложные вычисления: Проверки, где человеку легко ошибиться с калькулятором, а скрипт посчитает мгновенно.

Нагрузочное тестирование: Создать 10 000 одновременных пользователей вручную невозможно.

Что НЕ стоит автоматизировать:

Одноразовые проверки: Если тест нужно прогнать один раз, быстрее сделать это руками.

UX/UI (Usability): Скрипт не оценит, красиво ли выглядит кнопка и удобно ли ей пользоваться.

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

Обзор инструментов автоматизации

Выбор инструмента зависит от уровня пирамиды тестирования и технологического стека проекта. Не существует «лучшего» инструмента, есть подходящий под задачу.

Уровень Unit (Модульные тесты)

Здесь инструменты обычно привязаны к языку разработки.

* Java: JUnit, TestNG. * Python: PyTest, Unittest. * JavaScript/TypeScript: Jest, Mocha. * C#: NUnit, xUnit.

Уровень API (Интеграционные тесты)

Здесь мы проверяем взаимодействие систем без браузера.

* Postman (Newman): Отлично подходит для старта. Позволяет писать тесты на JS внутри графического интерфейса. * RestAssured (Java): Мощная библиотека для тестирования REST-сервисов. Де-факто стандарт в мире Java. * Requests (Python): Простая и элегантная библиотека для HTTP-запросов, часто используемая в связке с PyTest.

Уровень UI (Системные тесты)

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

| Инструмент | Языки | Описание | | :--- | :--- | :--- | | Selenium WebDriver | Java, Python, C#, JS, Ruby | «Дедушка» автоматизации. Стандарт индустрии. Гибкий, поддерживает все браузеры, но требует настройки драйверов и написания оберток. | | Playwright | TS/JS, Python, Java, C# | Современный инструмент от Microsoft. Быстрый, надежный, умеет работать с несколькими вкладками и перехватывать сетевые запросы «из коробки». | | Cypress | JavaScript/TypeScript | Популярен во фронтенд-разработке. Работает прямо внутри браузера, что дает высокую скорость, но имеет ограничения (например, сложно работать с несколькими вкладками). |

Построение Test Automation Framework

Просто написать скрипт, который кликает по кнопкам — это не инженерный подход. Если у вас 500 тестов, и в каждом вы пишете driver.findElement(By.id("login")), то при смене ID кнопки вам придется править 500 файлов.

Вам нужен Framework (Каркас). Это набор правил, библиотек и паттернов, которые организуют код тестов.

!Архитектура тестового фреймворка: от базовых библиотек до отчетов и CI/CD.

Основные компоненты фреймворка:

Core (Ядро): Обертки над драйвером (Selenium/Playwright), управление конфигурацией (URL стенда, браузер).

Data Helpers: Генераторы тестовых данных (случайные email, имена, даты).

Page Objects: Описание страниц приложения (об этом ниже).

Reporting: Инструменты для красивых отчетов (например, Allure Report). Логи с текстом «Test Failed» читать неудобно, нужны скриншоты и графики.

Паттерн Page Object Model (POM)

Это самый важный паттерн в UI-автоматизации. Его суть заключается в разделении логики теста и описания страницы.

Каждая веб-страница (или ее часть) описывается как отдельный класс в коде. Элементы страницы (кнопки, поля) становятся переменными класса, а действия пользователя — методами.

Пример без POM (Плохой код):

Пример с POM (Хороший код):

Сначала описываем страницу в отдельном файле:

А сам тест становится чистым и читаемым:

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

Поддержка: Если разработчики поменяли ID кнопки «Войти», мы меняем его только в одном месте (в классе LoginPage), а не в 50 тестах.

Читаемость: Тест читается как сценарий на английском языке.

Переиспользование: Метод login() можно использовать в сотнях разных тестов.

Лучшие практики (Best Practices)

Чтобы ваш фреймворк не превратился в монстра, которого боятся трогать, следуйте этим правилам:

Атомарность: Один тест проверяет одну вещь. Не пытайтесь в одном тесте проверить регистрацию, покупку, возврат товара и смену пароля. Если тест упадет, вы не поймете, где именно проблема.

Независимость: Тесты не должны зависеть друг от друга. Тест №2 не должен ожидать, что Тест №1 создал пользователя. Каждый тест должен сам подготовить себе данные (Pre-condition) и убрать за собой (Post-condition).

Ожидания (Waits): Никогда не используйте жесткие задержки вроде sleep(5) (спать 5 секунд). Используйте «умные ожидания» (Smart Waits), которые ждут появления элемента: wait.until(element_is_visible). Интернет может быть медленным, и 5 секунд может не хватить, а может быть быстрым, и тогда вы просто так теряете время.

Резюме

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

Мы изучили: * ROI: Формулу, помогающую понять, окупится ли автоматизация. * Инструменты: Selenium, Playwright, RestAssured и другие. * Фреймворк: Почему важна структура, а не просто набор скриптов. * Page Object Model: Паттерн, который спасает от хаоса при изменениях в верстке.

В следующей статье мы перейдем к теме CI/CD (Continuous Integration / Continuous Delivery) и узнаем, как встроить наши автотесты в конвейер разработки, чтобы они запускались автоматически при каждом сохранении кода разработчиком.

Управление дефектами, отчетность и метрики качества

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

Просто сказать разработчику «там не работает» — недостаточно. В инженерном тестировании процесс обнаружения, документирования и исправления ошибок строго регламентирован. В этой статье мы разберем жизненный цикл дефекта, научимся писать идеальные баг-репорты, отличать серьезность от приоритета и измерять качество продукта с помощью математики.

Что такое дефект?

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

Управление дефектами — это не просто их поиск, а процесс, гарантирующий, что найденные проблемы будут исправлены и не появятся снова.

Жизненный цикл дефекта (Bug Lifecycle)

Баг не исчезает сразу после того, как вы его нашли. Он проходит определенные этапы существования, называемые жизненным циклом. Эти этапы фиксируются в системе баг-трекинга (например, Jira, YouTrack, Redmine).

!Диаграмма переходов статусов дефекта от создания до закрытия.

Основные статусы:

New (Новый): Дефект только что заведен тестировщиком. Он еще не проанализирован.

Assigned (Назначен): Тимлид или менеджер назначил дефект на конкретного разработчика.

In Progress (В работе): Разработчик начал исправлять ошибку.

Fixed (Исправлен): Разработчик внес правки в код и считает, что проблема решена. Теперь мяч снова на стороне тестировщика.

Verified (Проверен): Тестировщик проверил исправление (Re-testing) и подтверждает, что бага больше нет.

Closed (Закрыт): Финальный статус. Ошибка устранена и проверена.

Reopened (Переоткрыт): Если после статуса Fixed тестировщик видит, что проблема осталась, он возвращает баг в работу.

Иногда баг может получить специфические статусы: * Duplicate: Такой баг уже есть в системе. * Rejected / Won't Fix: Это не баг, а фича (или исправлять слишком дорого/рискованно). * Deferred: Отложено до следующего релиза.

Анатомия идеального баг-репорта

Плохой баг-репорт вызывает у разработчика раздражение и желание его закрыть. Хороший баг-репорт ускоряет исправление. Ваша цель — ответить на три вопроса: Что случилось? Где случилось? При каких условиях?

Структура отчета:

Summary (Заголовок): Краткая суть проблемы. Должен быть понятен без открытия самого тикета.

Плохо:* «Кнопка не работает». Хорошо:* «Ошибка 404 при нажатии кнопки 'Оплатить' в корзине авторизованным пользователем».

Description (Описание): Детали, окружение, ссылки.

Steps to Reproduce (Шаги воспроизведения): Самая важная часть. Алгоритм действий, приводящий к ошибке.

Expected Result (Ожидаемый результат): Как система должна работать согласно требованиям.

Actual Result (Фактический результат): Как система работает на самом деле.

Attachments (Вложения): Скриншоты, видео, логи сервера.

Severity vs Priority

Новички часто путают эти два понятия, выставляя везде «Критический» уровень. Давайте разберем разницу.

* Severity (Серьезность): Техническая степень влияния дефекта на систему. Насколько сильно сломана программа? * Priority (Приоритет): Бизнес-очередность исправления. Как быстро нужно это починить?

| Ситуация | Severity | Priority | Почему? | | :--- | :--- | :--- | :--- | | Сайт падает при загрузке главной страницы | Blocker | High | Системой невозможно пользоваться, чинить немедленно. | | Опечатка в названии компании на главной странице | Minor | High | Технически система работает идеально, но для репутации бизнеса это катастрофа. | | Кнопка «Купить» не работает в старом браузере IE 6 | Critical | Low | Функция блокирована (Critical), но этим браузером пользуется 0.01% людей (Low). |

Метрики качества

Как понять, качественный у нас продукт или нет? Фраза «багов вроде нет» не подходит для инженерного отчета. Нам нужны цифры. Рассмотрим две фундаментальные метрики.

1. Плотность дефектов (Defect Density)

Эта метрика показывает, насколько «забагован» определенный модуль или вся система относительно её размера. Она помогает выявить проблемные зоны в коде.

Формула расчета:

Где: * — плотность дефектов (Defect Density). * — общее количество обнаруженных и подтвержденных дефектов. * — размер программного продукта. Обычно измеряется в тысячах строк кода (KLOC) или функциональных точках (Function Points).

Например, если в модуле оплаты (размером 5000 строк кода, то есть 5 KLOC) найдено 25 багов, то плотность равна:

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

2. Эффективность устранения дефектов (DRE)

Defect Removal Efficiency (DRE) — это метрика, которая оценивает эффективность работы команды тестирования. Она показывает, какой процент ошибок мы нашли до релиза, по сравнению с тем, что нашли пользователи после релиза.

Формула:

Где: * — эффективность устранения дефектов в процентах. * — количество дефектов, найденных командой тестирования во время разработки. * — количество дефектов, найденных пользователями в промышленной эксплуатации (на продакшене) за определенный период после релиза.

Пример: Тестировщики нашли 90 багов перед релизом. После выхода обновления пользователи нашли еще 10 багов.

Где — это показатель эффективности. Чем ближе это число к 100%, тем лучше работает QA-отдел. Если DRE падает ниже 85-90%, это сигнал о проблемах в процессах тестирования.

Отчетность (Reporting)

Метрики и списки багов бесполезны, если о них никто не знает. Отчетность — это способ коммуникации с бизнесом.

Основные виды отчетов:

Daily Status Report: Короткая сводка за день. Что сделали, что планируем, есть ли блокирующие проблемы.

Test Summary Report: Финальный отчет перед релизом. Содержит:

* Общее количество выполненных тест-кейсов (Passed / Failed). * Список известных проблем (Known Issues), с которыми мы выходим в релиз. * Рекомендация QA: «Готов к релизу» (Go) или «Не готов» (No-Go).

> «Качество — это не действие, это привычка». — Аристотель

Резюме

Управление дефектами — это дисциплина, превращающая хаос ошибок в упорядоченный процесс улучшения продукта.

Мы узнали, что баг живет своей жизнью: от New до Closed.

Мы научились различать Severity (техническое влияние) и Priority (бизнес-срочность).

Мы освоили математику качества: Defect Density помогает найти плохой код, а DRE оценивает нашу собственную эффективность.

Этой статьей мы завершаем теоретический блок курса. Теперь у вас есть полный набор знаний: от теории и дизайна тестов до автоматизации и метрик. Вы готовы применять инженерный подход на практике.