Почему принципы важны

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

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

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

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

Суть: Тестирование может доказать, что дефекты существуют, но не может доказать, что дефектов нет. Даже после прогона тысяч тестов с нулём провалов нельзя утверждать, что ПО свободно от дефектов.

Почему это важно: Заинтересованные стороны часто спрашивают: «Это без багов?» Честный ответ всегда: «Нет, но мы не нашли багов в протестированных условиях.» Это различие не педантизм — оно устанавливает правильные ожидания от тестирования.

Реальный пример: Миссия NASA Mars Pathfinder (1997) прошла все наземные тесты успешно. Однако на Марсе баг инверсии приоритетов вызывал постоянные перезагрузки системы. Дефект существовал всё время, но не был выявлен в тестовых условиях на Земле.

Практический вывод: При отчётности говорите «дефекты не обнаружены», а не «ПО свободно от дефектов».

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

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

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

Математика: Рассмотрим форму с 3 выпадающими списками по 10 вариантов в каждом. Это 10 x 10 x 10 = 1,000 комбинаций. Добавьте текстовое поле на 100 символов из набора в 96 символов — получите 96^100 дополнительных комбинаций. Протестировать их все физически невозможно.

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

Принцип 3: Раннее тестирование экономит время и деньги

Суть: Активности тестирования должны начинаться как можно раньше в SDLC. Это включает ревью требований, анализ дизайна и написание тест-кейсов до написания кода.

Почему это важно: Как мы разобрали в Уроке 1.2, стоимость исправления дефекта растёт экспоненциально с каждой фазой SDLC. Дефект требований, пойманный при ревью, стоит 1x. Тот же дефект в продакшене — 100x.

Shift-left тестирование: Этот современный термин описывает практику смещения активностей тестирования на более ранние этапы. Вместо тестирования только после написания кода shift-left означает:

  • Ревью требований на тестируемость
  • Написание тест-кейсов на этапе проектирования
  • Написание unit-тестов вместе с кодом (TDD)
  • Запуск статического анализа до code review
graph LR subgraph Традиционно direction LR R1[Требования] --> D1[Дизайн] --> C1[Код] --> T1[Тест ✓] end subgraph Shift-Left direction LR R2[Требования ✓] --> D2[Дизайн ✓] --> C2[Код ✓] --> T2[Тест ✓] end

Практический вывод: Начинайте писать тест-кейсы в момент получения требований. Не ждите билда для тестирования.

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

Суть: Небольшое число модулей обычно содержит большинство дефектов. Это следует принципу Парето (правило 80/20): примерно 80% дефектов находят в 20% модулей.

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

Почему дефекты кластеризуются:

  • Сложность: Сложные модули имеют больше потенциальных точек отказа
  • Частота изменений: Часто модифицируемый код более подвержен регрессиям
  • Опыт разработчика: Модули, написанные менее опытными разработчиками, могут содержать больше дефектов
  • Сильная связанность: Модули с большим количеством зависимостей сложнее реализовать корректно
  • Нечёткие спецификации: Расплывчато определённые функции ведут к недопониманию

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

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

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

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

Как противостоять парадоксу пестицида:

  • Регулярно пересматривать и обновлять тест-кейсы
  • Добавлять новые тесты для каждого бага, найденного в продакшене
  • Использовать исследовательское тестирование для обнаружения непокрытых областей
  • Ротировать тестировщиков между функциями для свежего взгляда
  • Дополнять регрессионное тестирование рандомизированными тестами и тестами на основе свойств

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

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

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

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

Факторы контекста:

  • Отрасль: Здравоохранение, финансы и авиация требуют более строгого тестирования, чем развлекательные приложения
  • Уровень риска: Системы, критичные для жизни, требуют более тщательного тестирования, чем внутренние инструменты
  • Методология разработки: Agile-тестирование отличается от тестирования в waterfall
  • Регуляторные требования: Некоторые отрасли требуют определённых типов тестирования (FDA для медицины, PCI DSS для платежей)
  • Бюджет и сроки: Стартапы с 2-недельными спринтами не могут тестировать как enterprise-команды с 6-месячными циклами

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

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

Суть: Нахождение и исправление дефектов не поможет, если построенная система неудобна или не удовлетворяет потребности и ожидания пользователей. Продукт без дефектов, которым никто не хочет пользоваться — всё равно провал.

Почему это важно: Этот принцип напрямую связан с различием верификации и валидации из Урока 1.3. Можно идеально верифицировать продукт (ноль багов), при этом полностью провалить валидацию (неправильный продукт).

Реальный пример: Google Wave (2009) был технически впечатляющим, хорошо протестированным продуктом, объединяющим email, мгновенные сообщения и совместную работу. Багов было мало. Но пользователи сочли его запутанным и ненужным — у них уже были email и чат. Google Wave был закрыт через год, несмотря на прохождение всех проверок качества.

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

Итоговая диаграмма

graph TD P1["1. Тестирование показывает наличие
дефектов, не отсутствие"] --> Core[Семь принципов
тестирования] P2["2. Исчерпывающее тестирование
невозможно"] --> Core P3["3. Раннее тестирование
экономит время и деньги"] --> Core P4["4. Кластеризация дефектов
правило 80/20"] --> Core P5["5. Парадокс пестицида
Обновляйте тесты"] --> Core P6["6. Тестирование зависит
от контекста"] --> Core P7["7. Заблуждение об отсутствии
ошибок"] --> Core style Core fill:#3b82f6,color:#fff

Упражнение: какой принцип применяется?

Для каждого сценария определите, какой принцип ISTQB нарушается или иллюстрируется:

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

  2. QA-лид докладывает CEO: «Мы прогнали 5,000 тест-кейсов и все прошли. Гарантируем, что продукт без багов.»

  3. Финтех-стартап применяет одинаковую строгость тестирования к маркетинговому лендингу и к движку обработки платежей.

  4. После сбоя в продакшене команда обнаруживает, что 7 из последних 10 продакшен-багов пришли из сервиса уведомлений.

  5. Команда разработки пишет код 3 месяца, прежде чем QA впервые видит продукт.

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

  7. Фитнес-приложение не имеет известных багов, но пользователи жалуются, что оно отслеживает метрики, которые никому не интересны.

ПодсказкаСопоставьте каждый сценарий с одним из семи принципов. Некоторые сценарии иллюстрируют нарушение (неправильное действие), другие — проявление принципа (наблюдаемое явление).
Решение

  1. Парадокс пестицида (Принцип 5) — Прогон одних и тех же тестов 18 месяцев без обновления. Тесты устарели и больше не эффективны для нахождения новых дефектов.

  2. Тестирование показывает наличие, не отсутствие (Принцип 1) — Нарушен. Невозможно гарантировать отсутствие багов. Правильная формулировка: «Все 5,000 тест-кейсов прошли. Дефекты не обнаружены в протестированных условиях.»

  3. Тестирование зависит от контекста (Принцип 6) — Нарушен. Маркетинговый лендинг и движок обработки платежей имеют совершенно разные уровни риска и требуют разных подходов к тестированию.

  4. Кластеризация дефектов (Принцип 4) — Проиллюстрирован. Большинство дефектов сконцентрировано в небольшом числе модулей. Сервис уведомлений должен получить усиленный фокус тестирования.

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

  6. Исчерпывающее тестирование невозможно (Принцип 2) — Нарушен. Попытка протестировать каждую комбинацию нереальна. Команде следует использовать тестирование на основе рисков и комбинаторные техники.

  7. Заблуждение об отсутствии ошибок (Принцип 7) — Проиллюстрирован. Ноль багов ничего не значит, если продукт не удовлетворяет потребности пользователей. Функции необходимо валидировать по реальным ожиданиям.

Профессиональные советы

Совет 1: Запомните эти принципы для сертификации ISTQB. Если планируете сертификацию ISTQB, эти семь принципов — гарантированный материал экзамена. Но помимо экзаменов, они направляют ежедневные решения по тестированию.

Совет 2: Используйте принципы, чтобы аргументированно отвечать на неразумные запросы. Когда менеджер говорит «протестируйте всё», сошлитесь на Принцип 2. Когда кто-то говорит «не надо тестировать, пока код не готов», сошлитесь на Принцип 3. Принципы дают профессиональный авторитет, подкреплённый отраслевым консенсусом.

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

Ключевые выводы

  • Тестирование может показать наличие дефектов, но не доказать их отсутствие (Принцип 1)
  • Протестировать всё невозможно — используйте приоритизацию на основе рисков (Принцип 2)
  • Начинайте тестировать рано, чтобы ловить дефекты, когда их исправление дёшево (Принцип 3)
  • Большинство дефектов кластеризуются в нескольких модулях — фокусируйте тестирование там (Принцип 4)
  • Регулярно обновляйте тесты, иначе они перестанут находить баги (Принцип 5)
  • Адаптируйте подход к тестированию под контекст (Принцип 6)
  • Продукт без багов, которым никто не пользуется — всё равно провал (Принцип 7)