Автор: Ли Хокинс (Lee Hawkins)
Оригинал статьи
Перевод: Ольга Алифанова

Конфликт, возникающий при рассказе о проблемах исследовательского тестирования

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

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

Как с этим бороться? Повышать уровень доверия к себе!

Что такое уровень доверия, и почему это важно?

"Уровень доверия" – это качество человека или предмета, заставляющее людей верить или доверять им. Это значит, что они достойны нашего доверия. Уровень доверия имеет значение, потому что если люди вряд ли вам поверят, то ваше влияние на них снижается.

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

Один из способов повысить уровень доверия к себе как к тестировщику – это научиться применять оракулы и эвристики.

Отделяйте наблюдение от мнения при помощи оракулов и эвристик

Когда я впервые услышал про "оракулы", я работал тестировщиком примерно восемь лет – в 2007 году я посетил курс Rapid Software Testing с Майклом Болтоном. До этого я не особенно задумывался, как именно я нахожу проблемы в тестируемых продуктах. Когда меня спросили, как я обнаруживаю потенциальные проблемы, я часто говорил, что делаю это "на основании своего опыта работы с продуктом" или "сравнивая продукт со спецификацией".

Оракул – это способ распознавания проблемы.

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

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

Эвристика – это способ, помогающий мне найти новые тест-идеи.

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

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

Возвращаясь к примеру с использованием юзер-стори в качестве оракула: несоответствие между продуктом и юзер-стори может и не быть проблемой продукта – возможно, стори устарела, или же изменения в продукт были внесены специально, так как эта функциональность стала предпочтительной.

Вы, скорее всего, обзаведетесь своим инструментарием эвристик, когда хорошо с ними познакомитесь и осознаете их возможности. К примеру, я часто пользуюсь эвристикой соответствия, ожидая, что все элементы продукта будут соответствовать сравнимым элементам в том же самом продукте – это один из подходов Майкла Болтона в эвристике FEW HICCUPPS.

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

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

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

"Комментарии при клике на поле должны переходить в режим редактирования".

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

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

"Переход в режим редактирования в поле комментария не соответствует полям описания и задачи в карточке".

Вы все еще свободны высказать личное мнение, но явно сообщите о том, что это именно личное мнение:

"Мне очень нравится удобство перехода в режим редактирования описания и задачи через простой клик, и меня смущает, что поле комментария работает иначе".

Мы должны свободно делиться идеями и обратной связью, но надо четко разделять наблюдения и личное мнение.

Попробуйте вот что

Теперь вы знаете, как использование оракулов и эвристик может повысить уровень доверия к вам. Ниже – ряд советов по применению этого знания на практике:

1. Попробуйте использовать эвристику соответствия продукта самому себе (согласно примеру для Trello, который я привел выше) в ходе тестирования продукта, пытаясь выявить потенциальные проблемы. Не забудьте сообщить о найденных проблемах и сослаться на оракул, который вам помог.
2. Попробуйте другую эвристику для генерации различных идей для тестирования – взгляните на FEW HICCUPPS Майкла Болтона или чит-лист тест-эвристик (от Элизабет Хендриксон, Джеймса Линдси и Дейла Эмери, с дополнениями от Андреа Дженсен, Эди Стоукс, Каллума Эйкхерста-Райана, Дейва Дора, Деборы Шервуд, Марка Уинтерингэма и Саймона Томса).
3. Понаблюдайте, есть ли разница в реакции заинтересованных лиц, когда вы говорите о проблемах, апеллируя к оракулам и эвристикам и, таким образом, разделяя наблюдения и личное мнение.

Полезные ссылки

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

• Как говорить о тестировании – Джеймс Бах
• Серия статей про оракулы – Майкл Болтон
• Ожидаемый результат – статья Майкла Болтона