Психология бага. Или 7 причин, почему я его не нашёл

Тестирование завершено, чек-лист полностью охвачен, автотесты отработали, продукт выходит в продакшн и... буквально через полчаса пользователь пишет в поддержку: «Тук-тук, я у вас тут с багом столкнулся». Знакомо?

Но как такое возможно? — удивлённо спросит обыватель. Почему хороший QA-инженер, который всё проверил, мог его пропустить? Или инженер не так уж хорош? Давайте разбираться.

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

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

Сегодня я предлагаю обсудить некоторые именно психологические причины, почему баги могут остаться незамеченными, и как с этим можно бороться.

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

Также не стоит забывать, что тестировщик — не робот. Людям свойственно ошибаться и это абсолютно нормально. Другой вопрос, что мы делаем уже после того, как допустили (или пропустили) ошибку.

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

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

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

Задавайте себе провокационные вопросы вроде «What if…?»:

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

Этот феномен пришёл из когнитивной психологии: когда человек не замечает значительные изменения в его поле зрения, если эти изменения происходят постепенно или вне фокуса внимания.

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

🔥 Как бороться? Используйте сравнение «до/после», делайте наглядные скриншоты предыдущих версий, проводите тестирование «новыми глазами» — например, попросите коллег взглянуть на изменения и поделиться фидбэком. Работа в связке очень выручает.

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

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

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

Когда мы приступаем к задаче с уже сформированным «багажом знаний», мы склонны использовать одни и те же подходы. Даже если они больше неактуальны. Раньше ведь работало, правда?

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

🤚🏼 Пример. Мы проверяем мобильное приложение только в портретном режиме, потому что так делали раньше. А альбомный режим при этом ломает нам интерфейс.

Тестировщики говорили на английском, поэтому текст на французском проверялся формально. Хотя один из переводов содержал ошибку, которая меняла весь смысл: «Подтвердите ваш адрес» превратился в «Удалите ваш адрес».

🔥 Как бороться? Постоянно меняйте условия тестирования, чтобы избежать эффекта «пестицида»: языки, браузеры, устройства, геолокации, временные зоны. Не используйте одни и те же тестовые данные.

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

В тестировании это проявляется в том, что инженер больше времени уделяет проверке, что система работает правильно. Чем тому, что она может сломаться.

Обычно, мы тестируем то, что ожидаем увидеть. Если фича ведёт себя, как мы предполагаем, проще закрыть глаза на какие-то отклонения от сценария.

🤚🏼 Пример. Тестируем форму оплаты. Как положено, сначала проверяем позитивный сценарий: указали валидные данные → оплата прошла успешно.

Затем поверхностно проверяем негативные кейсы: один неверный символ в номере карты → отказ, всё ok. Но никто не проверил, что будет, если оставить поле CVV, скажем, пустым. Потому что мозг уже решил, что «всё работает корректно». А система принимала такой платёж, деньги у клиента списывались, но сама транзакция отмечалась как «failed».

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

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

Парадокс происходит, когда мы сосредоточились на чём-то важном, при этом остальные детали даже не замечаем, хотя, казалось бы, всё перед носом. Это хорошо показано в экспериментах типа «Невидимая горилла», где нужно успеть посчитать, сколько всего передач сделали игроки в белых майках 👇🏼👇🏼👇🏼

🤚🏼 Пример. Мы проверяем работу формы отправки заявки. Фокусируемся на валидации полей и на результате отправки данных на бэкенд. Между тем на странице исчезла кнопка «Назад» и появилась очепятка в заголовке. Мы этого не заметили, потому что и не искали.

🔥 Как бороться? Периодически расширяйте свой фокус внимания. Делайте общую проверку интерфейса, не ограничивайтесь только своей задачей. Используйте чек-листы, включающие общие аспекты продукта.

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

🤚🏼 Пример. Мы тестируем сложную функцию в пятницу. Уже почти 19:00, накопилась усталость за неделю, но хочется успеть всё протестировать перед заслуженными выходными. Мозг работает медленнее, и мы пропускаем важное условие проверки.

🔥 Как бороться? Ешьте слона частями: разбивайте задачи на блоки, делайте перерывы, используйте метод «Помидора»: 25 минут работы → 5 минут отдыха (в том числе от компьютера) → после 4 таких подходов делаем большой перерыв на полчаса → и всё по новой. Не стремитесь сделать всё сразу.

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

Порой баг ускользает от нас не из-за каких-либо сложностей, а из-за банального давления внутри: дедлайн, ожидания команды, наше желание «не задерживать релиз». Это особенно заметно в условиях срочности.

🤚🏼 Пример. Команда хочет выпустить фичу побыстрее → тестировщик чувствует давление → торопится → выполняет минимальный набор проверок → баг остаётся незамеченным и, как следствие, вылезает в проде.

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

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

Мы не обязаны находить все баги на свете. Однако наш долг — делать всё возможное, чтобы найти их как можно больше и как можно раньше.

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

#тестирование #qaengineer #qa #психология #опыт #vc