Тестировщик и вера в Бога: баг или фича?

«Тестирование может лишь показать наличие ошибок, но не их отсутствие» — Эдсгер Дейкстра. И всё же мы каждый день нажимаем «Deploy». На каком основании?

Привет, Хабр! Меня зовут Михаил Федоров, я руковожу центром компетенций QA. В предыдущих статьях я рассказывал про QA Assist — AI-ассистента для тестирования. Сейчас идёт пилот на реальном проекте, копятся метрики и грабли — но писать об этом пока рано. Результаты будут, а пока давайте поговорим о чём-то другом.

Однажды друг в шутку спросил: «А тестировщики вообще могут верить в Бога? Это же не совместимо, нет?»

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

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

---

Оглавление

1. Определимся с терминами

2. Скептик, который вынужден доверять

3. Допущения тестирования: чему мы доверяем не проверяя

4. Почему «релизим» — это не акт веры

5. Заключение: баг или фича?

---

1. Определимся с терминами

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

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

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

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

Кажется, что тестирование и вера — два противоположных полюса:

Всё очевидно, правда? Тестировщик — человек доказательств. Вера — про отсутствие доказательств. Несовместимо. Статью можно заканчивать.

…Или нет.

---

2. Скептик, который вынужден доверять

Профессия тестировщика построена на профессиональном скептицизме. Наша работа — не верить. Буквально.

• Разработчик говорит «я проверил, работает» → мы не верим, проверяем сами

• В требованиях написано «система должна обрабатывать до 1000 запросов в секунду» → мы не верим, нагружаем

• Тест прошёл → мы не верим, проверяем, не ложноположительный ли он

• Тестовое окружение «идентично продакшену» → мы не верим (и правильно делаем)

Хороший тестировщик — это человек, который слышит «всё работает» и думает «а что если нет?». Мы по профессии — адвокаты дьявола. Наша задача — опровергать, а не подтверждать.

В этом смысле тестирование ближе всего к научному методу: выдвигаем гипотезу (система работает корректно), пытаемся её опровергнуть (тестируем), и только если не смогли опровергнуть — временно принимаем как истину. Ключевое слово — «временно». До следующего релиза.

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

Между формальным доказательством (2 + 2 = 4) и чистой верой («Бог существует») — целый спектр:

• Обоснованные суждения («мы протестировали достаточно для релиза»)

• Прагматическое доверие («стенд достаточно похож на прод»)

• Индуктивные обобщения («раньше работало — значит, будет работать»)

• Экспертные оценки («Маша-аналитик сказала, что так правильно»)

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

Давайте посмотрим, какие допущения мы делаем каждый день — и насколько далеко от «доказанного» они находятся.

---

3. Допущения тестирования: чему мы доверяем не проверяя

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

И вот именно здесь начинаются проблемы.

Допущение 1. Источник истины надёжен

Мы тестируем систему на соответствие требованиям. Но откуда мы знаем, что требования правильные? Аналитик написал, что кнопка должна быть зелёной. Мы проверяем — зелёная. Тест прошёл. Но что если она должна быть красной, а аналитик ошибся?

Для простых случаев всё очевидно. Но для сложных систем источник истины часто… отсутствует. Вы тестируете рекомендательную систему. Пользователь с историей покупок X получил рекомендацию Y. Это правильно? В требованиях написано «система должна давать релевантные рекомендации». Спасибо, это очень помогло.

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

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

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

Допущение 2. Тестовое окружение достаточно похоже на продакшен

«Тестовый стенд идентичен продакшену». Это утверждение никогда не было правдой на 100%. Данные другие. Нагрузка другая. Сеть другая. Иногда версия ОС другая.

Мы доверяем, что разница несущественна. Обычно — правильно. Иногда — нет.

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

Допущение 3. Достаточно полное покрытие существует

«Мы покрыли 95% кода тестами». Отлично. А оставшиеся 5%? А комбинации входных данных, которые мы не попробовали? А сценарии, которые мы не придумали? Исчерпывающее тестирование невозможно — это важный принцип ISTQB. «Мы протестировали достаточно» — суждение, основанное на опыте и оценке рисков, а не на доказательстве.

Допущение 4. Инструменты работают корректно

CI/CD-пайплайн честно прогнал все тесты, а не тихо пропустил половину. Playwright кликнул именно туда, куда мы указали. Сеть доставила запрос именно на тот сервер. Мы не проверяем всё это перед каждым запуском.

Пример. В другом проекте CI-агент на Jenkins периодически «подвисал» при параллельном запуске UI-тестов. Часть тестов тихо скипалась по таймауту, но финальный статус прогона показывал «passed». Мы полгода доверяли зелёной галочке, пока один из тестировщиков не заметил, что количество выполненных тестов не совпадает с количеством кейсов в сьюте. Зелёная галочка врала.

Допущение 5. Прошлый опыт применим к будущим ситуациям

«Если тест прошёл 10 раз — значит, он стабильный». «Этот тип багов обычно проявляется в граничных значениях». Мы доверяем индукции: если что-то работало N раз, оно будет работать в N+1-й раз. Но это не доказательство — это обобщение опыта.

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

---

Итого: тестирование стоит на фундаменте непроверенных допущений. Каждое из них можно (и иногда нужно) поставить под сомнение. Мы вынуждены выбирать, чему доверять, а что проверять.

---

4. Почему «релизим» — это не акт веры

Философ Карл Поппер назвал бы это так: тестировщик занимается фальсификацией — выдвигает гипотезу «система работает» и пытается её опровергнуть. Каждый баг-репорт — чёрный лебедь, разбивший гипотезу. В этом принципиальное отличие от веры: религиозное утверждение нефальсифицируемо — его нельзя опровергнуть экспериментом. А гипотезу о корректности системы — можно. И мы занимаемся этим каждый день.

Но вот в чём штука: доказать, что система сломана, мы можем — достаточно одного воспроизводимого бага. Доказать, что она работает — нет. Сколько бы тестов ни прошло, следующий может упасть. Дейкстра это знал. Мы это знаем. И всё равно в какой-то момент говорим: «Релизим».

Это не вера. Это то же самое решение, которое принимает пилот перед взлётом: все чек-листы пройдены, все системы в норме, но гарантии нет. Он не «верит», что самолёт долетит — он оценил риск и принял решение. Если завтра откажет двигатель — это не кризис веры. Это инженерный инцидент с конкретными причинами и последствиями.

Разница между профессионалом и человеком, который просто кликнул «approved» — в том, что профессионал помнит: это лучшее, что у нас есть, но не гарантия.

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

---

5. Заключение: баг или фича?

Так совместимы ли тестирование и вера?

На самом деле вопрос поставлен неправильно. Он предполагает, что тестировщик живёт в мире чистых доказательств. Как мы увидели — не живёт.

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

Впрочем, главное здесь не ответ на вопрос друга, а кое-что практичнее:

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

• Различайте источники истины. Требования в Jira трёхлетней давности — не то же, что свежая спецификация после ревью. Не все авторитеты одинаково надёжны.

• Помните, что зелёные тесты — не гарантия. Они — свидетельство в пользу качества, а не доказательство. Особенно когда менеджер спрашивает «а вы гарантируете, что багов нет?».

Тестировщик — не человек, который «не верит». Тестировщик — человек, который осознанно выбирает, чему доверять, а что проверять. И чем лучше он это осознаёт — тем лучше работает.

Вот это — фича.