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

Введение в тестирование: основные понятия, цели, QA vs QC и семь принципов тестирования

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

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

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

Многие новички представляют работу тестировщика так: сидит человек, хаотично нажимает на клавиши и ждет, пока программа сломается. Это миф.

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

Проще говоря, тестирование — это сравнение того, что есть, с тем, что должно быть.

Откуда мы знаем, «как должно быть»?

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

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

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

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

Вот главные цели тестирования:

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

Предотвращение дефектов. Да, тестировщики могут предотвращать ошибки! Если тестировщик проверит требования еще до начала написания кода и найдет там логическое противоречие, баг в коде даже не родится.

Предоставление информации. Тестирование дает бизнесу информацию о качестве продукта. Можно ли выпускать релиз? Какие риски существуют? Работает ли основной функционал?

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

> Тестирование может показать наличие дефектов, но не может доказать их отсутствие. > — Эдсгер Дейкстра, ученый в области компьютерных наук

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

В вакансиях вы часто можете встретить термины QA Engineer (Quality Assurance) и QC (Quality Control), которые используют как синонимы слова «тестировщик». Но с точки зрения теории это разные понятия, вложенные друг в друга.

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

Разберем эту иерархию подробнее:

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

Это непосредственно процесс проверки продукта. * Что делаем: Пишем тест-кейсы, запускаем программу, ищем баги, документируем ошибки. * Фокус: На продукте и поиске ошибок.

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

Это набор действий, предназначенных для оценки качества продукта. Тестирование является частью QC. * Что делаем: Помимо самого тестирования, сюда входят анализ результатов тестирования, ревью кода, проверка готовности к релизу. * Фокус: На выявлении брака в готовом (или почти готовом) продукте.

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

Это совокупность активностей, направленных на обеспечение уверенности в том, что требования к качеству будут выполнены. Это управление процессами. * Что делаем: Выстраиваем процессы так, чтобы ошибки не появлялись. Обучение сотрудников, выбор инструментов, улучшение методологии разработки, анализ причин возникновения дефектов. * Фокус: На процессе и предотвращении брака.

Аналогия с заводом автомобилей: * Тестирование: Рабочий проверяет, закрывается ли дверь у конкретной машины. * QC: Мастер проверяет партию машин и отбраковывает те, у которых двери не закрываются. * QA: Инженер анализирует, почему двери вообще выходят кривыми, и меняет настройки конвейера или поставщика металла, чтобы все будущие машины были качественными.

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

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

Принцип 1: Тестирование демонстрирует наличие дефектов

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

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

Проверить все возможные комбинации входных данных и сценариев невозможно (за исключением тривиальных случаев).

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

Принцип 3: Раннее тестирование

Чем раньше мы начнем тестировать, тем дешевле будет исправление ошибок.

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

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

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

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

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

Аналогия: Если травить насекомых одним и тем же ядом (пестицидом), у них вырабатывается иммунитет. Решение: Тесты нужно регулярно пересматривать, обновлять и дополнять новыми сценариями.

Принцип 6: Тестирование зависит от контекста

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

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

Принцип 7: Заблуждение об отсутствии ошибок

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

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

Заключение

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

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

Жизненный цикл разработки ПО (SDLC) и пирамида уровни тестирования

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

Многие думают, что разработка выглядит так: придумали идею -> написали код -> отдали пользователю. Но в реальности это сложный инженерный процесс, разбитый на этапы. Этот процесс называется SDLC.

Что такое SDLC?

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

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

Основные этапы SDLC

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

!Круговая диаграмма, иллюстрирующая 6 основных этапов жизненного цикла разработки ПО.

Разберем каждый этап подробнее:

Сбор и анализ требований (Requirements Analysis).

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

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

Архитекторы и дизайнеры решают, как это будет работать и выглядеть. Создаются макеты интерфейса, схемы баз данных, выбираются технологии. Тестировщики могут тестировать макеты дизайна.

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

Самый очевидный этап. Программисты пишут код, превращая документацию и макеты в работающую программу.

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

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

Развертывание и внедрение (Deployment).

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

Поддержка (Maintenance).

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

Модели разработки: Водопад vs Гибкость

В зависимости от того, как команда переходит между этими этапами, выделяют разные модели SDLC. Самые известные из них — это Waterfall (Каскадная модель) и Agile (Гибкая методология).

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

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

* Плюсы: Четкость, понятные сроки, подробная документация. * Минусы: Если на этапе тестирования выяснится, что идея была плохой, переделывать придется всё с самого начала. Это очень дорого и долго.

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

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

* Плюсы: Быстрая обратная связь, возможность менять требования на ходу. * Минусы: Требует высокой дисциплины и постоянного общения в команде.

Уровни тестирования и Пирамида Майка Кона

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

Для визуализации правильной стратегии тестирования используют концепцию Пирамиды тестирования, популяризированную Майком Коном.

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

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

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

Это фундамент пирамиды.

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

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

Средний слой пирамиды.

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

3. Системное / E2E тестирование (System / End-to-End Testing)

Верхушка пирамиды.

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

Почему пирамида выглядит именно так?

Главная идея пирамиды — экономическая эффективность.

Если мы будем искать все баги только через UI (верхушка), мы узнаем о проблеме слишком поздно, а проверка займет часы.

Если баг найден юнит-тестом (основание), разработчик узнает о нем через секунду после написания кода и сразу исправит.

Поэтому хорошая стратегия автоматизации выглядит так: * 70% — Юнит-тесты (быстро, дешево, надежно). * 20% — Интеграционные тесты (проверка связей). * 10% — UI/E2E тесты (проверка критических сценариев пользователя).

Анти-паттерн: Рожок мороженого (Ice Cream Cone)

К сожалению, во многих проектах пирамида перевернута. Это называется «Рожок мороженого».

Это происходит, когда: * Разработчики не пишут юнит-тесты. * Вся нагрузка по поиску ошибок ложится на ручных тестировщиков и UI-автотесты.

Результат: Тестирование занимает вечность, релизы задерживаются, а стоимость поддержки тестов становится космической. Если вы попали на такой проект, ваша задача как QA — постепенно убеждать команду внедрять тесты на более низких уровнях.

Заключение

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

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

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

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

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

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

Зачем нужна классификация?

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

В тестировании так же. Мы не можем просто «протестировать программу». Мы должны понимать:

Проверяем ли мы функции или удобство?

Имеем ли мы доступ к коду или смотрим снаружи?

Проверяем новую фичу или старую?

Глобально все виды тестирования можно разделить по нескольким признакам. Самое важное деление — по объекту тестирования (что проверяем) и по знанию системы (как проверяем).

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

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

Это самый распространенный вид тестирования. Он отвечает на вопрос: «Что делает система?».

Мы проверяем, выполняет ли программа свои функции согласно требованиям. Если в документации сказано, что кнопка «Купить» должна добавлять товар в корзину, мы нажимаем её и проверяем корзину. Если товар там — тест пройден.

Примеры функциональных тестов: * Авторизация пользователя. * Расчет стоимости доставки. * Отправка сообщения в чате. * Создание отчета.

Внутри функционального тестирования часто выделяют подвид — Дымовое тестирование (Smoke Testing). Это короткий цикл тестов, подтверждающий, что приложение вообще запускается и выполняет основные функции. Если «дым идет» (программа падает при запуске), то глубокое тестирование проводить нет смысла.

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

Если функциональное тестирование проверяет что система делает, то нефункциональное проверяет как она это делает.

Представьте автомобиль. * Функциональное требование: машина должна ехать. * Нефункциональное требование: машина должна разгоняться до 100 км/ч за 5 секунд, быть безопасной и удобной.

Нефункциональное тестирование описывает характеристики системы.

Основные виды нефункционального тестирования:

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

* Нагрузочное (Load): Как ведет себя система при ожидаемой нагрузке (например, 1000 пользователей одновременно). * Стрессовое (Stress): Что будет, если нагрузку увеличить в 10 раз? Как система упадет и сохранятся ли данные? * Стабильности (Stability): Как работает система при средней нагрузке, но в течение длительного времени (например, 24 часа).

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

Насколько пользователю удобно и понятно работать с программой. Легко ли найти кнопку «Выход»? Читаем ли текст? Не слишком ли много кликов нужно для простой операции?

Тестирование безопасности (Security Testing):

Проверка уязвимостей системы. Можно ли войти без пароля? Защищены ли данные банковских карт? Устойчив ли сайт к хакерским атакам?

Тестирование совместимости (Compatibility Testing):

Работает ли сайт в Chrome, Safari и Firefox? Корректно ли отображается приложение на iPhone и Android?

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

3. Классификация по доступу к коду (Методы ящиков)

Вторая важнейшая классификация отвечает на вопрос: «Видим ли мы внутреннее устройство программы?».

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

Метод черного ящика (Black Box)

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

* Как работает: Подаем данные на вход -> Смотрим результат на выходе. * Пример: Вы тестируете калькулятор. Вы вводите 2 + 2 и ждете 4. Вам неважно, как именно процессор складывает биты, вам важен результат. * Кто использует: Большинство ручных тестировщиков (Manual QA).

Метод белого ящика (White Box)

Мы видим код, структуру базы данных и алгоритмы. Мы тестируем внутреннюю логику.

* Как работает: Анализируем код, выбираем пути выполнения, проверяем условия if/else. * Пример: Вы видите в коде условие: if (age < 18) return error. Вы специально пишете тест, который передает возраст 17, чтобы проверить именно эту строчку кода. * Кто использует: Разработчики (Unit-тесты) и SDET (автоматизаторы).

Метод серого ящика (Grey Box)

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

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

4. Связанное с изменениями: Регресс и Re-test

Это, пожалуй, самый частый вопрос на собеседованиях: «В чем разница между регрессионным тестированием и повторным (re-testing)?».

Когда разработчик исправляет баг, код меняется. Любое изменение несет риски.

Повторное тестирование (Re-testing)

Это проверка того, что конкретный дефект был исправлен.

* Ситуация: Вы нашли баг «Не работает кнопка Вход». Разработчик сказал «Исправил». * Действие: Вы идете и нажимаете кнопку «Вход». Если работает — тест пройден.

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

Это проверка того, что исправление бага не сломало ничего другого в системе.

* Ситуация: Разработчик чинил кнопку «Вход» и случайно задел код регистрации. * Действие: После проверки кнопки «Вход» (Re-test), вы проверяете регистрацию, восстановление пароля и другие связанные функции, чтобы убедиться, что старый функционал все еще работает.

> Золотое правило: Сначала Re-test (проверяем фикс), потом Regression (проверяем, что не сломали остальное).

Заключение

Сегодня мы разобрали основные виды классификации тестирования. Давайте закрепим:

Функциональное — проверяет бизнес-логику (что делает?).

Нефункциональное — проверяет атрибуты качества (как работает? быстро? удобно? безопасно?).

Черный ящик — тестируем без знания кода.

Белый ящик — тестируем с знанием кода.

Re-test — проверка исправления бага.

Регресс — проверка отсутствия новых багов в старом функционале.

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

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

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

Сегодня мы переходим к самой «мякоти» профессии — тест-дизайну.

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

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

Мы разберем три самые популярные техники «черного ящика», которые вы будете использовать каждый день: Классы эквивалентности, Граничные значения и Попарное тестирование.

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

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

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

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

Представьте, что вы тестируете систему покупки авиабилетов. Правила тарифа гласят: * Детям до 2 лет — бесплатно. * Детям от 2 до 12 лет — скидка 50%. * Взрослым от 12 лет — полная стоимость.

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

Класс 1 (Младенцы): от 0 до 2 лет.

Класс 2 (Дети): от 2 до 12 лет.

Класс 3 (Взрослые): от 12 лет и старше.

Негативные классы (Невалидные данные): отрицательный возраст (например, -5) или нереалистично большой (например, 200).

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

Чтобы протестировать систему, нам достаточно взять по одному значению из каждого класса. Например: * 1 год (представитель класса младенцев). * 7 лет (представитель класса детей). * 25 лет (представитель класса взрослых). * -1 (негативный тест).

Если система правильно сработала для 7 лет, мы предполагаем, что она так же правильно сработает и для 5, и для 9 лет, так как логика кода для них одна.

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

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

Почему? Потому что в коде используются операторы сравнения: > (больше), < (меньше), >= (больше или равно), <= (меньше или равно). Очень легко перепутать > и >=.

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

Как выбирать границы?

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

Само граничное значение.

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

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

Вернемся к нашему примеру с авиабилетами. Границы диапазонов там: 2 года и 12 лет.

Проверка границы 2 года: * 1 год и 364 дня (почти 2) — должно быть бесплатно. * 2 года ровно — тут вопрос к требованиям. Обычно «до 2 лет» означает, что в день рождения уже платно, или наоборот. Это самое критичное место для бага! * 2 года и 1 день — должна быть скидка 50%.

Если мы работаем с целыми числами, то для границы мы проверяем:

где — это граничное значение, — значение на шаг меньше границы, — значение на шаг больше границы.

> Ошибки на границах встречаются так часто, что существует профессиональная шутка: «Тестировщик заходит в бар. Заказывает 0 кружек пива, 999999999 кружек пива, -1 кружку пива, ящерицу и одну кружку пива».

Совмещение техник: Обычно эти две техники используют вместе. Сначала вы разбиваете данные на классы, а потом берете тесты не из середины класса (как 7 лет), а ближе к его краям (2 и 12 лет).

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

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

Представьте, что вы тестируете интернет-магазин одежды. У товара есть параметры:

Цвет: Красный, Синий, Зеленый, Черный (4 варианта).

Размер: S, M, L, XL, XXL (5 вариантов).

Материал: Хлопок, Шерсть, Синтетика (3 варианта).

Доставка: Курьер, Почта, Самовывоз (3 варианта).

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

где — общее количество тестов, — количество цветов (4), — количество размеров (5), — количество материалов (3), — количество способов доставки (3).

Считаем:

180 тестов для одной футболки! А если параметров будет 10? Количество тестов уйдет за миллион. Это называется комбинаторный взрыв.

Решение проблемы

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

Например, «Синий цвет» может конфликтовать с «Материалом Шерсть» (краска не ложится), но ему все равно, какой там размер или способ доставки.

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

Вместо проверки всех сочетаний (All Combinations), мы проверяем все пары. Это позволяет сократить количество тестов в разы, сохраняя высокую эффективность.

Для нашего примера с футболками использование Pairwise сократит количество тестов со 180 до примерно 20-25 кейсов.

!Визуальное сравнение объема работы при полном переборе и попарном тестировании.

Инструменты для Pairwise

Вручную составлять такие таблицы очень сложно. Тестировщики используют специальные генераторы: * PICT (от Microsoft) * AllPairs * Онлайн-генераторы (например, pairwise.org)

Вы просто вводите параметры, а программа выдает вам готовую таблицу с минимально необходимым набором тестов.

Резюме

Сегодня мы вооружились тремя мощными инструментами:

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

Граничные значения указывают нам на самые опасные места в логике программы (стыки диапазонов).

Попарное тестирование спасает нас от комбинаторного взрыва, когда параметров слишком много.

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

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

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

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

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

Сегодня мы поговорим о «бюрократии», которая спасает проекты от хаоса: о тестовой документации и жизненном пути бага.

Уровни тестовой документации

В тестировании существует иерархия документов. Мы не будем углубляться в глобальные стратегии (Test Strategy) и планы (Test Plan), которые пишут лиды и менеджеры. Мы сосредоточимся на том, с чем QA-инженер работает ежедневно:

Чек-листы (Checklists)

Тест-кейсы (Test Cases)

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

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

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

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

Пример чек-листа для формы логина:

* Ввод валидного логина и пароля. * Ввод неверного пароля. * Ввод незарегистрированного email. * Восстановление пароля. * Кнопка «Запомнить меня».

Плюсы: * Быстро создавать и поддерживать. * Легко читать.

Минусы: * Требует знания продукта (новичок может не понять, как именно проверить пункт). * Результаты тестирования могут быть неоднозначными (разные тестировщики могут проверить один пункт по-разному).

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

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

Если чек-лист — это список покупок, то тест-кейс — это подробный кулинарный рецепт. В нем расписано каждое действие.

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

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

Основные атрибуты тест-кейса:

ID: Уникальный номер (например, TC-001).

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

Плохо:* Проверка кнопки. Хорошо:* Авторизация пользователя с валидными данными.

Предварительные условия (Preconditions): Что должно быть сделано до начала теста. Например: «Пользователь зарегистрирован», «Открыта страница входа».

Шаги (Steps): Последовательность действий.

Ожидаемый результат (Expected Result): Самое важное поле. Что должно произойти после выполнения шагов.

Постусловия (Postconditions): Как вернуть систему в исходное состояние (например, «Удалить созданного пользователя»).

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

| Атрибут | Значение | | :--- | :--- | | ID | AUTH-001 | | Заголовок | Успешная авторизация существующего пользователя | | Preconditions | Пользователь user@test.com с паролем 12345 существует. Открыта страница /login. | | Steps | 1. Ввести user@test.com в поле Email.<br>2. Ввести 12345 в поле Password.<br>3. Нажать кнопку «Войти». | | Expected Result | Произошел редирект в Личный кабинет. В правом верхнем углу отображается имя пользователя. |

> Важно: Ожидаемый результат должен быть однозначным. Не пишите «Система работает правильно». Пишите «Появилось сообщение 'Успешно' зеленого цвета».

Что выбрать: Чек-лист или Тест-кейс?

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

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

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

Цель баг-репорта — показать разработчику проблему так, чтобы он смог её воспроизвести и исправить.

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

Summary (Тема): Краткое описание проблемы. Отвечает на вопросы: Что? Где? Когда?

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

Description (Описание): Более детальная информация, окружение (браузер, версия ОС).

Steps to Reproduce (Шаги воспроизведения): Самая важная часть. Инструкция, как «сломать» программу.

Actual Result (Фактический результат): Что произошло на самом деле (например, «Система зависла»).

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

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

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

Severity vs Priority: вечная путаница

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

Severity (Серьезность) — это техническая характеристика дефекта. Насколько сильно он влияет на работу системы. * Blocker: Блокирует дальнейшую работу/тестирование (сайт не открывается). * Critical: Не работает важная бизнес-функция (не проходит оплата), обходного пути нет. * Major: Функция не работает, но есть обходной путь (workaround). * Minor: Незначительное нарушение логики (не работает сортировка в редком сценарии). * Trivial: Визуальные ошибки, опечатки.

Priority (Приоритет) — это менеджерская характеристика. Как быстро нужно исправить баг. * High (Высокий): Исправить немедленно. * Medium (Средний): Исправить в плановом порядке. * Low (Низкий): Исправить, когда будет время.

#### Примеры сочетаний:

High Severity / High Priority: Упал сервер базы данных. Никто не может работать. Чиним срочно.

Low Severity / High Priority: Опечатка в названии компании на главной странице («Goggle» вместо «Google»). Технически сайт работает идеально (Low Severity), но для репутации это катастрофа, нужно править прямо сейчас (High Priority).

High Severity / Low Priority: Приложение падает, если нажать 10 кнопок одновременно на старом телефоне 2010 года выпуска. Технически это краш (High Severity), но пользователей с такими телефонами почти нет, поэтому чинить будем в последнюю очередь (Low Priority).

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

Баг не просто создается и исчезает. Он проходит определенный путь (workflow). Понимание этого пути критически важно для взаимодействия с разработчиками.

!Диаграмма состояний дефекта от создания до закрытия.

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

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

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

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

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

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

Closed (Закрыт): Если баг действительно исчез, его закрывают.

Reopened (Переоткрыт): Если разработчик сказал «исправил», а баг все еще воспроизводится, тестировщик возвращает его в работу.

Иногда баг может получить статус Rejected (Отклонен), если разработчик считает, что это не баг, а фича (feature), или Deferred (Отложен), если баг признан некритичным для текущего релиза.

Заключение

Качественная документация — это язык общения внутри команды.

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

Помните: плохой баг-репорт («У вас тут ничего не работает») вызывает у разработчика раздражение. Хороший баг-репорт (с шагами и логами) вызывает уважение и желание помочь.

В следующей лекции мы поговорим об инструментах, в которых ведется вся эта работа (Jira, TestRail), и немного затронем тему автоматизации.