Home

Автор: Аннелиз Хербоза (Anneliese Herbosa)
Оригинал статьи
Перевод: Ольга Алифанова

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

Уроки традиционного повествования

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

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

Вот их примерный список:

• Заголовок. Ваш заголовок должен быть кратким, но емким (то есть не "Фича А сломана", а "Фича А не срабатывает при первом использовании продукта").
• Окружение. Проиллюстрируйте свою историю – посмотрите вокруг на 360 градусов. Каким браузером, устройством, версией, ОС вы пользовались, тестируя? Какие еще детали помогут нарисовать точную картину происходящего?
• Детальное описание. Нарисуйте яркую картинку, не упускайте важных фактов. Однако при этом старайтесь не включать лишних деталей, которые могут отвлечь или запутать читателя.
• Ожидания vs Реальность. После того, как читатели начнут узнавать больше, копая глубже и все больше и больше погружаясь в сюжет, они начнут делать выводы о том, что должно было произойти и том, что на самом деле произошло.
• Следите за речью. Рассказывая историю, очень важно быть последовательным в словоупотреблении, языковом стиле и терминологии. Оформляя баг-репорт, следите за выбором слов.
  • Продуктовая терминология. Это "квадратик", "кнопка", или "призыв к действию"? Знайте, в чем разница между ними, выберите что-то одно, и используйте этот термин на протяжении всего репорта. Используйте оригинальную документацию как подсказку.
  • Тон. Помните, кто ваша аудитория, и держите в уме свои цели для создания баг-репорта. Он не направлен на то, чтобы выразить ваш гнев или раздражение определенным продуктом/фичей или тем, что что-то не работает как ожидалось (да, даже если это Internet Explorer).
  • Дополнительная мультимедиа. В любой хорошей истории есть что-то интересное, приукрашивающее ее значимым и полезным образом. Примеры медиаматериалов:
    • Скриншоты. Картинка заменит тысячу слов.
    • Запись экрана. Видео заменит еще пару тысяч.
    • Логи ошибок консоли. Сообщат об ошибках JavaScript.
    • Ориентиры. Комментарии – например, похожие проблемы, с которыми вы сталкивались раньше, чтобы помочь читателю прийти к решению или хотя бы попробовать применить схожий подход.

Джеймс Бах в своей статье перечисляет распространенные ошибки, которые тестировщики делают в баг-репорта.

Принцип сбалансированности

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

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

На одном конце спектра:

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

На другом конце спектра:

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

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

• Рассказывает ли мой репорт историю целиком? Если его будет читать кто-то, кроме меня, получат ли они хорошее (полное, исчерпывающее) понимание вопроса, о котором я пытаюсь рассказать?
  • Если да, оставьте все как есть.
  • Если нет, выясните, чего не хватает, и добавьте это.
  • Так ли необходима каждая деталь в этом баг-репорте? Все в нем включено преднамеренно и играет значительную роль в рассказе истории. Держите это в уме, составляя баг-репорты.
    • Если да, оставьте все как есть.
    • Если нет, уберите лишнее.
    • Не уверены, но предчувствуете, что это может пригодиться? Сделайте заметку! Если вы не уверены, относится ли та или иная деталь к вопросу, то не повредит сообщить о ней на всякий случай, чтобы читатель тоже это знал. Он будет сам решать, использовать ли эту информацию в процессе разбирательств с багом.

Знайте вашу аудиторию

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

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

• В чем заключается проблема?
• Какие детали имеют отношение к проблеме? (вся релевантная информация или детали, которые могут относиться к вопросу и помочь в будущих расследованиях).
• Где еще это происходит? (окружения или сценарии, и будьте как можно точнее; обратное тоже может помочь – где это не происходит?)
• Каков ожидаемый результат? Иногда просто заявить о проблеме недостаточно. Чтобы ввести читателя в контекст, определение ожидаемого результата может помочь нарисовать более полную, ясную картину и помочь разработчику понять, как должно работать.

Чем больше вы понимаете о том, что нужно разработчику, тем меньше противоречивости и игры баг-репортом в футбол вы получите.

И жили они долго и счастливо… Конец.

Когда читатель доходит до конца истории, он остается наедине со своими мыслями, и ощущает себя не так, как в ее начале. Читатель может почувствовать себя растерянным и сбитым с толку, или же информированным, узнавшим что-то новое, воодушевленным. Какова мораль истории? Что читатель должен был из нее вынести? Как, с вашей точки зрения, он должен отреагировать? Эти вопросы стоит держать в голове, завершая отчет о баге. Не забывайте про принцип KISS (Keep it simple, stupid – "Делай как можно проще") – помните, что больше не значит лучше, пытаясь как можно более емко передать ваше ключевое сообщение.

Вот ряд финальных критериев, которые нужно иметь в виду, завершая баг-репорт, чтобы максимизировать его полезность:

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

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

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

• How to Report Bugs Effectively
• Rapid Software Testing Guide to Making Good Bug Reports
• You’re Not Managing a Team of Software Engineers, You’re Managing a Team of Writers
• Ministry of Testing Masterclass: Storytelling & Narratology for Software Testers
• User Stories

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