Привет, Хабр. В преддверии старта курса "QA Engineer" приглашаем записаться на открытый урок на тему "Как правильно составлять баг репорт".

Также предлагаем вашему вниманию перевод короткой полезной статьи.

Меня недавно спросили, могу ли я поговорить с некоторыми из моих коллег о работе с багами. В частности, меня спросили, могу ли я объяснить, как выглядит хороший багрепорт и какую информацию он может содержать. Под прицелом оказалась команда Halaxy Service. Я восхищаюсь людьми, которые работают в службе поддержки, это работа может быть тяжелой, и когда у вас возникают трудные клиенты или ситуации, вы находитесь под изрядным давлением. Я работал на этой должности (в другой компании), временами это может быть очень сложно. При этом сотрудники Halaxy Service — нечто особенное. Их взаимопонимание с клиентами Halaxy превосходит все, что я когда-либо видел или слышал.

У меня было 10-15 минут на выступление. Не так много времени, чтобы по-настоящему вникнуть, тем более, что люди, с которыми я разговаривал, не были специалистами по тестированию. Моя цель состояла в том, чтобы передать некоторые ключевые моменты в понятных терминах, которые можно было бы извлечь и использовать. Я решил, что обсуждение разницы между сбоем (fault), ошибкой (error) и отказом (failure) не влезает в это обсуждение. Точно так же не было времени раскрывать эвристику как концепцию, но я кратко рассказал о важности согласованности. Чего мы хотели достигнуть так это того, чтобы люди из команды поддержки могли писать багрепорты достаточно детализированные, чтобы четко определить контекст и облегчить дальнейшее исследование и решение проблемы другим участникам разработки (включая всех членов команды, а не только разработчиков).

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

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

Как это произошло — на этом этапе процесса формирования багрепорта мы хотим получить представление о том, что происходило, когда результаты пошли в нежелательном направлении. Будет полезна информация о браузере (особенно если это старый браузер). Мы могли бы спросить, как они взаимодействовали с программным обеспечением, с конкретными данными или чем-то еще, что они могут вспомнить о том, что они сделали к этому моменту. Здесь много информации, которая может быть актуальной в зависимости от контекста проблемы. «Как» - это информация, которая поможет нам увидеть «что».

Что должно было произойти — полезно знать не только, в чем проблема, но и почему наш клиент считает, что это проблема. Это преследует несколько целей. Во-первых, это дает нам представление о том, чего хотят наши клиенты. Это может быть просто: «Я бы хотел, чтобы он работал так, как когда я делал то же самое два дня назад». Это также может быть обсуждение из разряда «Я хочу ”Х”, а получаю “Y”». В обоих примерах независимо от того, основана ли обратная связь клиентов на непреднамеренном ли изменении результата или на предполагаемом (наш клиент ошибается или документация клиента допускает двоякое толкование), мы понимаем, как наш клиент видит эту часть нашей системы. Это важно как для исследования и решения задач, так и для помощи в управлении ожиданиями клиентов, если позже нам понадобится объяснить, почему различия между «желаемым и фактическим» отражают то, как функциональность должна выполняться на бизнес-уровне.

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

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

Узнать подробнее о курсе "QA Engineer"

Записаться на открытый урок на тему "Как правильно составлять баг репорт".

ЗАБРАТЬ СКИДКУ