Иногда, когда я просматриваю ошибки, записанные новенькими (а иногда и старенькими) тестировщиками, рука машинально тянется к лицу. В голове возникает только одна мысль:
«Что? Что я сейчас прочитала?»
В интернете много информации о том, ЧТО обязательно должно присутствовать в баг-репорте. А я решила поделиться с вами своими мыслями о том, КАК нужно писать баг-репорт, чтобы было понятно, о чём вы пишете.
В первую очередь, я писала это для инженеров по тестированию и инженеров технической поддержки, которые передают нам баги, присланные заказчиками. Также моя статья может помочь сформировать описание возникшей проблемы при обращении пользователя в техподдержку: корректное описание позволяет без дополнительных вопросов быстрее обработать инцидент.
Вообще её может быть полезно почитать всем членам команды разработки ПО, которые фиксируют своё общение в багтрекинговой системе.
Приведу пример, чтобы стало понятно, от чего моя рука летит к лицу со скоростью света:
«В контроле файлов при наличии достаточного числа файлов, имена некоторых не отображаются полностью.
Создаём любой документ УД. На вкладке Регистрация в поле Добавьте файл, правым кликом мышь, и выбираем несколько файлов. Второй вариант, перетащить несколько файлов в данное поле. В резутате, если несколько файлов, названия не помещаются полностью. Только если развернуть карточку на весь экран можно увидеть всё полностью. Строка с файлом должна переноситься на следующую строку в контроле, но этого не происходит.»
(Орфография и пунктуация сохранены).
Какой-то невероятный кусок текста, состоящий из сплошного потока сознания.
Коллеги! Вы же пишете для других людей, у которых совсем другая голова и совсем другой образ мыслей. Вы должны писать понятно!
Вот ТОП-10 правил хорошего тона, которых я придерживаюсь сама и которые рекомендую коллегам:
1) Сначала глагол.
2) Принцип «Что-Где-Когда».
3) Обезличенность.
4) Простые конструкции.
5) Без лишних слов.
6) Сократить очевидное.
7) Упростить описание сложного действия.
8) По пунктам.
9) Однозначность.
10) Перечитать.
1. Сначала глагол
Магистр Йода из «Звёздных войн» говорил так, что его было непросто понять с первого раза. Его речь строилась по принципу «объект-глагол-субъект».
«Когда и тебе 900 лет исполнится, тоже не молодо будешь выглядеть ты».
В нашей речи глагол стоит в начале (если он есть).
Пример:
Плохо – «Скопированную карточку открыть на редактирование».
Хорошо – «Открыть на редактирование скопированную карточку».
2. Принцип «Что-Где-Когда»
Этот принцип общеизвестный – сначала надо написать «что», а уже потом «в каком месте» и «при каких условиях». Лучше всего работает при составлении краткого описания ошибки.
Что происходит? – «Не создаётся карточка», «Выдаётся необработанное исключение», «Не создаётся база данных».
Где происходит? – «В виртуальной папке», «На вкладке История», «В контекстном меню».
Когда происходит? – «По нажатию кнопки», «После смены состояния карточки», «При сохранении изменений».
Пример:
Плохо – «В отчёте при добавлении файла комментария текстовый комментарий стирается».
Хорошо – «Стирается текстовый комментарий в отчёте при добавлении файла комментария».
3. Обезличенность
Описание ошибки – это не летопись ваших действий, а руководство для другого человека. Уберите себя из описания.
Пример:
Плохо – «Нажимаем кнопку», «Открываю страницу».
Хорошо – «Нажать кнопку», «Открыть страницу».
4. Простые конструкции
Сложносочинённые и сложноподчинённые предложения, причастные и деепричастные обороты осложняют восприятие текста. Чем проще будет построено предложение, тем лучше.
Пример:
Плохо – «На панели инструментов есть кнопка с шестерёнкой, открывающая меню из двух пунктов, при наведении на которую не появляется всплывающая подсказка».
Хорошо – «Навести мышку на кнопку с шестерёнкой на панели инструментов – не появилась всплывающая подсказка».
5. Без лишних слов
Когда я смотрю советские фильмы, в которых каждая вторая фраза стала крылатой, я восхищаюсь тем, как тщательно проработана речь персонажей. Ни одного лишнего словечка. Каждое слово на вес золота. Так же нужно составлять и описание ошибок – каждое слово должно что-то значить.
Привычная речь богата эпитетами, местоимениями, предлогами, которые дополнительного смысла не привносят. Если справиться с собственным мозгом очень сложно, запишите весь поток сознания как есть, а потом удалите из текста те слова, которые не несут смысловой нагрузки.
Пример:
Плохо – «По какой-то причине смена значений в поле работает довольно странно – по сути обновление поля происходит через какой-то промежуток времени».
Убрать слова «По какой-то причине», «довольно», «странно», «по сути». Они не содержат ценной информации и могут быть удалены из описания без потери смысла. Словосочетание «какой-то промежуток времени» может быть заменено на более короткий синоним.
Хорошо – «Обновление значений в поле происходит с задержкой».
6. Сократить очевидное
Некоторые действия не являются специфичными для тестируемой системы. Например, сохранение некоторого объекта, закрытие окна, вызов контекстного меню, двойной клик, запуск приложения. Эти действия обычно интуитивно понятны, поэтому при описании ошибки не стоит заострять на них внимание.
Пример:
Плохо – «Найти ярлык приложения на рабочем столе, кликнуть по нему 2 раза левой кнопкой мыши».
Хорошо – «Открыть приложение по ярлыку».
7. Упростить описание сложного действия
Допустим, в тестируемой системе есть некоторая специфичная операция. Новенькие тестировщики или разработчики, которые плохо ориентируются в интерфейсе, могут не знать, как выполнить такую операцию. Поэтому описать выполнение этой задачи можно через описание простых действий, которые помогут её выполнить.
Пример:
Плохо – «Согласовать документ», «Выполнить синхронизацию свойств».
Хорошо – «Нажать кнопку «Согласовано» на панели инструментов карточки документа», «Выбрать команду «Синхронизировать свойства» в контекстном меню объекта».
Да, это увеличивает объём описания. Зато уменьшает время воспроизведения за счёт сокращения количества вопросов типа «А как это сделать?» к автору ошибки.
Важно! То, что очевидно для вас, не всегда очевидно для другого человека.
Лично я использую 2 приёма оценки очевидности своего описания:
1) Представить, что видишь интерфейс впервые;
2) Спрогнозировать вопросы, которые могут появиться у читателя.
8. По пунктам
Хорошая практика – разбить шаги воспроизведения на пункты. Это даёт 2 главных преимущества:
1) Упрощается прохождение шагов воспроизведения.
2) Появляется возможность сослаться на некоторый пункт.
Пример:
1) Открыть справочник категорий.
2) Добавить новую категорию. Сохранить, закрыть справочник.
3) Повторить пункты 1 и 2.
Или
1) Создать карточку документа.
2) Создать карточку документа другого вида.
3) Открыть карточку, созданную на шаге 1.
Сколько действий должен содержать один пункт? Вопрос, на который все тестировщики отвечают по-разному.
Я считаю, что общее количество пунктов должно быть не более 5-6, последующие пункты уже воспринимаются сложнее, первое преимущество теряется.
Один пункт должен содержать набор действий, позволяющий достичь некоторой точки. Такой точкой может быть возникновение системного сообщения, создание некоторого артефакта в системе – всё, на чём можно приостановить воспроизведение.
9. Однозначность
Речь наша богата синонимичными словами и словосочетаниями, одни из них уместны и понятны всем, другие – не очень. Я придерживаюсь следующих трёх принципов.
Первый принцип – избегать жаргонных слов и слов с размытым смыслом.
Пример:
Плохо – «система ругается», «клацнуть в молоко», «окно уезжает за экран», «кансельнуть».
Хорошо – «выдаётся необработанное исключение», «кликнуть в пустое место окна», «окно перемещается за пределы экрана», «отменить».
Второй – использовать принятые в вашей команде слова. Второй принцип иногда может исключать первый. Например, если все поголовно в компании говорят «задизейблено» вместо «неактивно», значит, употребление этого слова будет более понятно остальным членам команды. Никто же не ходит в магазин за гальваническим элементом, все ходят за батарейками.
Важно! Если разные коллеги говорят по-разному (кто-то «хинт», кто-то «подсказка»), для эффективности дальнейшего поиска такой ошибки лучше при описании употребить и то, и другое слово.
Третий – одно из правил, провозглашённых в фильме «Посвященный», — «Правильно употребляй слова». Например, иногда словом «символ» заменяют слово «буква», но это разные входные данные, не следует их путать.
10. Перечитать
После того, как вы написали и откорректировали описание ошибки, обязательно перечитайте от начала и до конца. Возможно, вы найдёте опечатку, нечаянный повтор слова, лишний символ или что-то в этом духе. Поскольку взгляд замыливается от чтения собственного текста, я использую метод переключения внимания – увожу взгляд буквально на пару секунд на растение в горшке или соседа слева, а потом возвращаюсь к тексту.
Дополнительно я советую почитать книжку Ли Лефевера «Искусство объяснять. Как сделать так, чтобы вас понимали с полуслова».
Учитесь доносить свои мысли грамотно и понятно, чтобы вас было легко и приятно читать. И да пребудет с вами сила!
P.S.: Убийца – дворецкий, а тот «невероятный кусок текста» из начала статьи должен был выглядеть вот так:
«Не помещаются полностью названия файлов в файловом контроле документа при наличии нескольких файлов.
1) Создать любой документ УД. Оставить в режиме окна, не переходить в полноэкранный.
2) Добавить более 1 файла на вкладке Регистрация в файловый контроль (командой контекстного меню или перетаскиванием).
Результат: Названия файлов видны не полностью. Недостаточно места для отображения названий файлов при размере окна по умолчанию.
Ожидаемый результат: Названия файлов должны отображаться полностью.»
Комментарии (65)
the_bat
04.08.2015 23:27+8Сам работал тестировщиком несколько лет. Казалась бы да, понятны оба варианта, но мне кажется, что соблюдать правила литературного написания текста не сложно и Вы можете быть уверены что баг воспроизведут и пофиксят без лишних вопросов. Я за второй, правильный, вариант. Когда проектов более одного, а багов более сотни — это помогает. Респект за статью.
FishDude
04.08.2015 23:59-6Большинство этих «правил» на деле являются не правилами, а «капризами». И на вопрос, «а что даёт выполнение этого правила?» правильный ответ будет «глубокое удовлетворение моего начальственного эго».
the_bat
05.08.2015 09:35+7Знавал я тестировщиков, которые не могли воспроизвести описанный ими баг. Хотя баг был. От описания зависит многое. При работе в команде важно, чтобы это описание было структурированных и ещё и однообразным для всех проектов, в этом случае тестеры и разработчики «притераются» друг к другу.
Potapo4ka
05.08.2015 10:30+5Я бы назвала это «рекомендации по оформлению баг-репорта». Существуют же всяческие рекомендации по оформлению кода, чтобы его легче было читать. Если следовать вашей логике, то это тоже своего рода каприз и можно писать весь код вообще в одну строчку, а переменные называть zxcvbn =)
J_K
05.08.2015 00:41+13Да ерунда все это. Обезличенное — необезличенное.
Вы не сказали главного.
Описание бага должно содержать всего лишь 3 секции:
1) Шаги, которые надо выполнить, чтобы воспроизвести баг.
2) Ожидаемая реакция системы
3) Действительная реакция системы.
Все!
Да, еще описание должно касаться только ОДНОГО бага. Для каждого бага, пусть даже самого незначительного, заводить отдельную запись.Potapo4ka
05.08.2015 01:34+4видимо, вы невнимательно прочитали: я не писала о том, ЧТО писать в баг-репорте (такой информации в интернете более чем достаточно), я писала о том, КАК это писать.
J_K
05.08.2015 03:44+4Очень даже внимательно.
Как только вы начнете писать то, ЧТО нужно писать в репорте, проблема КАК уйдет сама собой.Potapo4ka
05.08.2015 10:36+1Иногда в большом куске информации есть всё, что нужно, но выуживать это нужное приходится по крупицам и из разных мест текста. Для меня это помехи в канале передачи информации, которые замедляют мою работу.
petuhov_k
05.08.2015 11:27Вы напрасно спорите. В компании где я работаю описание бага в обязательном порядке содержит шаги с ожидаемым и наблюдаемым поведением. Если этого нет, баг возвращается автору. В таком описании содержится вся необходимая и достаточная информация, как для разработчика, так и для тестировщика, который будет верифицировать баг. И это работает. Почему? Потому, что сложно научить человека составлять предложения так, чтобы они были понятны всегда и всем. Ну не будет человек сидеть и расставлять слова в нужном порядке, падежах и склонениях, ни тестировщик, ни тем более пользователь. Шаги же напротив — легко и просто написать, для этого не нужны особые лингвистические познания, их легко и просто понять. Шаги не избавляют от необходимости давать заголовок багу и составлять текстовое описание, но описание, это больше как дополнение. Попробуйте и Вам больше никогда не понадобится выуживать информацию по крупицам.
Potapo4ka
06.08.2015 00:26+1Шаги воспроизведения входят в описание ошибки. Под словом «Описание» я понимаю алгоритм воспроизведения, ожидаемое поведение, наблюдаемое поведение — это всё и есть описание (в контексте моей статьи). Как вы себе представляете описание без шагов? Вот только они могут быть написаны сплошным текстом, а могут быть структурированы в соответствии с описанными мной рекомендациями.
>>> сложно научить человека составлять предложения так, чтобы они были понятны всегда и всем
Сложно. Но можно попытаться направить поток его сознания в нужное русло. Именно на это направлены мои рекомендации.petuhov_k
06.08.2015 05:24Шаги должны быть написаны не сплошным текстом, и не в соответствии с вашими рекомендациями. Под шагами я понимаю описание вида:
1. Запустить приложение А.
2. Выбрать пункт меню Б->В
3. В появившемся диалоге перейти на вкладку Г.
4. Нажать кнопку Д.
Ожидается: поле Е меняет значение на Ё
Наблюдается: поле Е не изменилось
Понятно, доступно, одно правило, вместо 10.Potapo4ka
06.08.2015 09:34Теперь представьте что у вас большая и сложная система, и что много чего в ней нужно настроить и выполнить, чтобы получить ошибку. Например, была у меня ошибка, которая возникала на втором этапе второго цикла согласования документов. Сначала нужно написать, что и где требуется заполнить в карточке документа, чтобы можно было запустить согласование. Затем запустить согласование. Затем полностью описать действия согласующего, консолидатора согласования на первом цикле согласования, чтобы дойти до второго, затем описать действия согласующего на первом этапе второго цикла. Ещё существует куча предусловий, например, корректно запущенный workflow-сервис и в достаточном объёме выданные права.
Иногда получается довольно внушительный объём информации, поэтому я своим коллегам и предлагаю структурировать всё, это: разбить на пункты, описывать простыми предложениями, убрать лишние слова, очевидные действия сократить, где непонятно расписать подробнее (например, у нас не все разработчики в курсе, как запустить согласование), слова употреблять однозначно и понятно (чтобы разработчик не размышлял, что такое «виза»), а в конце перечитать всё получившееся.
Кстати, в своём примере вы и сами соблюли большинство из моих правил, хотя сами себе в этом не признаётесь =)
Я рада, что по наитию вы сразу всё пишите просто и понятно. Так делают, к сожалению, не все.
Wouw
05.08.2015 06:54+1Еще должно быть обоснование ожидаемой реакции системы. Иначе «тестеры» начинают сами придумывать правильную реакцию. И на основании вымышленной «правильной реакции» оформляют баг.
J_K
05.08.2015 07:16Для этого элементарно делается ссылка на параграф или раздел в спецификации.
Envek
05.08.2015 15:13+2Если таковая есть :-)
J_K
05.08.2015 21:28Да, разумеется :)
Если нет, делается ссылка на любой другой документ (письмо, чат и т.д.), где проводилось обсуждение данного вопроса.
Если и этого нет, тогда надо, чтобы тестер просто спросил у ответственного лица, какая должна быть реакция. Желательно в письменном виде. После этого ответ вставляется в описание бага.
Self_Perfection
05.08.2015 13:26Вот да. Только для себя я выработал на один пункт более длинный список пунктов, который применим к любой просьбе о помощи с компьтерной проблемой:
1) Какую глобально задачу решаю
2) Какие шаги выполняю
3) Что ожидаю получить
4) Чем отличается фактически полученное от ожидаемого.
Отсутствие информации по какому-либо пункту почти наверняка потребует дополнительных уточняющих вопросов. И да, первый пункт тоже нужен. Пример высосанный из пальца: не получается отправить письмо электропчтой (далее действия, симптомы и проблемы). Вот только дебажить эту проблему оказывается неправильным, потому что глобальная задача «отправить большой файл соседу» в данном случае решается гораздо проще через уже существующий сетевой диск.
servekon
05.08.2015 09:18+1Пример:
Плохо – «На панели инструментов есть кнопка с шестерёнкой, открывающая меню из двух пунктов, при наведении на которую не появляется всплывающая подсказка».
Хорошо – «Навести мышку на кнопку с шестерёнкой на панели инструментов – не появилась всплывающая подсказка».
Есть ощущение, что «хороший» вариант писал гугл переводчик. Мне кажется, что хороший вариант должен звучать так:
При наведении на кнопку с шестерёнкой на панели инструментов(,) не появляется всплывающая подсказка.Potapo4ka
05.08.2015 10:07тоже хороший вариант
Kain_Haart
05.08.2015 14:18+1Ваш хороший вариант не соответствует «что-где-когда».
Он имеет форму «когда-что-где».
Т.о. по вашим правилам лучше бы он имел видНе появляется всплывающая подсказка на панели инструментов при наведении мыши на иконку с шестеренкой
achekalin
05.08.2015 11:30+1> 10 правил хорошего тона при описании багов
Прочитал, после утренней запарки, как «правила хорошего тона при НАПИСАНИИ багов»
zv347
05.08.2015 12:01+1Вот типичный сценарий моего общения с ТП (немного утрировал и упростил).
1. Пишу репорт, например:При появлении на странице модального окошка типа alert страница становится неактивной, но сам «алерт» не отображается. При сворачивании окна браузера и последующем разворачивании (или просто уходе фокуса с браузера) — оно появляется. Воспроизводится на любой странице, в Win7 и XP. Например, попробуйте открыть html-файл вот с этим:
<script> alert('Оп-па!') </script>
(Это не дословно, но текст реального багрепорта. Видимо, автор сего поста был бы в шоке, хотя для человека более-менее «в теме» ничего непонятного.)
2. Ответ:Спасибо бла-бла-бла очень важно, мы ничего не поняли, ничего не можем воспроизвести, пришлите скриншот, версию системы, что на вас сейчас надето, что вы ели вчера вечером.
3. Присылаю требуемое.
4. Ответ:Ах да, мы уж сто лет про это знаем, исправим, исправим.
Вообще, то, что описано в посте, действительно похоже на капризы. Я не имею в виду штатных тестировщиков, но с обычными пользователями, посылающими репорты через формы обратной связи — так точно нельзя.
knagaev
05.08.2015 12:04+2Интересную картинку для привлечения внимания подобрали.
Очень смешно она захватывается краем глаза при прочтении первого предложения :)
zeromodule
05.08.2015 13:34Я полностью согласен с автором.
А все те, кто выше считают, что всё это не обязательно, что важно не КАК, а ЧТО, что иногда достаточно только скриншота, и позволяющие себе прочие вольности и отклонения от современных промышленных стандартов — просто непрофессионалы, которым нужно отправляться на дополнительное обучение.
BigD
05.08.2015 15:43«Плохо – «Нажимаем кнопку», «Открываю страницу».
Хорошо – «Нажать кнопку», «Открыть страницу».»
Категорически не согласен. Я описыываю, что у меня не работало и не работает, а не пишу инструкцию по воспроизведению тестировщиком того или иного бага.
Поэтому только первый вариант.
Или даже лучше в прошедшем времени: «Нажал кнопку. Открыл страницу. Картинка не появилась».
EvilsInterrupt
05.08.2015 15:48А для кого Вы пишите? ;)
Как раз-таки для тестировщиков и пишите, потому что после того как багу пофиксят именно они будут перепроверять.
Любой личный вклад человека легко смотрится по: автор баги, автор комита, автор еще чего-нибудь.
А в документации писать СТРОГО без указания себя любимого!BigD
05.08.2015 15:55+1Вы перекладываете на пользователя, столкнувшегося с багом, работу по написанию сценария тестирования. А это не его функция и не его цель. Даже исправление бага не является его целью. Целью пользователя является нормальная работа инструмента.
P.S. Работал как тимлидом первой линии поддержки, так и менеджером проектов разработки, так что вижу ситуацию с двух сторон.EvilsInterrupt
05.08.2015 16:24>>Вы перекладываете на пользователя, столкнувшегося с багом
А причем тут пользователь?
Вы путаете «теплое» с «мягким» это разное!
Да. Согласен, что пользователь не обязан быть технарем. Но в статье идет речь не о пользователях! А о участниках команды разработчиков. Другими словами, про тестировщиков, разработчиков, представителях саппорта и др. Вот им-то как раз и надо уметь писать. А если не хотят учиться делать хорошо, то стоит им напомнить об их роли в процессе разработки.
agee
05.08.2015 22:47+1а не пишу инструкцию по воспроизведению тестировщиком того или иного бага
Вообще-то, статья именно о тестировщиках и программистах, которые потом будут воспроизводить и чинить эти баги.
Цитата из статьи:
просматриваю ошибки, записанные новенькими (а иногда и старенькими) тестировщиками
Тестировщик как раз и должен писать инструкцию по воспроизведению. К чему Ваш коммент?
steck
05.08.2015 18:36+2Пункт «Сократить очевидное» я бы вычеркнул.
Нужно описать то, что происходило, потому что
Открыть приложение по ярлыку
Может быть
- выделить ярлык и нажать Enter
- Кликнуть мышью два раза
- Вызвать контекстное меню правой кнопкой, выбрать открыть
- Набрать в консоли «имя_ярлыка».lnk
- Если ярлык в панели быстрого запуска — кликнуть по нему один раз
- Любое действие, не приводящее к открытию приложения. Например, перетащить ярлык куда-нибудь
и много других вариантов.
И очень и очень часто стандартный путь разработчика отличаеся от стандартного пути тестировщика в очевидных вещах.
Чем подробнее — тем лучше.Potapo4ka
05.08.2015 18:41+1Если все эти действия приводят к идентичному результату и от этого не зависит воспроизведение ошибки, то можно так сильно не детализировать.
Допустим, ошибка происходит в новой сессии. Для этого нужно открыть программу, что создаст новую сессию. Но КАК открыть программу — мышкой открыть или из консоли — да как угодно, это не нужно конкретизировать, главное открыть.steck
05.08.2015 19:43А кто Вам сказал, что от действий не зависит результат?
Мой опыт показывает, что чаще всего именно от деталей он и зависит. Очевидные баги не допускаются (ну или быстро починены) и осталось только нечто хитрое, но требующее 80% времени.
Пример из жизни: один баг по описанию смог воспроизвести только тестировщик-левша. Потому что в описании было «поставьте три точки» и только он ставил их не по часовой стрелке, а против.
Julles
05.08.2015 20:49Извините, а это как?
он ставил их не по часовой стрелке, а против
В текстовом редакторе? Мышью? Что-то не получается себе это представить.
Но насчет «очевидные баги не допускаются» вы, конечно, очень посмешили :)steck
05.08.2015 22:24+1Это был не текстовый, а графический редактор. С возможностью простенького 3d. От треугольника на плоскости строилась нормаль, по которую накладывалась фигура. В результате, если точки были расположены по другому, то фигуры шли в другую от плоскости сторону.
RadioAgent
05.08.2015 20:32Спасибо за статью. Отдал почитать сотрудникам, убрав вторую часть девятого пункта, про однозначность.
Хочу немного рассказать о причинах:
У нас команда разрабатывает тестирует и поддерживает крайне сложный программный продукт с невероятным количеством объектов. Доходит до того, что на этапе тестирования всплывает одинаковое именование совершенно разных объектов (очевидно, что эта проблема должна решаться не на этапе тестирования, а организационными методами, но сейчас не об этом).
Мы столкнулись со следующей проблемой:
в команде, естественно, сложился свой жаргон. Очень часто жаргонизмы рождаются на этапе становления проекта, когда вот эту штуку, которую еще толком не спроектировали, уже нужно как-то называть. Вот и рождаются всякие ППП, ОБЛ, Химеры, Толерансы, g-точки и прочие звери. Лишь в момент реализации интерфейсов звери обретают более благородные имена, которые закрепляются документацией.
А теперь представьте, что не только разработчики, но и тестировщики, и техподдержка смертельно заражены этой жаргонной заразой. Вот в этот момент понимаешь, что «аккумуляторная батарея питания» — это однозначная, всем понятная языковая единица, а «батарейка» — это любимая песня тестировщика.
Мы столкнулись с реальной проблемой при транслировании ошибки от пользователей через техподдержку к разработчикам и далее к тестировщикам. Когда из-за неоднозначных трактовок, терминов, обозначающих сразу множество элементов программы, сотрудники из разных групп начинали терять время. THIS IS BABYLON!
А еще, жаргонизмы — ужасные слова паразиты, которые моментально начинают лезть как тараканы в письма от техподдержки к клиентам, последствия чего проиллюстрированы первой картинкой в топике.
Посмотрев на все это было принято решение бичевать сотрудников за употребление даже самых безобидных сокращений и жаргонизмов при оформлениибаговошибок.
Чисто субъективно, создается ощущение, что культура документального общения, только благодаря жесткой дисциплине в команде техподдержки, сама собой стала расти во всех остальных командах. При этом, никаких жалоб на оформляемые багрепорты не поступало, всем все было понятно, и разработчиков никто не просил ничего ломать в их хрупком мировосприятии.
PS кстати, g-точка в интерфейсе осталась g-точкой. Я был бы не против еще и Химеры, это прибавило бы немного эпичности нашему программному продукту.
Julles
05.08.2015 21:02Моя головная боль при чтении баг репортов не очень опытных тестировщиков:
1) Лишние шаги в описании бага. Вместо того, чтобы сделать нормальный root cause analysis (насколько это в силах тестировщика) и определить минимальное число шагов для воспроизведения ошибки, записывают весь свой личный извилистый путь, который их к этой ошибке привел. А разработчик потом недоумевает где именно может происходить ошибка и каждый шаг считает существенным. Одна сотрудница так и не могла понять почему это важно, спорила со мной, ровно пока я не выдала ей интерна в помощь. Посмотрев на баги интерна и оказавшись по другую сторону баррикад, она быстро поняла, почему это проблема.
2) Схожее с предыдущим: в баге указывается, например, «браузер Хром». Идешь уточнить, и точно: это не означает, что ошибка воспроизводится только в Хроме, это тестировщик тестировал лишь в Хроме, вот его и указал. А воспроизводится ли в других браузерах (или в других версиях браузера), и существенная ли это информация в данном случае — его не волновало.
3) Из той же оперы: создать заковыристый баг, но не предположить, что это может быть багом только у конкретного пользователя, не проверить с другим эккаунтом — разработчик тратит время пытаясь понять, почему у него это не воспроизводится, и в результате выясняется, что смотреть надо в конкретный профиль конкретного пользователя.
4) Выдуманные соображения о том, что является или не является ожидаемым результатом. Даже если есть подробная документация, она не всегда может охватить все пограничные ситуации. Поэтому тестировщик уверенно создает баг, вместо того, чтобы уточнить у ответственного за требования, а совпадает ли его представление с представлением тестировщика. И если в компании каждый баг не проходит через человека, знакомого со всеми требованиями и способного выловить подобные штуки, то частенько в итоге чинят то, что сломано не было. Или, в лучшем случае, просто тратят чужое время.
xiWera
06.08.2015 03:01Первый текст вполне понятен опытному разработчику. Но годность статьи от этого не страдает.
В больших компаниях тебе редко описывает баги Наталья 80го левела, такие быстро взлетают над остальными. А у «обычных» тестеров другая крайность наблюдается — нифига не описывать вообще. Пример:
«нужная функциональность не работает»
тут смотрим на КПДВ в начале страницы
Rondo
А к какому врачу мне обращаться, если я одинаково хорошо понимаю оба варианта исходного «невероятного куска текста»?
bak
Значит вы разработчик 80-го левела :) На мой взгляд второй вариант воспринимается намного легче чем первый.
kentastik
Я тоже не очень понял что беспокоит автора, прекрасно понял поток сознания, в голове прям чётко нарисовалась картина происходящего. Что отметил для себя, так это отсутствие самого главного, 11 пункта — скринов ошибки :)
Potapo4ka
Скрины и прочие вложения не должны заменять собой описание. Первое, на что посмотрит разработчик при открытии багтрекинга (по крайней мере нашего багтрекинга) — описание, до вложений ещё нужно добраться, поэтому описание должно быть максимально понятным.
kentastik
Это опять ваше мнение. 1 хороший скрин перебивает все ваши пункты вместе взятые. И да, я в первую очередь смотрю именно скрины.
zeromodule
Ни один скриншот не может заменить чёткого текстового описания.
Возможно, просто кто-то не имеет достаточно опыта в QA и владения русским языком, чтобы описать проблему.
kentastik
Поговорка «Лучше один раз увидеть, чем 1000 раз услышать» Вам явно не знакома.
nekt
Часто бывает, что ни скриншота, ни текстового описания особо то и не нужно — достаточно иметь внятный системный лог происходящего.
Dywar
Как бы выглядел скрин по проблеме — «У нас что то не работает, разберитесь» :)
А так картинки очень помогали (мне лично).
agee
И что мне Ваш скриншот? Создается впечатление, что у Вас просто мало опыта разработки или Вы не работали над более или менее сложными проектами. Что если баг проявляется только при подключении к 3G с определенно выставленными настройками пользователя и только после того, как предварительно было сделано другое действие? Скриншот этот Ваш до лампочки будет в таких ситуациях.
EvilsInterrupt
Огромное количество людей «работают» исключительно «глазами». Зрительный образ очень важен!!! Можно очень хорошо и толково описать, тем самым вынудить человека представить где и что находится в тестируемом продукте\системе. А можно приложить скриншот, указать ссылку на хэлп, где указано как дойти до этого места и тем самым убивается ой как много зайцев, основные:
* Опытным не надо читать много буков им все понятно
* Новички знакомятся с продуктом, т.к. открывают хэлп
* Баг выглядит лаконичнее!
michael_vostrikov
Да, и GUI тоже дураки придумали.
Хороший скрин может ответить также на много второстепенных вопросов — браузер, ОС, URL страницы и т.д. Главное, на нем должно быть то, что может помочь в решении проблемы. Мне встречалось примерно такое: «При заходе на страницу такую-то белый экран». И реально скрин белого экрана, просто белый прямоугольник и ничего больше.
muxaeji
Скрин не очень хорошо заменяет текстовое описание. Во-первых, поиск баги по скринам — то еще развлечение, если багов больше 2-3. Во-вторых, скрин очень редко показывает историю — события которые привели к появлению бага. Т.е. тестовое описание все равно нужно практически всегда. А скрин, как дополнение, и отнюдь не обязательное.
П.С. Если кто-то подумал, что если нужна история, просто приложи видео, то это идея даже хуже.
kentastik
Вы слишком утрируете, при создании тикета невозможно обойтись без его названия и небольшого описания, скрин должен дополнять картину.
muxaeji
Название «Баг», описание «Смотри скрин». Или снова утрирую? =)
Впрочем, глагол «дополнять» можно понимать по разному. У нас обычно стараются чтобы проблема была полностью понятна из текста (если это не так, текст рекламации правится, пока не станет понятно).
Скрин — как необязательное дополнение.
burjui
Про поиск вы верно заметили. Нет ничего хуже поиска бага определённой «тематики», когда описания багов (особенно названия тикетов) выглядят, как пример в начале поста.
И вообще, непонятно, с чем спорят комментаторы выше. Вроде бы, автор не утверждал, что наличие хорошего описания подразумевает отстутствие скриншотов. В общем случае скриншоты дополняют описание. Если описание бага настолько просто, что умещается в скриншот, можно и опустить описание. Но при этом как минимум название тикета должно быть написано по правилам из поста, иначе придётся открывать каждый тикет с невнятным названием, чтобы посмотреть скриншот.
APXEOLOG
Не всегда можно описать проблему скрином. Скрин хорошо помогает когда есть что-то чего не должно быть («Вот тут кнопка активная, а должна быть неактивная»). А как вы будете скринить то чего нет, да еще и с последовательностью действий которая к этому привела? («Не появляется окно 'свойства' при нажатии кнопки свойства в контекстном меню более одного раза»)
vlivyur
EvilsInterrupt
В компании где работаю используется Jira. И аттачи видны сразу же и небольшие preview от скриншотов. Поэтому человек может сразу глянуть на картинку и заглянуть в описание, только в том случае если из скриншота непонятно. Это экономит время
alexey-kirilenko
из вас получится хороший тестер...?
kentastik
сомневаюсь, что человек сможет точно определять подаваемое на него электричество…
gluck59
В экосистеме автора статьи это будет звучать примерно так:
«Подключите провода от обеих рук к розетке. Напряжение есть, но непонятно сколько вольт».
zeromodule
Вы можете дальше позволять тестировщикам скидывать вам баги в том виде, в котором им взбрело в голову.