Home

Автор: Мааике Бринкхоф (Maaike Brinkhof)

Оригинал статьи: http://blog.xebia.com/mapping-biases-to-testing-confirmation-bias/

Перевод: Ольга Алифанова

Часть 1, где объясняется используемая терминология

Начну с плохих новостей: предубеждения подтверждения невозможно избежать, но это даже хорошо – если вы им страдаете, то вы живой нормальный человек. Наша "Система 1" позволяет сразу перейти к выводам, если наши предположения, скорее всего, верны, и ошибка не приведет к страшным последствиям. К примеру, встречая нового человека, вы делаете выводы о нем, основываясь на своих стереотипах, одежде, которая на нем надета, осанке, и т. п. Это происходит настолько быстро, что вы не успеваете с этим бороться.

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

Предубеждение подтверждения – это "зонтичный" термин для целого семейства когнитивных искажений: например, это гала-эффект, "то, что видишь – это все, что там есть", эвристика доступности (для полного списка см. книгу Дэвида Канемана "Думай медленно… Решай быстро"). Мы также разберемся, почему эвристики – важная часть нашей работы – напрямую связаны с предубеждением подтверждения.

Гала-эффект

Этот эффект объясняется как тенденция позитивно или негативно воспринимать абсолютно все в человеке. С моей точки зрения, к системам или новым частям системы, которые вы видите впервые, это тоже применимо. От первого впечатления тяжело избавиться. Признаюсь, что проработав некоторое время в команде, я начала заранее ожидать от определенных разработчиков определенного уровня качества. Разработчик А, очень организованный человек, гордился чистотой своего кода, подключал меня к процессу разработки и задавал вопросы. Когда наступало время для исследовательского тестирования (после того, как мы совместно написали автотесты), мне нравилось абсолютно все! Я уже была позитивно предубеждена насчет его работы.

Разработчик В был менее дисциплинирован, не писал юнит-тесты и даже не пытался запустить приложение локально перед передачей в тестирование. Не будем разбираться, насколько его подход не соответствует Agile – суть в том, что я заранее ожидала от него плохой работы. Даже тогда, когда его натренировали другие разработчики, и его подход заметно улучшился, я с большим подозрением относилась к его коду. Интересно, сколько багов я упустила, тестируя работу разработчика А, благодаря гала-эффекту.

То, что ты видишь – это все, что там есть (WYSIATI)

Это предубеждение несет пугающие последствия для тестирования. WYSIATI – это "основная функциональность системы, демонстрирующая воплощенные идеи. Информации, которую вы не можете припомнить, скорее всего, не существует". Для меня это звучит как "нельзя протестировать то, о чем даже не думаешь". Звучит логично, но зачастую тестирование презентуется именно так! Мы небрежно бросаемся фразами вроде "100% покрытие" и "полностью протестировано". Мы можем добросовестно и тщательно протестировать продукт, но это не значит, что мы изловили все-все-все ошибки. Лично для меня это большая проблема, с которой мне тяжело справляться. Мы всегда ищем баланс между потраченным временем и рисками, и нам приходится совершать "прыжок веры" в продакшн, даже осознавая, что, строго говоря, всегда есть шанс, что (возможно, ужасный) баг притаился прямо за углом.

Эвристика доступности

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

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

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

Заключение

Система 2 (по Канеману) отвечает за сомнения и недоверие, и это очень важно для тестировщиков. Если риски высоки, попытайтесь подключить Систему 2 к вашим размышлениям. Не будьте слишком строги к себе – постоянно подключать эту систему просто невозможно, и вы быстро устанете. Просто держите в уме, что вы, как живой человек, подвержены предубеждению подтверждения, сделайте шаг назад и попросите коллегу посмотреть на ситуацию свежим взглядом.

Обсудить в форуме