Home

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

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

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

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

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

Я дополнительно выделила важные моменты в этом определении. Тестируя, мы постоянно принимаем решения. Поэтому очень важно понимать, какие "якоря" могут повлиять на этот процесс. Чтобы было понятнее - я считаю, что тестирование – это не только непосредственная деятельность по тестированию продукта, но и размышления обо всем, имеющем отношение к качеству. Стиль мышления тестировщика применим ко всему, что касается разработки ПО: процесс, создание спецификаций, методы работы в команде, и так далее.

 Личный опыт

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

У клиентов, с которыми я работала, спринты продолжались от двух до трех недель. Те, кто работает по Scrum, знают, как это происходит: в начале спринта из пользовательских историй создается бэклог, а в конце команда удостоверяется, что выполнила всю необходимую работу. При этом в последний день спринта всю команду, а особенно тестировщиков, лихорадит, я видела это сто раз. Связано это с тем, что многие компании втихаря устраивают "Scrum-водопад" вместо Scrum. Разработка стартует вместе с началом спринта, но тестирование все еще сдвинуто в самый хвост процесса. Бизнесу нужны реализованные пользовательские истории, и тестировщиков постоянно подгоняют, и вот так длительность спринта становится якорем. От тестировщика требуется большое мужество, чтобы высказаться против такого подхода, поделиться мнением, как избежать подобных ситуаций, и не поддаться непреодолимому желанию закрыть глаза на критерии готовности историй.

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

Якорь спринта очень силен. Когда вы работаете по Scrum, вы выдрессированы думать в рамках организованных и упорядоченных спринтов, даже если реальная жизнь куда более суматошна. Здесь можно привести контраргумент: пользовательские истории не реализуются в срок (или реализуются, но плохо), так как их объем плохо оценили. Это подводит нас к разговору о следующем якоре.

Оценка пользовательских историй

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

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

Я часто сталкивалась с тем, что оценка объема пользовательских историй была чересчур занижена. "Да мы уже делали похожие штуки, и тогда они потянули на 8 баллов" - традиционный аргумент в таких ситуациях. Эти "похожие штуки" становятся якорем, и если новая задача внезапно оценена в 13 баллов, от вас потребуют объяснений. Я обычно говорю, что необходимо брать в расчет неизвестные факторы, которые могут повлиять на нас. Или (еще менее популярный аргумент) "наша история знает примеры, когда мы оценивали задачу в 8 баллов и не укладывались в спринт". К сожалению, вера в оценки высока, и убедить коллег удается редко. Я сдавалась под общим напором куда чаще, чем мне хотелось бы. Поверьте, я не прыгаю от радости с криком "А я же говорила", когда оцененная всеми в 8 баллов (а мной в 13) задача не завершена в срок. Я просто молчу. До следующего планирования. И там-то я выскажусь в ключе "А помните ту восьмибалльную историю? Да? Давайте не будем так тупить на этот раз?", и цикл повторится вновь.

Подсчет багов для измерения качества продукта

Самый дурацкий пример из моей практики на эту тему имел место несколько лет назад. Я тогда работала в крупной фирме, которая очень увлекалась планированием и построением процессов. Каждый релиз контролировался минимум 10 менеджерами, и оценке рисков уделялось пристальное внимание. Управление рисками, меж тем, основывалось на куче якорей и было не вполне здоровым. Если в релизе было не более 2 багов высокой критичности, 5-10 средней и любое количество минорных, то он считался "качественным". Собрания, посвященные отчету о дефектах, напоминали безумное чаепитие Алисы. Куча народу сидела и серьезно обсуждала списки багов, вынося вердикт "релиз ОК" на основании количества багов в нем. Время, которое мы тратили на обсуждение минорных багов, могло быть куда более успешно потрачено на их исправление. Клиническая бюрократия как она есть. Якорь тут вроде очевиден, но я повторюсь: качество вашего продукта не зависит от количества найденных багов. Принимая количество багов как якорь, вы, конечно, упрощаете понятие "качества продукта" - но при этом вы отрицаете реальность. Качество - очень сложная концепция, будьте крайне осторожны, попадаясь на якоря вроде "количество дефектов того или иного типа", и принимая решения на их основании.

Почему тестировщикам важно это понимать?

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

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

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

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