В тестировании есть несколько базовых принципов. Это не просто теория для собеседования и не сухие пункты из учебника. Это вещи, которые помогают правильно смотреть на работу тестировщика и не ждать от тестирования невозможного.
В ISTQB Foundation Level Syllabus описываются семь основных принципов тестирования:
- тестирование показывает наличие дефектов,
- исчерпывающее тестирование невозможно,
- раннее тестирование экономит время и деньги,
- дефекты склонны группироваться,
- тесты со временем теряют эффективность,
- тестирование зависит от контекста,
- отсутствие найденных дефектов ещё не означает, что продукт полезен пользователю.
Разберём их простым языком.
1. Тестирование показывает наличие дефектов, а не их отсутствие
Это один из самых важных принципов.
Когда тестировщик проверил функцию и не нашёл багов, это не значит, что багов там точно нет. Это значит только то, что в рамках выполненных проверок проблемы не обнаружились.
Представьте, что вы купили подержанную машину и проверили её перед покупкой.
Вы завели двигатель, проехали пару километров, проверили тормоза, фары, кондиционер, документы. Всё выглядит нормально.
Но можете ли вы после этого сказать: «В машине точно нет никаких проблем»?
Нет.
Вы можете сказать только:
«Я проверил основные вещи и явных проблем не увидел».
С тестированием так же.
Если мы проверили регистрацию пользователя с обычной почтой, нормальным паролем и корректным именем, это ещё не значит, что регистрация идеально работает во всех случаях.
- А если пользователь введёт имя из одного символа?
- А если email будет с плюсом?
- А если пароль будет на 200 символов?
- А если нажать кнопку регистрации два раза подряд?
- А если сервер в этот момент ответит с задержкой?
Тестирование снижает вероятность того, что серьёзная проблема уйдёт в релиз, но не даёт магической гарантии, что продукт полностью безошибочный.
Это важно понимать и новичку, и менеджеру, и заказчику.
Фраза «Мы протестировали, багов нет» звучит красиво, но в реальности правильнее говорить:
«Мы выполнили такие-то проверки, критичных проблем не нашли, риски считаем приемлемыми».
Вот это уже профессиональный подход.
2. Исчерпывающее тестирование невозможно
Исчерпывающее тестирование — это когда мы проверили вообще все возможные варианты.
В реальной жизни почти всегда это невозможно.
Допустим, у нас есть обычная форма регистрации:
имя, email, пароль, номер телефона, дата рождения.
Кажется, простая форма. Но вариантов уже огромное количество.
Имя может быть коротким, длинным, с дефисом, с пробелом, на русском, на английском, с апострофом, с цифрами, пустым.
Email может быть обычным, с точкой, с плюсом, с длинным доменом, с ошибкой, уже зарегистрированным.
Пароль может быть коротким, длинным, с пробелами, со спецсимволами, только из цифр, с кириллицей.
Телефон может быть российским, иностранным, с плюсом, без плюса, с пробелами, с лишней цифрой.
И это мы ещё не начали говорить про разные браузеры, устройства, скорость интернета, роли пользователей и состояние сервера.
Если пытаться проверить вообще всё, тестирование никогда не закончится.
Поэтому хороший тестировщик не пытается проверить бесконечность. Он выбирает важные проверки.
Он думает:
- что самое критичное?
- где выше риск ошибки?
- какие сценарии чаще всего используют реальные пользователи?
- что может привести к потере денег, данных или доверия?
- какие граничные значения стоит проверить?
Например, если доставка бесплатная от 1500 рублей, не нужно проверять все суммы от 1 до 100 000 рублей.
Достаточно проверить важные точки:
1499 рублей — доставка ещё платная;
1500 рублей — доставка уже бесплатная;
1501 рубль — доставка бесплатная.
Это и есть здравый подход: не пытаться проверить всё подряд, а выбирать проверки с умом.
3. Раннее тестирование экономит время и деньги
Многие новички думают, что тестирование начинается тогда, когда разработчик уже написал код.
На самом деле хороший QA подключается раньше.
Ещё на этапе требований можно найти кучу проблем.
Например, аналитик написал:
«Пользователь может отменить заказ».
Звучит понятно. Но QA сразу задаёт вопросы:
- до какого момента можно отменить заказ?
- можно ли отменить заказ после оплаты?
- что будет с деньгами?
- что будет с бонусами?
- можно ли отменить заказ, если его уже передали курьеру?
- получит ли уведомление администратор?
- что увидит пользователь после отмены?
Если эти вопросы задать до разработки, команда спокойно уточнит логику и сделает нормально.
Если не задать — разработчик реализует как понял. Потом тестировщик найдёт проблему. Потом задачу вернут в разработку. Потом придётся переделывать код, менять интерфейс, перепроверять, возможно, переносить релиз.
Одна неуточнённая фраза в требованиях может превратиться в несколько дней лишней работы.
Поэтому раннее тестирование — это не только про «запустить приложение и проверить». Это ещё и про ревью требований, макетов, схем, API-контрактов и логики до того, как команда потратила время на реализацию.
Чем раньше нашли проблему, тем дешевле её исправить.
4. Дефекты часто группируются
Этот принцип означает, что баги обычно распределены по продукту неравномерно.
Часто бывает так: в одной части приложения всё более-менее спокойно, а в другой баги появляются постоянно.
Например, команда делает интернет-магазин.
Каталог работает стабильно. Карточка товара работает стабильно. Поиск работает терпимо.
А вот корзина всё время ломается:
скидка считается неправильно;
товар удаляется, но сумма не обновляется;
промокод применяется два раза;
доставка пропадает после обновления страницы;
при оплате иногда создаётся два заказа.
Это сигнал для QA.
Значит, корзина — рискованная зона. Её нужно проверять глубже. Возможно, там сложная бизнес-логика, много условий, старый код, слабые требования или частые изменения.
Новичку важно понять: не все части продукта одинаково опасны.
Если времени мало, нельзя просто «равномерно потыкать всё». Нужно уделять больше внимания тем местам, где выше риск.
В реальной работе тестировщик постепенно запоминает такие зоны.
Например:
- «С оплатой у нас всегда аккуратнее».
- «После изменений в личном кабинете часто ломаются уведомления».
- «Если трогали авторизацию — обязательно проверяем восстановление пароля».
- «Если меняли доставку — проверяем промокоды и итоговую сумму».
Это уже не случайное тестирование, а работа на основе опыта и рисков.
5. Тесты со временем устаревают
Этот принцип часто называют «парадоксом пестицида».
Смысл простой: если постоянно проверять продукт одними и теми же тестами, в какой-то момент они перестают находить новые баги.
Допустим, у вас есть чек-лист для регистрации:
открыть форму;
ввести имя;
ввести email;
ввести пароль;
нажать «Зарегистрироваться»;
проверить, что пользователь создан.
Вы прогоняете этот чек-лист каждый релиз. Он полезен, но со временем команда уже привыкает к этим проверкам. Разработчики не ломают очевидные вещи, а новые баги появляются в других местах.
Например:
- при регистрации с телефона кнопка уезжает вниз;
- письмо подтверждения попадает в спам;
- при слабом интернете форма отправляется дважды;
- пользователь создаётся, но роль назначается неправильно;
- через API можно зарегистрироваться с пустым паролем.
- Старый чек-лист этого не поймает.
- Поэтому тесты нужно обновлять.
Добавлять новые сценарии. Убирать устаревшие. Менять тестовые данные. Смотреть на реальные баги из прошлых релизов. Анализировать, где пользователи чаще сталкиваются с проблемами.
Это не значит, что старые тесты бесполезны. Регрессионные проверки всё равно нужны, особенно для критичных функций.
Но нельзя годами проверять одно и то же и думать, что этого достаточно.
Продукт меняется — тесты тоже должны меняться.
6. Тестирование зависит от контекста
Не существует одного универсального способа тестировать всё.
Сайт-визитка, банковское приложение, медицинская система, игра, интернет-магазин и приложение для доставки еды тестируются по-разному.
Например, если мы тестируем лендинг для рекламной кампании, нам важны:
- отображение на разных устройствах;
- скорость загрузки;
- корректные ссылки;
- форма заявки;
- аналитика;
- визуальные баги.
Если мы тестируем банковское приложение, там уже совсем другой уровень ответственности:
- безопасность;
- деньги;
- персональные данные;
- права доступа;
- история операций;
- подтверждение действий;
- стабильность;
- логирование;
- интеграции с внешними системами.
А если мы тестируем игру, появляются свои акценты:
- производительность;
- баланс;
- графика;
- сохранения;
- сетевое взаимодействие;
- поведение персонажей;
- пользовательский опыт.
Один и тот же подход нельзя бездумно переносить везде.
Новичок может спросить:
«А как правильно тестировать?»
Ответ будет не очень удобный:
«Зависит от продукта, задачи, рисков, сроков и команды».
И это нормальный ответ.
Хороший QA не просто применяет шаблон. Он сначала понимает контекст:
- что мы тестируем?
- для кого это сделано?
- какая цена ошибки?
- какие функции критичны?
- сколько у нас времени?
- что уже известно о проблемных местах?
- какие проверки дадут максимум пользы?
И только потом выбирает подход.
7. Отсутствие найденных багов не означает, что продукт хороший
Это очень важный и часто болезненный принцип.
Можно сделать продукт, который технически работает без явных багов, но всё равно никому не нужен.
Представьте приложение для записи к врачу.
Тестировщик проверил:
- регистрация работает;
- вход работает;
- врачи отображаются;
- дата выбирается;
- запись создаётся;
- уведомление приходит.
Багов не найдено.
Но потом реальные пользователи начинают жаловаться.
Оказывается, чтобы записаться к врачу, нужно пройти 9 экранов. Поиск врача неудобный. Нельзя быстро выбрать ближайшую дату. Непонятно, где посмотреть адрес клиники. Кнопка подтверждения находится внизу, и пожилые пользователи её не замечают.
Формально функция работает.
Но пользоваться ей неудобно.
Это и есть ловушка: отсутствие багов не равно качество.
Качество — это не только «ничего не падает». Это ещё и польза для пользователя.
Продукт должен решать задачу человека.
Если пользователь не может быстро записаться к врачу, купить товар, оплатить заказ или найти нужную информацию, то продукт плохой, даже если в нём нет красных ошибок на экране.
Поэтому QA должен думать не только как проверяющий, но и как пользователь.
Не просто:
- «Соответствует ли требованиям?»
А ещё:
- «Решает ли это реальную задачу?»
- «Понятно ли человеку, что делать дальше?»
- «Не слишком ли сложно?»
- «Не потеряется ли пользователь?»
- «Не выглядит ли всё формально правильным, но неудобным?»
Вот здесь тестирование начинает пересекаться с продуктовым мышлением.
Зачем новичку знать эти принципы
На старте может казаться, что принципы тестирования — это теория для экзамена или собеседования.
Но на самом деле они помогают не впадать в крайности.
Они объясняют, почему нельзя гарантировать отсутствие всех багов.
Почему невозможно проверить абсолютно всё.
Почему QA должен подключаться раньше, а не только в конце.
Почему одни зоны продукта требуют больше внимания, чем другие.
Почему тесты нужно обновлять.
Почему подход к тестированию зависит от продукта.
И почему технически рабочая функция может всё равно быть плохой для пользователя.
Если коротко, эти принципы учат главному: тестирование — это не механическая работа по инструкции.
Это постоянное мышление о рисках, пользователях, продукте и качестве.
И чем раньше ты это поймёшь, тем быстрее ты перестанешь быть человеком, который просто «кликает по сайту», и начнёшь расти в сторону настоящего QA.