Основы тестирования программного обеспечения

Введение в тестирование: цели, принципы и роль QA в жизненном цикле разработки (SDLC)

Добро пожаловать в курс «Основы тестирования программного обеспечения». Мы начинаем наше путешествие в мир качества, поиска дефектов и создания надежных цифровых продуктов.

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

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

Что такое тестирование и зачем оно нужно?

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

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

История первого «бага»

Термин «баг» (жук) в контексте компьютерных ошибок стал популярным благодаря Грейс Хоппер. В 1947 году операторы машины Mark II нашли мотылька, застрявшего между контактами реле, что вызвало сбой в работе. Они вклеили мотылька в технический журнал с подписью: «First actual case of bug being found» (Первый реальный случай обнаружения жука).

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

Основные цели тестирования

Зачем компании тратят огромные бюджеты на отделы тестирования? Вот ключевые цели:

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

Обнаружение дефектов. Чем раньше найдена ошибка, тем дешевле её исправить.

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

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

QA, QC и Тестирование: в чем разница?

Новички часто путают понятия QA (Quality Assurance), QC (Quality Control) и Testing. Давайте разберемся, так как это разные уровни ответственности.

!Иерархия понятий: QA включает в себя QC, а QC включает в себя Тестирование

1. Testing (Тестирование)

Это непосредственно процесс проверки системы. * Вопрос: «Работает ли эта кнопка так, как задумано?» * Действие: Тестировщик пишет тест-кейс, проходит его и заводит баг-репорт, если нашел ошибку.

2. QC (Quality Control — Контроль качества)

Это набор активностей, направленных на проверку готовности продукта. QC включает в себя тестирование, но также охватывает анализ результатов тестирования, работу с метриками и проверку соответствия требованиям. * Вопрос: «Соответствует ли продукт заявленным требованиям качества?» * Действие: Проверка кода (Code Review), запуск автотестов перед релизом, анализ количества найденных багов.

3. QA (Quality Assurance — Обеспечение качества)

Это самый широкий процесс, охватывающий весь цикл разработки. Цель QA — выстроить процессы так, чтобы дефекты не появлялись. Это превентивная мера. * Вопрос: «Как нам улучшить процесс разработки, чтобы ошибки не возникали?» * Действие: Внедрение стандартов кодирования, обучение сотрудников, выбор инструментов, настройка CI/CD (непрерывной интеграции).

> QA занимается процессом, QC — продуктом, а Тестирование — конкретными проверками.

7 принципов тестирования

Существует международный стандарт ISTQB (International Software Testing Qualifications Board), который выделяет 7 фундаментальных принципов тестирования. Понимание этих принципов отличает профессионала от любителя.

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

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

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

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

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

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

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

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

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

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

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

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

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

Нахождение и исправление багов не поможет, если созданная система не подходит пользователю. Можно создать идеально работающее приложение без единого бага, которое никому не нужно или неудобно в использовании.

Роль QA в жизненном цикле разработки (SDLC)

SDLC (Software Development Life Cycle) — это период времени, который начинается с момента принятия решения о создании программного продукта и заканчивается в момент его полного изъятия из эксплуатации.

Многие думают, что тестировщик вступает в игру только после того, как программист написал код. Это грубая ошибка, свойственная устаревшим моделям разработки.

!Вовлеченность QA-инженера на всех этапах создания ПО

Рассмотрим, что делает QA-инженер на каждом этапе:

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

QA подключается уже здесь. Он читает техническое задание (ТЗ) и ищет в нем логические противоречия. Пример:* В ТЗ написано «Поле принимает только цифры», а на макете дизайнера в этом поле нарисован email. QA задает вопрос аналитику: «Так цифры или email?». Этим он предотвращает баг еще до написания кода.

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

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

3. Разработка (Coding)

Пока разработчики пишут код, тестировщики пишут Тест-кейсы (сценарии проверки) и готовят тестовые данные. К моменту, когда первая версия программы готова, у QA уже готов полный набор проверок.

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

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

5. Внедрение и поддержка

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

Заключение

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

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

Классификация тестирования: уровни пирамиды, функциональные и нефункциональные виды проверок

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

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

В этой статье мы разберем три ключевых измерения классификации тестирования:

Уровни тестирования (Пирамида тестирования).

Типы тестирования (Функциональное и Нефункциональное).

Связанные с изменениями виды (Регрессионное и Ре-тест).

Пирамида тестирования (Testing Pyramid)

Одной из самых важных концепций в современном QA является Пирамида тестирования, популяризированная Майком Коном. Она показывает, как должны распределяться тесты в проекте для достижения максимальной эффективности и скорости.

!Классическая пирамида тестирования, показывающая соотношение количества и стоимости различных уровней проверок

Давайте разберем каждый уровень снизу вверх.

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

Это фундамент пирамиды. * Что тестируем: Самые маленькие, неделимые части кода (функции, методы, классы) в изоляции от остальной системы. * Кто делает: Обычно сами разработчики. * Особенности: Эти тесты пишутся быстро, выполняются за миллисекунды и их должно быть очень много (тысячи). * Пример: У нас есть функция sum(a, b), которая складывает два числа. Юнит-тест проверяет, что sum(2, 2) возвращает 4.

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

* Что тестируем: Взаимодействие между несколькими модулями или компонентами системы. * Кто делает: Разработчики или автоматизаторы (SDET). * Особенности: Проверяем, не «ломается» ли система, когда модули начинают общаться друг с другом. * Пример: Проверка того, что модуль «Корзина» корректно передает итоговую сумму в модуль «Оплата».

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

Именно здесь чаще всего работают функциональные тестировщики (Manual QA). * Что тестируем: Всю систему целиком как единый продукт. * Кто делает: QA-инженеры. * Особенности: Мы проверяем продукт с точки зрения конечного пользователя, используя графический интерфейс (GUI) или API. Окружение должно быть максимально приближено к боевому (Production). * Пример: Пользователь заходит на сайт, добавляет товар в корзину, оплачивает картой и получает чек на почту.

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

Верхушка пирамиды. * Что тестируем: Готовность продукта к релизу и соответствие бизнес-требованиям. * Кто делает: Заказчик, Product Manager или сами пользователи (бета-тестирование). * Особенности: Ответ на вопрос: «Это то, что мы заказывали?».

> Антипаттерн: Рожок мороженого (Ice Cream Cone) > Если в компании мало юнит-тестов, но огромная армия ручных тестировщиков, проверяющих всё через интерфейс, пирамида переворачивается. Это ведет к долгому поиску багов и дорогой поддержке.

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

Это самое глобальное разделение видов тестирования. Если упростить, то: * Функциональное: ЧТО система делает? * Нефункциональное: КАК система работает?

Функциональное тестирование (Functional Testing)

Проверка функций системы на соответствие требованиям. Работает ли кнопка? Сохраняются ли данные? Считается ли скидка?

Внутри функционального тестирования есть своя иерархия по глубине проверки:

Дымовое тестирование (Smoke Testing)

* Короткий цикл тестов, подтверждающий, что приложение вообще «живое» и основные функции работают. Если дымовой тест не прошел, дальше тестировать нет смысла. Аналогия:* Сантехник включил воду, чтобы проверить, не бьет ли фонтан из трубы. Если бьет — нет смысла проверять, хорошо ли закрывается кран.

Тестирование критического пути (Critical Path)

* Проверка сценариев, которыми пользуются 80-90% пользователей в обычной жизни. Пример:* Логин -> Поиск товара -> Покупка.

Расширенное тестирование (Extended Testing)

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

Нефункциональное тестирование (Non-Functional Testing)

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

Вот основные виды нефункциональных проверок:

#### 1. Тестирование производительности (Performance Testing) Нагрузочное (Load Testing): Как ведет себя система при ожидаемой* нагрузке (например, 1000 пользователей одновременно). * Стрессовое (Stress Testing): Поиск предела прочности. Сколько пользователей нужно, чтобы сервер упал? Как система восстанавливается после падения?

#### 2. Тестирование удобства использования (Usability Testing) Понятен ли интерфейс? Удобно ли нажимать на кнопки? Не слишком ли мелкий шрифт? Это субъективная, но важная проверка.

#### 3. Тестирование безопасности (Security Testing) Проверка на уязвимости. Можно ли украсть данные пользователей? Можно ли зайти в админку без пароля? (SQL-инъекции, XSS и прочее).

#### 4. Тестирование совместимости (Compatibility Testing) * Кроссбраузерное: Chrome, Safari, Firefox. * Кроссплатформенное: iOS, Android, Windows, macOS.

#### 5. Тестирование локализации (Localization Testing) Корректность перевода, форматы дат (ДД.ММ.ГГГГ против ММ/ДД/ГГГГ), валюты и направление текста.

Связанные с изменениями виды тестирования

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

Ре-тест (Re-testing)

Это проверка конкретного исправления. * Вы нашли баг: «Не работает кнопка Вход». * Разработчик сказал: «Исправил». Вы идете и проверяете только* кнопку «Вход».

Регрессионное тестирование (Regression Testing)

Это проверка того, что старый функционал не сломался из-за новых изменений. * Разработчик починил кнопку «Вход». * Но из-за изменений в коде авторизации сломалась «Регистрация». * Регрессия направлена на поиск таких побочных эффектов.

!Разница между проверкой исправления (Re-test) и проверкой отсутствия новых ошибок (Regression)

Статическое и Динамическое тестирование

И напоследок, классификация по методу выполнения.

Статическое тестирование (Static Testing)

* Программный код не запускается. * Мы читаем требования, проверяем макеты, проводим ревью кода (Code Review). Цель:* Найти ошибки в логике и документации до того, как они превратятся в код.

Динамическое тестирование (Dynamic Testing)

* Код запускается и выполняется. * Это классическое тестирование: нажатие кнопок, отправка запросов, работа с приложением.

Заключение

Понимание классификации тестирования позволяет QA-инженеру говорить на одном языке с командой и правильно выбирать стратегию проверок.

* Если нужно проверить бизнес-логику — мы идем в Функциональное тестирование. * Если сайт тормозит — мы проводим Нагрузочное. * Если вышел новый релиз — мы обязательно делаем Регрессию.

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

Тестовая документация: правила написания тест-кейсов, чек-листов и оформление баг-репортов

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

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

В этой статье мы научимся писать три главных документа тестировщика:

Чек-лист (Check-list)

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

Баг-репорт (Bug Report)

Чек-лист: краткость — сестра таланта

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

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

Структура чек-листа

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

Пример чек-листа для формы регистрации: * Проверка ввода валидного email. * Проверка ввода email без «@». * Проверка пароля менее 6 символов. * Проверка кнопки «Зарегистрироваться».

Когда использовать чек-листы?

Когда мало времени. Написание подробных инструкций занимает часы, чек-лист пишется за минуты.

Когда команда опытная. Если тестировщики знают продукт наизусть, им не нужны пошаговые инструкции.

Для Дымового тестирования (Smoke Testing). Быстро пробежаться по основным функциям.

Тест-кейс: подробная инструкция

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

В отличие от чек-листа, тест-кейс отвечает на вопросы: Что проверить? Как проверить? Какой результат мы ждем?

Атрибуты идеального тест-кейса

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

Рассмотрим классическую структуру тест-кейса:

#### 1. ID (Идентификатор) Уникальный номер (например, TC-001). Помогает ссылаться на тест в отчетах.

#### 2. Заголовок (Title) Краткое описание сути проверки. Должен отвечать на вопросы: Что? Где? Когда? Плохо:* Проверка логина. Хорошо:* Авторизация пользователя с валидными данными через форму на главной странице.

#### 3. Предварительные условия (Preconditions) Действия, которые нужно выполнить до начала теста, чтобы привести систему в нужное состояние. Пример:* Пользователь зарегистрирован в системе; открыта страница входа.

#### 4. Шаги (Steps) Пошаговая инструкция действий.

Ввести test@email.com в поле «Email».

Ввести 123456 в поле «Пароль».

Нажать кнопку «Войти».

#### 5. Ожидаемый результат (Expected Result) Самая важная часть. Что должно произойти после выполнения шагов? Пример:* Произошел переход в Личный кабинет; в правом верхнем углу отображается имя пользователя.

> Важно: Ожидаемый результат должен быть однозначным. Фразы вроде «система работает корректно» или «страница загрузилась быстро» недопустимы. Корректно — это как? Быстро — это сколько миллисекунд?

Сравнение Чек-листа и Тест-кейса

| Характеристика | Чек-лист | Тест-кейс | | :--- | :--- | :--- | | Детализация | Низкая (только идеи) | Высокая (пошагово) | | Время на создание | Быстро | Долго | | Поддержка | Легко обновлять | Трудно поддерживать актуальность | | Для кого | Опытные сотрудники | Новички и сложные сценарии |

Баг-репорт: искусство жаловаться

Когда фактический результат работы программы не совпадает с ожидаемым, мы находим Баг (дефект). Чтобы разработчик мог его исправить, мы должны оформить Баг-репорт.

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

Структура Баг-репорта

Качественный отчет об ошибке должен отвечать на вопрос: «Как мне (разработчику) воспроизвести это у себя?».

#### 1. Заголовок (Summary) Как и в тест-кейсе, принцип Что? Где? Когда?. Плохо:* Кнопка не работает. Хорошо:* Ошибка 404 при нажатии на кнопку «Оплатить» в корзине авторизованным пользователем.

#### 2. Окружение (Environment) Где воспроизвелась ошибка? (Браузер, версия ОС, модель телефона, версия приложения).

#### 3. Шаги воспроизведения (Steps to Reproduce) Путь к ошибке. Должен быть минимально коротким, но достаточным.

#### 4. Фактический результат (Actual Result) Что произошло на самом деле? (Появилась ошибка, система зависла, списались деньги дважды).

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

#### 6. Вложения (Attachments) Скриншоты, видеозапись экрана, логи сервера. Один скриншот может заменить тысячу слов.

Серьезность и Приоритет (Severity & Priority)

Эти два поля часто путают, но разница между ними критична.

Severity (Серьезность) — насколько сильно дефект влияет на работу системы технически.

Blocker: Система не работает, дальнейшее тестирование невозможно (сайт не открывается).

Critical: Не работает ключевая бизнес-функция (не проходит оплата), обходного пути нет.

Major: Функция не работает, но есть обходной путь (не работает клик мышкой, но работает Enter).

Minor: Незначительная ошибка, не влияющая на бизнес-логику (опечатка в тексте, съехала верстка).

Priority (Приоритет) — как срочно нужно исправить дефект с точки зрения бизнеса.

High: Исправить немедленно (прямо сейчас).

Medium: Исправить в текущем релизе.

Low: Можно исправить, когда будет время.

> Парадокс: Опечатка в названии компании на главной странице — это Minor Severity (система работает, ничего не падает), но High Priority (репутационные риски огромны).

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

Баг не просто создается и исчезает. Он проходит определенный путь.

!Стандартный процесс жизни дефекта от обнаружения до закрытия

New (Новый): Тестировщик создал баг.

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

In Progress (В работе): Разработчик чинит код.

Fixed / Resolved (Исправлен): Разработчик говорит, что починил.

Verified (Проверен): Тестировщик проверяет исправление.

* Если исправлено -> Closed (Закрыт). * Если не исправлено -> Reopened (Переоткрыт) и возвращается разработчику.

Золотые правила документации

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

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

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

Актуализация. Документация имеет свойство устаревать. Если изменился дизайн, а в тест-кейсе написано «Нажать синюю кнопку», а кнопка стала красной — тест-кейс нужно обновить.

Заключение

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

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

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

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

Вспомним второй принцип тестирования: «Исчерпывающее тестирование невозможно». Если у нас есть поле ввода, принимающее цифры от 1 до 100, мы физически можем проверить все 100 вариантов. Но что, если поле принимает любую строку? Или диапазон от 1 до 1 000 000? Проверять каждое значение — значит потратить годы на одну форму.

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

Главная задача тест-дизайна — сократить количество тестов без потери качества покрытия. Мы должны выбрать такие проверки, которые с наибольшей вероятностью найдут баги.

Что такое «Черный ящик»?

Большинство техник, которые мы сегодня разберем, относятся к методам тестирования «Черного ящика» (Black Box Testing).

Представьте себе закрытую коробку. Вы не видите, что внутри: не видите шестеренок, проводов или программного кода. У коробки есть входные отверстия (кнопки, поля ввода) и выходные сигналы (экран, лампочки).

!Концепция черного ящика: мы знаем вход и выход, но не видим внутреннюю реализацию.

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

Теперь перейдем к конкретным техникам, которые позволяют тестировать «черный ящик» эффективно.

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

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

Класс эквивалентности — это набор входных данных, которые обрабатываются программой по одной и той же логике.

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

Представьте, что вы тестируете систему продажи билетов в кино. * Детям до 12 лет — скидка 50%. * Взрослым от 12 до 60 лет — полная цена. * Пенсионерам старше 60 лет — скидка 30%.

Вместо того чтобы проверять каждый возраст (1 год, 2 года, 3 года...), мы разбиваем все возможные числа на классы (интервалы).

Математически это можно записать так:

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

У нас получается три класса:

Класс 1 (Дети): от 0 до 11 лет.

Класс 2 (Взрослые): от 12 до 60 лет.

Класс 3 (Пенсионеры): от 61 года и выше.

Чтобы протестировать эту логику, нам достаточно взять по одному любому значению из каждого класса. Например: 5 лет, 25 лет и 70 лет. Если программа правильно посчитала скидку для 5-летнего, мы предполагаем, что она правильно посчитает и для 6-летнего.

Valid и Invalid

Классы делятся на два типа: * Валидные (Valid): Данные, которые система должна принять (например, возраст 25). * Невалидные (Invalid): Данные, которые система должна отвергнуть или обработать как ошибку (например, возраст -5 или 200, или ввод букв вместо цифр).

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

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

Практика показывает, что разработчики чаще всего ошибаются не в середине диапазона, а на его границах.

В примере с кинотеатром условие «до 12 лет» может быть запрограммировано как if age < 12 или if age <= 12. Разница всего в один знак, но она критична для 12-летнего посетителя.

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

Какие значения брать?

Для каждой границы мы обычно берем два или три значения:

Саму границу.

Значение сразу перед границей.

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

Вернемся к нашему примеру с границей в 12 лет.

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

Нам нужно проверить: * 11 (входит в класс «Дети») * 12 (это точка перехода, куда она попадет? Согласно ТЗ — уже «Взрослый») * 13 (входит в класс «Взрослые»)

Если поле ввода принимает значения от 1 до 100, то граничными значениями будут: * Минимум: 0, 1, 2 * Максимум: 99, 100, 101

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

3. Таблица принятия решений (Decision Table)

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

Например, банк выдает кредит, если:

Возраст заемщика > 18 лет.

Есть постоянная работа.

Нет судимостей.

Если проверять все хаотично, можно запутаться. Для этого используют Таблицу принятия решений.

| Условия / Правила | Тест 1 | Тест 2 | Тест 3 | Тест 4 | | :--- | :--- | :--- | :--- | :--- | | Возраст > 18 | Да | Нет | Да | Да | | Есть работа | Да | Да | Нет | Да | | Нет судимостей | Да | Да | Да | Нет | | Результат | Кредит выдан | Отказ | Отказ | Отказ |

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

4. Диаграмма переходов состояний (State Transition)

Эта техника идеально подходит для тестирования объектов, которые меняют свое состояние в зависимости от действий пользователя.

Классический пример — Заказ в интернет-магазине.

Жизненный цикл заказа:

Новый (создан, но не оплачен).

Оплачен (деньги списались).

В сборке (кладовщик собирает товары).

Отправлен (передан курьеру).

Доставлен (клиент получил товар).

Отменен (клиент передумал).

!Схема переходов состояний заказа: мы видим разрешенные и запрещенные пути.

Суть техники — проверить:

Валидные переходы: Можно ли перейти из «Новый» в «Оплачен»?

Невалидные переходы: Можно ли перейти из «Доставлен» обратно в «Новый»? (Очевидно, нет, и система должна это запрещать).

5. Попарное тестирование (Pairwise Testing)

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

Где — общее количество комбинаций, — количество вариантов в одном списке, а степень — количество списков.

Проверить 10 миллиардов комбинаций невозможно.

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

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

6. Предугадывание ошибок (Error Guessing)

Это единственная неформальная техника. Она основана на опыте и интуиции тестировщика.

Вы смотрите на поле ввода и думаете: «А что, если я введу сюда пробел? А если иероглифы? А если скопирую сюда текст размером в 1 гигабайт?».

Опытный QA знает «слабые места» типичных приложений: * Ввод 0 в поля количества. * Ввод спецсимволов (<, >, /) для проверки на XSS-уязвимости. * Нажатие кнопки «Далее» без заполнения полей. * Потеря интернета в момент оплаты.

Заключение

Использование техник тест-дизайна отличает профессионала от любителя.

* Классы эквивалентности помогают не делать лишнюю работу. * Граничные значения находят самые коварные баги. * Таблицы решений и Диаграммы состояний помогают разобраться в сложной логике.

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

В следующей статье мы поговорим о том, как автоматизировать эти проверки и что такое пирамида автоматизации.

Введение в автоматизацию тестирования и обзор популярных инструментов для QA-специалистов

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

Здесь ручное тестирование становится неэффективным, дорогим и скучным. На помощь приходит автоматизация тестирования.

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

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

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

Проще говоря, это код, который проверяет другой код. Вместо того чтобы человек открывал браузер и нажимал на кнопки, это делает скрипт (робот).

Зачем нам автоматизация?

Многие новички думают, что цель автоматизации — полностью заменить тестировщиков. Это миф. Автоматизация призвана:

Ускорить регрессионное тестирование. То, что человек проверяет 4 часа, скрипт проверит за 5 минут.

Исключить человеческий фактор. Скрипт не устает, не отвлекается на кофе и не пропускает проверки из-за «замыленного» глаза.

Проводить сложные проверки. Например, нагрузочное тестирование (имитация 10 000 пользователей) невозможно провести вручную силами одного отдела.

Экономика автоматизации: ROI

Автоматизация — это дорого. Вам нужно нанять квалифицированного специалиста (SDET — Software Development Engineer in Test) и потратить время на написание кода. Поэтому перед стартом всегда рассчитывают ROI (Return on Investment) — коэффициент окупаемости инвестиций.

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

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

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

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

Что нужно и НЕ нужно автоматизировать

Не все тесты подлежат автоматизации. Существует золотое правило: «Автоматизируй рутину, исследуй новое вручную».

✅ Что нужно автоматизировать:

* Регрессионные тесты: Повторяющиеся проверки старого функционала. * Smoke-тесты: Быстрая проверка работоспособности сборки. * Тесты с большим объемом данных: Заполнение форм тысячами разных значений. * Сложные вычисления: Проверка математических формул в финансовом ПО. * Нагрузочное тестирование: Проверка производительности.

❌ Что НЕ нужно автоматизировать:

* UX/UI (Usability): Скрипт не может оценить, красиво ли выглядит кнопка и удобно ли ей пользоваться. * Одноразовые проверки: Если тест нужно прогнать всего один раз, быстрее сделать это руками. * Нестабильный функционал: Если код меняется каждый день, вы замучаетесь переписывать автотесты. * Тесты, требующие физического взаимодействия: Например, проверка работы сканера отпечатков пальцев (хотя и здесь есть эмуляторы).

Пирамида автоматизации

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

!Пирамида автоматизации показывает, что дешевых и быстрых Unit-тестов должно быть больше всего, а дорогих UI-тестов — меньше всего.

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

Integration/API Tests: Середина пирамиды. Проверяют взаимодействие модулей без запуска браузера. Они быстрые и стабильные. Их должно быть ~20%.

UI / E2E Tests: Верхушка. Имитация действий пользователя в браузере. Они медленные, часто падают из-за верстки и сложны в поддержке. Их должно быть ~10%.

> Антипаттерн «Рожок мороженого»: Когда команда пишет тысячи UI-тестов и почти не пишет Unit-тесты. Это приводит к тому, что прогон тестов занимает 10 часов, и релизы задерживаются.

Обзор популярных инструментов

Мир инструментов для QA огромен. Выбор зависит от языка программирования (Java, Python, JS) и типа тестирования. Рассмотрим лидеров рынка.

1. Web UI (Тестирование интерфейса в браузере)

* Selenium WebDriver: «Дедушка» автоматизации. Самый популярный инструмент, поддерживающий почти все языки (Java, Python, C#, etc.). Это библиотека, которая позволяет коду управлять браузером. Плюсы:* Огромное сообщество, поддержка всех браузеров. Минусы:* Требует настройки, медленнее современных аналогов.

* Playwright: Современный инструмент от Microsoft. Быстро набирает популярность. Плюсы:* Очень быстрый, умеет ждать элементы (нет проблем с тайм-аутами), работает «из коробки». Минусы:* Молодое сообщество.

* Cypress: Популярен в мире JavaScript. Плюсы:* Прост для фронтенд-разработчиков, удобный дебаггинг. Минусы:* Ограниченная поддержка языков (только JS/TS), сложности с работой в нескольких вкладках.

2. API Testing (Тестирование бэкенда)

* Postman: Изначально инструмент для ручного тестирования API, но позволяет писать скрипты на JS и запускать их автоматически (через Newman). Идеально для:* Новичков и быстрого старта.

* REST Assured: Библиотека для Java. Стандарт де-факто в Java-автоматизации API. Идеально для:* Серьезных Enterprise-проектов.

* Requests (Python): Простая и мощная библиотека для отправки HTTP-запросов в Python.

3. Mobile Testing (Мобильные приложения)

* Appium: Самый популярный инструмент для мобильной автоматизации. Работает и с iOS, и с Android. Особенность:* Использует протокол Selenium, поэтому тем, кто знает Selenium, легко перейти на Appium.

4. Load Testing (Нагрузочное тестирование)

* Apache JMeter: Классика нагрузочного тестирования. Имеет графический интерфейс, не требует глубокого знания кода. * K6: Современный инструмент, где сценарии нагрузки пишутся на JavaScript. Любим разработчиками.

Как стать автоматизатором?

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

Изучите язык программирования. Python или Java — лучшие варианты для старта. JavaScript — если хотите работать с Cypress/Playwright.

Освойте основы Git. Вы будете работать с кодом, поэтому системы контроля версий обязательны.

Начните с API. Автоматизировать API проще и стабильнее, чем UI.

Изучите паттерн Page Object. Это стандарт проектирования автотестов для UI, который помогает держать код в чистоте.

Заключение

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

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