Это не список для зубрёжки перед экзаменом, а рабочие ограничения профессии. Каждый принцип говорит, чего тестирование не может дать - и что с этим делать на практике, а не в теории.
Разворачивай каждый: определение по ISTQB, что оно меняет в работе, разбор ситуации.
Определение. Тестирование может показать, что дефекты есть. Оно не может доказать, что их нет. Даже когда тесты гоняются раз за разом без единого падения, это снижает вероятность необнаруженных дефектов, но не обнуляет её.
Что это меняет. "Зелёный" прогон - не сертификат качества, а состояние "пока не нашли". В отчёте пиши "функциональность работает в проверенных сценариях", а не "багов нет" - это разные по смыслу утверждения.
Пример. Регресс из 400 автотестов проходит без единого фейла третий релиз подряд. Команда решает не гонять ручные проверки на новый способ оплаты - "и так всё стабильно". Через неделю приходит жалоба: при оплате российской картой в Google Pay падает подтверждение 3-D Secure. Автотесты этот сценарий просто не покрывали.
Определение. Проверить все комбинации входов, предусловий и путей выполнения нереально, кроме тривиальных случаев. Вместо перебора применяют анализ рисков и техники тест-дизайна, чтобы выбрать репрезентативный набор.
Что это меняет. Вопрос не "успею ли я проверить всё", а "какой набор из 15-20 тестов покроет максимум риска". Это ответственность тестировщика, а не оправдание нехваткой времени.
Пример. Поле "возраст" от 18 до 65 формально даёт 48 валидных значений плюс бесконечность невалидных - буквы, дробные, отрицательные, пустую строку. Проверить всё за спринт нельзя, поэтому тестируют границы 17/18/65/66 и пару типовых невалидных вводов - и это покрывает почти все реальные баги на этом поле.
Определение. Чем раньше в жизненном цикле разработки найден дефект, тем дешевле его исправить. Сюда входят и статические активности - ревью требований, дизайна и кода - которые начинаются до того, как код вообще запущен.
Что это меняет. Тестировщика зовут не "когда фича готова", а на ревью требований - до того, как её начали кодить. Найти нестыковку в формулировке за 10 минут обсуждения дешевле, чем чинить продовую логику после релиза.
Пример. На ревью требований тестировщик замечает, что не описано поведение при повторной регистрации с уже занятым email. Обсуждение занимает пять минут. Если это не заметить, а дефект дойдёт до прода, придётся чинить логику, гонять миграцию для дублей в базе и разбирать тикеты поддержки.
Определение. Небольшая часть модулей системы обычно содержит непропорционально много дефектов. В тестировании на это часто ссылаются как на принцип Парето - условно 80% багов живёт в 20% функциональности.
Что это меняет. Если ты не смотрел историю багов проекта перед тем как планировать регресс - скорее всего, тратишь время не на те модули. Проверь баг-трекер: куда чаще открывают дефекты, туда и веди exploratory-сессии и более плотный регресс.
Определение. Если гонять один и тот же набор тестов раз за разом, он постепенно перестаёт находить новые дефекты - система будто "привыкает" к тестам, как вредители привыкают к пестициду. Наборы нужно регулярно пересматривать и дополнять.
Что это меняет. Набор автотестов, который не менялся полгода, - не признак стабильности, а сигнал, что его пора обновить. Добавляй кейсы под свежие баги, убирай то, что давно не ловит ничего критичного, разбавляй регресс exploratory-заходами.
Пример. Команда полгода гоняет один и тот же smoke-набор из 30 сценариев перед каждым релизом. Он всегда зелёный. Дефекты в проде продолжают появляться - просто в местах, которые smoke не проверяет: партнёрские интеграции, редкие тарифы, локализация. Тесты не ловят новое, потому что ищут старое.
Определение. Единого правильного подхода к тестированию нет. Тестирование банковского приложения с жёсткими требованиями к безопасности и тестирование сайта-визитки по глубине, срокам и техникам не совпадают в принципе.
Что это меняет. Прежде чем копировать чек-лист с прошлого проекта, спроси: какие тут риски, кто пользователь, что случится при отказе. Для медицинского ПО важнее soak-тесты и проверка соответствия регламентам, для внутреннего инструмента - скорость и покрытие основного сценария.
Пример. Тестировщик переходит с проекта лендинга кондитерской на банковское приложение и первое время тестирует так же - парой smoke-сценариев без внимания к безопасности. Команда быстро возвращает его к процессу: обязательные проверки авторизации, лимитов и прав доступа, потому что цена отказа здесь другая.
Определение. Находка и исправление множества дефектов не спасает проект, если построенная система не отвечает реальным потребностям и ожиданиям пользователей. В ISTQB CTFL 4.0 принцип называется absence-of-defects fallacy - в версии 3.1 говорили об "absence-of-errors fallacy", смысл не поменялся.
Что это меняет. Ноль открытых багов в трекере перед релизом - не повод для радости сам по себе. Спроси себя: ты тестировал то, что нужно пользователю, или только то, что написано в тикете.
Пример. Команда выкатывает идеально стабильный редактор форм - ни одного открытого бага, все автотесты зелёные. Пользователи всё равно уходят к конкуренту, потому что редактор не поддерживает совместную работу нескольких человек одновременно - а именно это было нужно рынку. Без единого бага, но не туда.
Читаешь ситуацию, выбираешь один из семи принципов, получаешь разбор.
Регресс из 50 ручных кейсов не меняется два года. Он стабильно проходит, а в проде каждый месяц находят новые баги в местах, которые эти 50 кейсов не проверяют.
Принцип 5, парадокс пестицида. Набор, который не меняется, со временем перестаёт находить новые дефекты - систему проверяют по одним и тем же путям, а новые баги живут там, куда тесты не смотрят.
После недели тестирования без единого найденного дефекта менеджер объявляет фичу полностью безбажной и предлагает убрать её из плана тестирования на следующих спринтах.
Принцип 1, тестирование показывает дефекты, а не их отсутствие. Отсутствие найденных багов за неделю не доказывает, что фича безбажна - это снижает вероятность, но не отменяет её.
Тестировщика подключают к проекту только на этапе приёмки - за два дня до релиза, посмотреть готовую фичу целиком в первый раз.
Принцип 3, раннее тестирование экономит время и деньги. Тестировщика подключили в конце, когда исправление найденного дефекта уже дорого стоит - требования и дизайн проверить было некому.
Тимлид требует протестировать форму регистрации на "всех возможных" комбинациях email, пароля и страны, прежде чем показать статус готовности.
Принцип 2, исчерпывающее тестирование невозможно. "Все возможные" комбинации трёх полей - это уже тысячи вариантов; задача решается через классы эквивалентности и границы, а не полный перебор.
Тестировщик тратит одинаковое количество часов на модуль "О компании", который почти не менялся два года, и на модуль оплаты, где каждый релиз минимум три критичных бага.
Принцип 4, скопление дефектов. Усилия распределены поровну, хотя история багов явно показывает, где риск выше - модуль оплаты заслуживает больше внимания, чем статичная страница "О компании".
Новый тестировщик приходит в команду банковского приложения и предлагает тестировать так же, как на прошлом проекте - лендинге кондитерской: пара smoke-сценариев и всё.
Принцип 6, тестирование зависит от контекста. Подход, который годился для сайта-визитки, не годится для банковского приложения - разная цена отказа требует разной глубины проверок.
Релиз выходит без единого открытого дефекта, все автотесты зелёные - но пользователи массово уходят, потому что фича не решает их задачу.
Принцип 7, заблуждение об отсутствии дефектов. Ноль багов не спасает продукт, если он не отвечает реальным потребностям пользователей - идеальная реализация неправильной идеи всё равно провал.