Привет, Хабр! Меня зовут Галина, я работаю QA-инженером в Ozon Tech. Если вы думаете, что тестировщики только ищут баги, то вы заблуждаетесь. Мы не просто охотники за дефектами (хотя баги ловить умеем), мы те, кто ежедневно выходит на поле боя против самого изощрённого противника — нашего собственного мозга.

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

Сегодня хочу рассказать, почему критическое мышление — это суперсила любого тестировщика, ссылаясь на теории классиков, таких как Майерс Г. и Кейнер К. Мы разберём, как когнитивные искажения могут мешать находить баги, что помогает развивать аналитический подход и как нестандартное мышление спасает проекты (и иногда ночной сон).

Что скрывается за словами «критическое мышление»?

Когда вы слышите «критическое мышление», что вы себе представляете: человека, который всех критикует, или, наоборот, гения, который всегда прав?

На самом деле всё гораздо интереснее...

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

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

Когнитивные искажения в тестировании: когда ваш мозг играет против вас

Работа тестировщика требует концентрации, внимания к деталям и... способности не попасть в ловушку собственного мышления.

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

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

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

1. Эффект авторитета: «Если документация сказала, что всё работает, значит, так и есть»

Кейнер отмечает, что чрезмерная зависимость от авторитетных источников может снизить качество тестирования, если тестировщик, полагаясь на ошибочные допущения или документацию, упускает критические ошибки. Эта мысль перекликается с идеей Майерса из книги «Искусство тестирования программ»: независимое тестирование требует, чтобы специалист не доверял слепо разработчику или документации, а проверял систему по формальным критериям. Такой подход минимизирует риск пропустить дефекты из-за слепого следования «авторитетному» мнению.

Цитаты из книги Кейнера:

«Если вы ждёте, что получите требования на куске пергамента, скреплённого печатью абсолютной истины, то найдите другую работу.
<…>
Тестировщик, который использует проектную документацию (спецификации продукта) в качестве единственного источника требований, вредит процессу тестирования».

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

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

Мораль. Всегда проверяйте факты. Документация — не истина в последней инстанции, а просто ещё один источник ошибок. Проверка реальности — ключевая составляющая критического мышления.

2. Предвзятость подтверждения: «Я ищу только то, что хочу найти»

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

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

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

Мораль. Тестируя систему, не забывайте смотреть шире. Один баг часто тянет за собой «друзей», а интеграции любят ломаться там, где меньше всего ждёшь.

3. Слепота к изменениям: «А здесь точно что-то поменялось?»

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

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

Например, на главной странице в левом верхнем углу всегда была возможность выбора адреса доставки. Но в какой-то момент из-за ошибки она пропала. Если в рамках тестирования вам не нужно менять адрес, вы просто не обратите внимания на это изменение. А вот пользователи увидят сразу и устроят штурм службы поддержки: «Где кнопка?! Верните обратно, нам срочно надо!»

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

Инструменты и практики: как тренировать критическое мышление и не сойти с ума

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

1. Метод «Почему»

Цитата из книги Кейнера:

«Любой вопрос, который приходит вам в голову, может подтолкнуть ваши собственные мысли в нужном направлении, что приведёт к важным открытиям».

Если бы дети писали тест-кейсы, они бы точно преуспели в этом методе. Суть проста: задавайте вопрос «Почему?» до тех пор, пока не докопаетесь до корня проблемы. Но если корневую причину устранить невозможно (из-за ограничений полномочий, ресурсов или границ системы), важно не останавливаться, а искать решения на более доступных уровнях, где изменения возможны.

Пример:

  1. Баг: пользователь не может добавить товар в корзину.

  2. Почему? Кнопка «Добавить в корзину» не работает.

  3. Почему? Ошибка в вызове JavaScript-функции.

  4. Почему? Функция использует неверный ID товара.

  5. Почему? ID товара не совпадает с тем, что приходит из базы данных.

  6. Почему? При миграции данных произошёл сбой.

Вместо одного фикса кнопки вы помогли всей команде предотвратить новые ошибки в будущем.

Еще пара примеров для самых любознательных:
Пример 1
  1. Баг: пользователь не получает уведомление о заказе.

  2. Почему? Уведомление не отправляется.

  3. Почему? Нет записи о заказе в системе уведомлений.

  4. Почему? При оформлении заказа не сработал триггер.

  5. Почему? Поле «email» в заказе оказалось пустым.

  6. Почему? Пользователь оформлял заказ через старую версию приложения, где email не проверяется.

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

Пример 2
  1. Баг: данные о новых заказах отображаются с задержкой.

  2. Почему? Система синхронизации работает медленно.

  3. Почему? Очередь запросов к сервису обработки заказов переполнена.

  4. Почему? Этот сервис не справляется с нагрузкой.

  5. Почему? Объём запросов вырос после запуска новой рекламной кампании.

  6. Почему? Никто не учёл рост трафика при планировании ресурсов.

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

2. Mind Mapping: рисуем карту мозга

Кейнер в своей работе отмечает важность креативного и упорядоченного подхода к тестированию. Один из таких способов — Mind Mapping, или карта мозга — помогает визуализировать систему, структурировать тестовые случаи и понять связи между её компонентами. Это отличный способ быстро увидеть слабые места и потенциальные точки отказа.

Как использовать:

  1. Берём основную фичу, например «оформление заказа».

  2. Добавляем ветви: корзина, оплата, доставка, уведомления.

  3. Для каждой ветви прописываем кейсы, ограничения и возможные проблемы.

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

И да, ещё и выглядит эта карта красиво!

3. Чек-листы: чтобы мозг не забыл важное

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

Пример

Составьте список вопросов для тестирования новой фичи

  1. Как это выглядит на мобильных устройствах?

  2. Что произойдёт, если ввести некорректные данные?

  3. Что будет, если пользователь нажмёт «назад»?

  4. А если интернет пропадёт в процессе?

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

Примеры из реальной работы: как критическое мышление спасает проекты

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

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

Вот несколько реальных примеров, где такой подход помог вовремя выявить серьёзные ошибки.

Пример 1. Логика скидок и нестандартная валюта

Ситуация

Релиз новой функциональности: пользователь должен видеть скидку в корзине. Всё протестировали, багов не нашли, команда готова к запуску. Один тестировщик решил провести дополнительные проверки.

Действия тестировщика

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

Вывод

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

Пример 2. Баг с двойной оплатой 

Ситуация

Тестировщик решил проверить, что будет, если пользователь дважды нажмёт на кнопку «Оплатить». Например, интернет подтормаживает, подтверждение не приходит сразу, и пользователь жмёт повторно.

Действия тестировщика

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

Вывод

Пользователи всегда найдут способ использовать приложение не так, как вы ожидали. Задача тестировщика — предугадать такие сценарии, чтобы система оставалась стабильной.

Пример 3. «Кто ж знал, что кнопки могут исчезать»

Ситуация

На этапе тестирования тестировщик обратил внимание, что интерфейс выглядит иначе на устройствах с нестандартными настройками. 

Действия тестировщика

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

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

Вывод

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

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

Заключение. Почему критическое мышление — это ваш главный инструмент

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

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

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

Критическое мышление — это суперсила

  1. Оно помогает увидеть то, что другие пропускают.

  2. Оно учит не принимать всё на веру, а проверять факты.

  3. Оно делает вас не просто исполнителем, а экспертом, который понимает, как работает система и как её улучшить.

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

Тестировщик с мышлением — это не просто часть команды. Это тот, кто меняет ход проекта. Иногда незаметно, иногда решающе.

А значит, каждый ваш вопрос приближает продукт к лучшему. И делает вас экспертом, к которому прислушиваются.

Комментарии (4)


  1. MAXH0
    10.07.2025 13:31

    На самом деле - НЕТ!. Это не суперсила. Эта базовая человеческая функция, которая есть у всех. В отличии, например, от абсолютного слуха или савант-синдрома.

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


    1. Ch_wolf Автор
      10.07.2025 13:31

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


  1. LLeonov
    10.07.2025 13:31

    Все так. Интересно, что и в быту всё также - видишь опечатки на сайтах, упаковках, инструкциях.. Все мелочи, которые никто другой не видит. Кроме тестировщика )


  1. Sgf46ie
    10.07.2025 13:31

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