Comments 65
А к какому врачу мне обращаться, если я одинаково хорошо понимаю оба варианта исходного «невероятного куска текста»?
Значит вы разработчик 80-го левела :) На мой взгляд второй вариант воспринимается намного легче чем первый.
Я тоже не очень понял что беспокоит автора, прекрасно понял поток сознания, в голове прям чётко нарисовалась картина происходящего. Что отметил для себя, так это отсутствие самого главного, 11 пункта — скринов ошибки :)
Скрины и прочие вложения не должны заменять собой описание. Первое, на что посмотрит разработчик при открытии багтрекинга (по крайней мере нашего багтрекинга) — описание, до вложений ещё нужно добраться, поэтому описание должно быть максимально понятным.
Это опять ваше мнение. 1 хороший скрин перебивает все ваши пункты вместе взятые. И да, я в первую очередь смотрю именно скрины.
Ни один скриншот не может заменить чёткого текстового описания.
Возможно, просто кто-то не имеет достаточно опыта в QA и владения русским языком, чтобы описать проблему.
Возможно, просто кто-то не имеет достаточно опыта в QA и владения русским языком, чтобы описать проблему.
Поговорка «Лучше один раз увидеть, чем 1000 раз услышать» Вам явно не знакома.
Часто бывает, что ни скриншота, ни текстового описания особо то и не нужно — достаточно иметь внятный системный лог происходящего.
Как бы выглядел скрин по проблеме — «У нас что то не работает, разберитесь» :)
А так картинки очень помогали (мне лично).
А так картинки очень помогали (мне лично).
И что мне Ваш скриншот? Создается впечатление, что у Вас просто мало опыта разработки или Вы не работали над более или менее сложными проектами. Что если баг проявляется только при подключении к 3G с определенно выставленными настройками пользователя и только после того, как предварительно было сделано другое действие? Скриншот этот Ваш до лампочки будет в таких ситуациях.
Огромное количество людей «работают» исключительно «глазами». Зрительный образ очень важен!!! Можно очень хорошо и толково описать, тем самым вынудить человека представить где и что находится в тестируемом продукте\системе. А можно приложить скриншот, указать ссылку на хэлп, где указано как дойти до этого места и тем самым убивается ой как много зайцев, основные:
* Опытным не надо читать много буков им все понятно
* Новички знакомятся с продуктом, т.к. открывают хэлп
* Баг выглядит лаконичнее!
* Опытным не надо читать много буков им все понятно
* Новички знакомятся с продуктом, т.к. открывают хэлп
* Баг выглядит лаконичнее!
Да, и GUI тоже дураки придумали.
Хороший скрин может ответить также на много второстепенных вопросов — браузер, ОС, URL страницы и т.д. Главное, на нем должно быть то, что может помочь в решении проблемы. Мне встречалось примерно такое: «При заходе на страницу такую-то белый экран». И реально скрин белого экрана, просто белый прямоугольник и ничего больше.
Хороший скрин может ответить также на много второстепенных вопросов — браузер, ОС, URL страницы и т.д. Главное, на нем должно быть то, что может помочь в решении проблемы. Мне встречалось примерно такое: «При заходе на страницу такую-то белый экран». И реально скрин белого экрана, просто белый прямоугольник и ничего больше.
Скрин не очень хорошо заменяет текстовое описание. Во-первых, поиск баги по скринам — то еще развлечение, если багов больше 2-3. Во-вторых, скрин очень редко показывает историю — события которые привели к появлению бага. Т.е. тестовое описание все равно нужно практически всегда. А скрин, как дополнение, и отнюдь не обязательное.
П.С. Если кто-то подумал, что если нужна история, просто приложи видео, то это идея даже хуже.
П.С. Если кто-то подумал, что если нужна история, просто приложи видео, то это идея даже хуже.
Вы слишком утрируете, при создании тикета невозможно обойтись без его названия и небольшого описания, скрин должен дополнять картину.
Про поиск вы верно заметили. Нет ничего хуже поиска бага определённой «тематики», когда описания багов (особенно названия тикетов) выглядят, как пример в начале поста.
И вообще, непонятно, с чем спорят комментаторы выше. Вроде бы, автор не утверждал, что наличие хорошего описания подразумевает отстутствие скриншотов. В общем случае скриншоты дополняют описание. Если описание бага настолько просто, что умещается в скриншот, можно и опустить описание. Но при этом как минимум название тикета должно быть написано по правилам из поста, иначе придётся открывать каждый тикет с невнятным названием, чтобы посмотреть скриншот.
И вообще, непонятно, с чем спорят комментаторы выше. Вроде бы, автор не утверждал, что наличие хорошего описания подразумевает отстутствие скриншотов. В общем случае скриншоты дополняют описание. Если описание бага настолько просто, что умещается в скриншот, можно и опустить описание. Но при этом как минимум название тикета должно быть написано по правилам из поста, иначе придётся открывать каждый тикет с невнятным названием, чтобы посмотреть скриншот.
Не всегда можно описать проблему скрином. Скрин хорошо помогает когда есть что-то чего не должно быть («Вот тут кнопка активная, а должна быть неактивная»). А как вы будете скринить то чего нет, да еще и с последовательностью действий которая к этому привела? («Не появляется окно 'свойства' при нажатии кнопки свойства в контекстном меню более одного раза»)
хороший скринКак видим, скриншоты тоже надо уметь готовить. Чтоб не получалось что на картинке MDI-приложение с кучей окошек в FHD разрешении и маленькое сообщение об ошибке. Или наоборот, когда присылают только окошко с ошибкой (кто ещё не знает: там тоже можно Ctrl-C нажимать), а ты догадывайся что могло привести к нему.
В компании где работаю используется Jira. И аттачи видны сразу же и небольшие preview от скриншотов. Поэтому человек может сразу глянуть на картинку и заглянуть в описание, только в том случае если из скриншота непонятно. Это экономит время
из вас получится хороший тестер...?
Вы можете дальше позволять тестировщикам скидывать вам баги в том виде, в котором им взбрело в голову.
Сам работал тестировщиком несколько лет. Казалась бы да, понятны оба варианта, но мне кажется, что соблюдать правила литературного написания текста не сложно и Вы можете быть уверены что баг воспроизведут и пофиксят без лишних вопросов. Я за второй, правильный, вариант. Когда проектов более одного, а багов более сотни — это помогает. Респект за статью.
Большинство этих «правил» на деле являются не правилами, а «капризами». И на вопрос, «а что даёт выполнение этого правила?» правильный ответ будет «глубокое удовлетворение моего начальственного эго».
Знавал я тестировщиков, которые не могли воспроизвести описанный ими баг. Хотя баг был. От описания зависит многое. При работе в команде важно, чтобы это описание было структурированных и ещё и однообразным для всех проектов, в этом случае тестеры и разработчики «притераются» друг к другу.
Я бы назвала это «рекомендации по оформлению баг-репорта». Существуют же всяческие рекомендации по оформлению кода, чтобы его легче было читать. Если следовать вашей логике, то это тоже своего рода каприз и можно писать весь код вообще в одну строчку, а переменные называть zxcvbn =)
Да ерунда все это. Обезличенное — необезличенное.
Вы не сказали главного.
Описание бага должно содержать всего лишь 3 секции:
1) Шаги, которые надо выполнить, чтобы воспроизвести баг.
2) Ожидаемая реакция системы
3) Действительная реакция системы.
Все!
Да, еще описание должно касаться только ОДНОГО бага. Для каждого бага, пусть даже самого незначительного, заводить отдельную запись.
Вы не сказали главного.
Описание бага должно содержать всего лишь 3 секции:
1) Шаги, которые надо выполнить, чтобы воспроизвести баг.
2) Ожидаемая реакция системы
3) Действительная реакция системы.
Все!
Да, еще описание должно касаться только ОДНОГО бага. Для каждого бага, пусть даже самого незначительного, заводить отдельную запись.
видимо, вы невнимательно прочитали: я не писала о том, ЧТО писать в баг-репорте (такой информации в интернете более чем достаточно), я писала о том, КАК это писать.
Очень даже внимательно.
Как только вы начнете писать то, ЧТО нужно писать в репорте, проблема КАК уйдет сама собой.
Как только вы начнете писать то, ЧТО нужно писать в репорте, проблема КАК уйдет сама собой.
Иногда в большом куске информации есть всё, что нужно, но выуживать это нужное приходится по крупицам и из разных мест текста. Для меня это помехи в канале передачи информации, которые замедляют мою работу.
Вы напрасно спорите. В компании где я работаю описание бага в обязательном порядке содержит шаги с ожидаемым и наблюдаемым поведением. Если этого нет, баг возвращается автору. В таком описании содержится вся необходимая и достаточная информация, как для разработчика, так и для тестировщика, который будет верифицировать баг. И это работает. Почему? Потому, что сложно научить человека составлять предложения так, чтобы они были понятны всегда и всем. Ну не будет человек сидеть и расставлять слова в нужном порядке, падежах и склонениях, ни тестировщик, ни тем более пользователь. Шаги же напротив — легко и просто написать, для этого не нужны особые лингвистические познания, их легко и просто понять. Шаги не избавляют от необходимости давать заголовок багу и составлять текстовое описание, но описание, это больше как дополнение. Попробуйте и Вам больше никогда не понадобится выуживать информацию по крупицам.
Подтверждаю. Это работает.
Шаги воспроизведения входят в описание ошибки. Под словом «Описание» я понимаю алгоритм воспроизведения, ожидаемое поведение, наблюдаемое поведение — это всё и есть описание (в контексте моей статьи). Как вы себе представляете описание без шагов? Вот только они могут быть написаны сплошным текстом, а могут быть структурированы в соответствии с описанными мной рекомендациями.
>>> сложно научить человека составлять предложения так, чтобы они были понятны всегда и всем
Сложно. Но можно попытаться направить поток его сознания в нужное русло. Именно на это направлены мои рекомендации.
>>> сложно научить человека составлять предложения так, чтобы они были понятны всегда и всем
Сложно. Но можно попытаться направить поток его сознания в нужное русло. Именно на это направлены мои рекомендации.
Шаги должны быть написаны не сплошным текстом, и не в соответствии с вашими рекомендациями. Под шагами я понимаю описание вида:
1. Запустить приложение А.
2. Выбрать пункт меню Б->В
3. В появившемся диалоге перейти на вкладку Г.
4. Нажать кнопку Д.
Ожидается: поле Е меняет значение на Ё
Наблюдается: поле Е не изменилось
Понятно, доступно, одно правило, вместо 10.
1. Запустить приложение А.
2. Выбрать пункт меню Б->В
3. В появившемся диалоге перейти на вкладку Г.
4. Нажать кнопку Д.
Ожидается: поле Е меняет значение на Ё
Наблюдается: поле Е не изменилось
Понятно, доступно, одно правило, вместо 10.
Теперь представьте что у вас большая и сложная система, и что много чего в ней нужно настроить и выполнить, чтобы получить ошибку. Например, была у меня ошибка, которая возникала на втором этапе второго цикла согласования документов. Сначала нужно написать, что и где требуется заполнить в карточке документа, чтобы можно было запустить согласование. Затем запустить согласование. Затем полностью описать действия согласующего, консолидатора согласования на первом цикле согласования, чтобы дойти до второго, затем описать действия согласующего на первом этапе второго цикла. Ещё существует куча предусловий, например, корректно запущенный workflow-сервис и в достаточном объёме выданные права.
Иногда получается довольно внушительный объём информации, поэтому я своим коллегам и предлагаю структурировать всё, это: разбить на пункты, описывать простыми предложениями, убрать лишние слова, очевидные действия сократить, где непонятно расписать подробнее (например, у нас не все разработчики в курсе, как запустить согласование), слова употреблять однозначно и понятно (чтобы разработчик не размышлял, что такое «виза»), а в конце перечитать всё получившееся.
Кстати, в своём примере вы и сами соблюли большинство из моих правил, хотя сами себе в этом не признаётесь =)
Я рада, что по наитию вы сразу всё пишите просто и понятно. Так делают, к сожалению, не все.
Иногда получается довольно внушительный объём информации, поэтому я своим коллегам и предлагаю структурировать всё, это: разбить на пункты, описывать простыми предложениями, убрать лишние слова, очевидные действия сократить, где непонятно расписать подробнее (например, у нас не все разработчики в курсе, как запустить согласование), слова употреблять однозначно и понятно (чтобы разработчик не размышлял, что такое «виза»), а в конце перечитать всё получившееся.
Кстати, в своём примере вы и сами соблюли большинство из моих правил, хотя сами себе в этом не признаётесь =)
Я рада, что по наитию вы сразу всё пишите просто и понятно. Так делают, к сожалению, не все.
Еще должно быть обоснование ожидаемой реакции системы. Иначе «тестеры» начинают сами придумывать правильную реакцию. И на основании вымышленной «правильной реакции» оформляют баг.
Для этого элементарно делается ссылка на параграф или раздел в спецификации.
Если таковая есть :-)
Да, разумеется :)
Если нет, делается ссылка на любой другой документ (письмо, чат и т.д.), где проводилось обсуждение данного вопроса.
Если и этого нет, тогда надо, чтобы тестер просто спросил у ответственного лица, какая должна быть реакция. Желательно в письменном виде. После этого ответ вставляется в описание бага.
Если нет, делается ссылка на любой другой документ (письмо, чат и т.д.), где проводилось обсуждение данного вопроса.
Если и этого нет, тогда надо, чтобы тестер просто спросил у ответственного лица, какая должна быть реакция. Желательно в письменном виде. После этого ответ вставляется в описание бага.
Вот да. Только для себя я выработал на один пункт более длинный список пунктов, который применим к любой просьбе о помощи с компьтерной проблемой:
1) Какую глобально задачу решаю
2) Какие шаги выполняю
3) Что ожидаю получить
4) Чем отличается фактически полученное от ожидаемого.
Отсутствие информации по какому-либо пункту почти наверняка потребует дополнительных уточняющих вопросов. И да, первый пункт тоже нужен. Пример высосанный из пальца: не получается отправить письмо электропчтой (далее действия, симптомы и проблемы). Вот только дебажить эту проблему оказывается неправильным, потому что глобальная задача «отправить большой файл соседу» в данном случае решается гораздо проще через уже существующий сетевой диск.
1) Какую глобально задачу решаю
2) Какие шаги выполняю
3) Что ожидаю получить
4) Чем отличается фактически полученное от ожидаемого.
Отсутствие информации по какому-либо пункту почти наверняка потребует дополнительных уточняющих вопросов. И да, первый пункт тоже нужен. Пример высосанный из пальца: не получается отправить письмо электропчтой (далее действия, симптомы и проблемы). Вот только дебажить эту проблему оказывается неправильным, потому что глобальная задача «отправить большой файл соседу» в данном случае решается гораздо проще через уже существующий сетевой диск.
Пример:
Плохо – «На панели инструментов есть кнопка с шестерёнкой, открывающая меню из двух пунктов, при наведении на которую не появляется всплывающая подсказка».
Хорошо – «Навести мышку на кнопку с шестерёнкой на панели инструментов – не появилась всплывающая подсказка».
Есть ощущение, что «хороший» вариант писал гугл переводчик. Мне кажется, что хороший вариант должен звучать так:
При наведении на кнопку с шестерёнкой на панели инструментов(,) не появляется всплывающая подсказка.
> 10 правил хорошего тона при описании багов
Прочитал, после утренней запарки, как «правила хорошего тона при НАПИСАНИИ багов»
Прочитал, после утренней запарки, как «правила хорошего тона при НАПИСАНИИ багов»
Вот типичный сценарий моего общения с ТП (немного утрировал и упростил).
1. Пишу репорт, например:
(Это не дословно, но текст реального багрепорта. Видимо, автор сего поста был бы в шоке, хотя для человека более-менее «в теме» ничего непонятного.)
2. Ответ:
3. Присылаю требуемое.
4. Ответ:
Вообще, то, что описано в посте, действительно похоже на капризы. Я не имею в виду штатных тестировщиков, но с обычными пользователями, посылающими репорты через формы обратной связи — так точно нельзя.
1. Пишу репорт, например:
При появлении на странице модального окошка типа alert страница становится неактивной, но сам «алерт» не отображается. При сворачивании окна браузера и последующем разворачивании (или просто уходе фокуса с браузера) — оно появляется. Воспроизводится на любой странице, в Win7 и XP. Например, попробуйте открыть html-файл вот с этим:<script> alert('Оп-па!') </script>
(Это не дословно, но текст реального багрепорта. Видимо, автор сего поста был бы в шоке, хотя для человека более-менее «в теме» ничего непонятного.)
2. Ответ:
Спасибо бла-бла-бла очень важно, мы ничего не поняли, ничего не можем воспроизвести, пришлите скриншот, версию системы, что на вас сейчас надето, что вы ели вчера вечером.
3. Присылаю требуемое.
4. Ответ:
Ах да, мы уж сто лет про это знаем, исправим, исправим.
Вообще, то, что описано в посте, действительно похоже на капризы. Я не имею в виду штатных тестировщиков, но с обычными пользователями, посылающими репорты через формы обратной связи — так точно нельзя.
Интересную картинку для привлечения внимания подобрали.
Очень смешно она захватывается краем глаза при прочтении первого предложения :)
Очень смешно она захватывается краем глаза при прочтении первого предложения :)
Я полностью согласен с автором.
А все те, кто выше считают, что всё это не обязательно, что важно не КАК, а ЧТО, что иногда достаточно только скриншота, и позволяющие себе прочие вольности и отклонения от современных промышленных стандартов — просто непрофессионалы, которым нужно отправляться на дополнительное обучение.
А все те, кто выше считают, что всё это не обязательно, что важно не КАК, а ЧТО, что иногда достаточно только скриншота, и позволяющие себе прочие вольности и отклонения от современных промышленных стандартов — просто непрофессионалы, которым нужно отправляться на дополнительное обучение.
«Плохо – «Нажимаем кнопку», «Открываю страницу».
Хорошо – «Нажать кнопку», «Открыть страницу».»
Категорически не согласен. Я описыываю, что у меня не работало и не работает, а не пишу инструкцию по воспроизведению тестировщиком того или иного бага.
Поэтому только первый вариант.
Или даже лучше в прошедшем времени: «Нажал кнопку. Открыл страницу. Картинка не появилась».
Хорошо – «Нажать кнопку», «Открыть страницу».»
Категорически не согласен. Я описыываю, что у меня не работало и не работает, а не пишу инструкцию по воспроизведению тестировщиком того или иного бага.
Поэтому только первый вариант.
Или даже лучше в прошедшем времени: «Нажал кнопку. Открыл страницу. Картинка не появилась».
А для кого Вы пишите? ;)
Как раз-таки для тестировщиков и пишите, потому что после того как багу пофиксят именно они будут перепроверять.
Любой личный вклад человека легко смотрится по: автор баги, автор комита, автор еще чего-нибудь.
А в документации писать СТРОГО без указания себя любимого!
Как раз-таки для тестировщиков и пишите, потому что после того как багу пофиксят именно они будут перепроверять.
Любой личный вклад человека легко смотрится по: автор баги, автор комита, автор еще чего-нибудь.
А в документации писать СТРОГО без указания себя любимого!
Вы перекладываете на пользователя, столкнувшегося с багом, работу по написанию сценария тестирования. А это не его функция и не его цель. Даже исправление бага не является его целью. Целью пользователя является нормальная работа инструмента.
P.S. Работал как тимлидом первой линии поддержки, так и менеджером проектов разработки, так что вижу ситуацию с двух сторон.
P.S. Работал как тимлидом первой линии поддержки, так и менеджером проектов разработки, так что вижу ситуацию с двух сторон.
>>Вы перекладываете на пользователя, столкнувшегося с багом
А причем тут пользователь?
Вы путаете «теплое» с «мягким» это разное!
Да. Согласен, что пользователь не обязан быть технарем. Но в статье идет речь не о пользователях! А о участниках команды разработчиков. Другими словами, про тестировщиков, разработчиков, представителях саппорта и др. Вот им-то как раз и надо уметь писать. А если не хотят учиться делать хорошо, то стоит им напомнить об их роли в процессе разработки.
А причем тут пользователь?
Вы путаете «теплое» с «мягким» это разное!
Да. Согласен, что пользователь не обязан быть технарем. Но в статье идет речь не о пользователях! А о участниках команды разработчиков. Другими словами, про тестировщиков, разработчиков, представителях саппорта и др. Вот им-то как раз и надо уметь писать. А если не хотят учиться делать хорошо, то стоит им напомнить об их роли в процессе разработки.
а не пишу инструкцию по воспроизведению тестировщиком того или иного бага
Вообще-то, статья именно о тестировщиках и программистах, которые потом будут воспроизводить и чинить эти баги.
Цитата из статьи:
просматриваю ошибки, записанные новенькими (а иногда и старенькими) тестировщиками
Тестировщик как раз и должен писать инструкцию по воспроизведению. К чему Ваш коммент?
Пункт «Сократить очевидное» я бы вычеркнул.
Нужно описать то, что происходило, потому что
Может быть
и много других вариантов.
И очень и очень часто стандартный путь разработчика отличаеся от стандартного пути тестировщика в очевидных вещах.
Чем подробнее — тем лучше.
Нужно описать то, что происходило, потому что
Открыть приложение по ярлыку
Может быть
- выделить ярлык и нажать Enter
- Кликнуть мышью два раза
- Вызвать контекстное меню правой кнопкой, выбрать открыть
- Набрать в консоли «имя_ярлыка».lnk
- Если ярлык в панели быстрого запуска — кликнуть по нему один раз
- Любое действие, не приводящее к открытию приложения. Например, перетащить ярлык куда-нибудь
и много других вариантов.
И очень и очень часто стандартный путь разработчика отличаеся от стандартного пути тестировщика в очевидных вещах.
Чем подробнее — тем лучше.
Если все эти действия приводят к идентичному результату и от этого не зависит воспроизведение ошибки, то можно так сильно не детализировать.
Допустим, ошибка происходит в новой сессии. Для этого нужно открыть программу, что создаст новую сессию. Но КАК открыть программу — мышкой открыть или из консоли — да как угодно, это не нужно конкретизировать, главное открыть.
Допустим, ошибка происходит в новой сессии. Для этого нужно открыть программу, что создаст новую сессию. Но КАК открыть программу — мышкой открыть или из консоли — да как угодно, это не нужно конкретизировать, главное открыть.
А кто Вам сказал, что от действий не зависит результат?
Мой опыт показывает, что чаще всего именно от деталей он и зависит. Очевидные баги не допускаются (ну или быстро починены) и осталось только нечто хитрое, но требующее 80% времени.
Пример из жизни: один баг по описанию смог воспроизвести только тестировщик-левша. Потому что в описании было «поставьте три точки» и только он ставил их не по часовой стрелке, а против.
Мой опыт показывает, что чаще всего именно от деталей он и зависит. Очевидные баги не допускаются (ну или быстро починены) и осталось только нечто хитрое, но требующее 80% времени.
Пример из жизни: один баг по описанию смог воспроизвести только тестировщик-левша. Потому что в описании было «поставьте три точки» и только он ставил их не по часовой стрелке, а против.
Извините, а это как?
В текстовом редакторе? Мышью? Что-то не получается себе это представить.
Но насчет «очевидные баги не допускаются» вы, конечно, очень посмешили :)
он ставил их не по часовой стрелке, а против
В текстовом редакторе? Мышью? Что-то не получается себе это представить.
Но насчет «очевидные баги не допускаются» вы, конечно, очень посмешили :)
Спасибо за статью. Отдал почитать сотрудникам, убрав вторую часть девятого пункта, про однозначность.
Хочу немного рассказать о причинах:
У нас команда разрабатывает тестирует и поддерживает крайне сложный программный продукт с невероятным количеством объектов. Доходит до того, что на этапе тестирования всплывает одинаковое именование совершенно разных объектов (очевидно, что эта проблема должна решаться не на этапе тестирования, а организационными методами, но сейчас не об этом).
Мы столкнулись со следующей проблемой:
в команде, естественно, сложился свой жаргон. Очень часто жаргонизмы рождаются на этапе становления проекта, когда вот эту штуку, которую еще толком не спроектировали, уже нужно как-то называть. Вот и рождаются всякие ППП, ОБЛ, Химеры, Толерансы, g-точки и прочие звери. Лишь в момент реализации интерфейсов звери обретают более благородные имена, которые закрепляются документацией.
А теперь представьте, что не только разработчики, но и тестировщики, и техподдержка смертельно заражены этой жаргонной заразой. Вот в этот момент понимаешь, что «аккумуляторная батарея питания» — это однозначная, всем понятная языковая единица, а «батарейка» — это любимая песня тестировщика.
Мы столкнулись с реальной проблемой при транслировании ошибки от пользователей через техподдержку к разработчикам и далее к тестировщикам. Когда из-за неоднозначных трактовок, терминов, обозначающих сразу множество элементов программы, сотрудники из разных групп начинали терять время. THIS IS BABYLON!
А еще, жаргонизмы — ужасные слова паразиты, которые моментально начинают лезть как тараканы в письма от техподдержки к клиентам, последствия чего проиллюстрированы первой картинкой в топике.
Посмотрев на все это было принято решение бичевать сотрудников за употребление даже самых безобидных сокращений и жаргонизмов при оформлениибагов ошибок.
Чисто субъективно, создается ощущение, что культура документального общения, только благодаря жесткой дисциплине в команде техподдержки, сама собой стала расти во всех остальных командах. При этом, никаких жалоб на оформляемые багрепорты не поступало, всем все было понятно, и разработчиков никто не просил ничего ломать в их хрупком мировосприятии.
PS кстати, g-точка в интерфейсе осталась g-точкой. Я был бы не против еще и Химеры, это прибавило бы немного эпичности нашему программному продукту.
Хочу немного рассказать о причинах:
У нас команда разрабатывает тестирует и поддерживает крайне сложный программный продукт с невероятным количеством объектов. Доходит до того, что на этапе тестирования всплывает одинаковое именование совершенно разных объектов (очевидно, что эта проблема должна решаться не на этапе тестирования, а организационными методами, но сейчас не об этом).
Мы столкнулись со следующей проблемой:
в команде, естественно, сложился свой жаргон. Очень часто жаргонизмы рождаются на этапе становления проекта, когда вот эту штуку, которую еще толком не спроектировали, уже нужно как-то называть. Вот и рождаются всякие ППП, ОБЛ, Химеры, Толерансы, g-точки и прочие звери. Лишь в момент реализации интерфейсов звери обретают более благородные имена, которые закрепляются документацией.
А теперь представьте, что не только разработчики, но и тестировщики, и техподдержка смертельно заражены этой жаргонной заразой. Вот в этот момент понимаешь, что «аккумуляторная батарея питания» — это однозначная, всем понятная языковая единица, а «батарейка» — это любимая песня тестировщика.
Мы столкнулись с реальной проблемой при транслировании ошибки от пользователей через техподдержку к разработчикам и далее к тестировщикам. Когда из-за неоднозначных трактовок, терминов, обозначающих сразу множество элементов программы, сотрудники из разных групп начинали терять время. THIS IS BABYLON!
А еще, жаргонизмы — ужасные слова паразиты, которые моментально начинают лезть как тараканы в письма от техподдержки к клиентам, последствия чего проиллюстрированы первой картинкой в топике.
Посмотрев на все это было принято решение бичевать сотрудников за употребление даже самых безобидных сокращений и жаргонизмов при оформлении
Чисто субъективно, создается ощущение, что культура документального общения, только благодаря жесткой дисциплине в команде техподдержки, сама собой стала расти во всех остальных командах. При этом, никаких жалоб на оформляемые багрепорты не поступало, всем все было понятно, и разработчиков никто не просил ничего ломать в их хрупком мировосприятии.
PS кстати, g-точка в интерфейсе осталась g-точкой. Я был бы не против еще и Химеры, это прибавило бы немного эпичности нашему программному продукту.
Моя головная боль при чтении баг репортов не очень опытных тестировщиков:
1) Лишние шаги в описании бага. Вместо того, чтобы сделать нормальный root cause analysis (насколько это в силах тестировщика) и определить минимальное число шагов для воспроизведения ошибки, записывают весь свой личный извилистый путь, который их к этой ошибке привел. А разработчик потом недоумевает где именно может происходить ошибка и каждый шаг считает существенным. Одна сотрудница так и не могла понять почему это важно, спорила со мной, ровно пока я не выдала ей интерна в помощь. Посмотрев на баги интерна и оказавшись по другую сторону баррикад, она быстро поняла, почему это проблема.
2) Схожее с предыдущим: в баге указывается, например, «браузер Хром». Идешь уточнить, и точно: это не означает, что ошибка воспроизводится только в Хроме, это тестировщик тестировал лишь в Хроме, вот его и указал. А воспроизводится ли в других браузерах (или в других версиях браузера), и существенная ли это информация в данном случае — его не волновало.
3) Из той же оперы: создать заковыристый баг, но не предположить, что это может быть багом только у конкретного пользователя, не проверить с другим эккаунтом — разработчик тратит время пытаясь понять, почему у него это не воспроизводится, и в результате выясняется, что смотреть надо в конкретный профиль конкретного пользователя.
4) Выдуманные соображения о том, что является или не является ожидаемым результатом. Даже если есть подробная документация, она не всегда может охватить все пограничные ситуации. Поэтому тестировщик уверенно создает баг, вместо того, чтобы уточнить у ответственного за требования, а совпадает ли его представление с представлением тестировщика. И если в компании каждый баг не проходит через человека, знакомого со всеми требованиями и способного выловить подобные штуки, то частенько в итоге чинят то, что сломано не было. Или, в лучшем случае, просто тратят чужое время.
1) Лишние шаги в описании бага. Вместо того, чтобы сделать нормальный root cause analysis (насколько это в силах тестировщика) и определить минимальное число шагов для воспроизведения ошибки, записывают весь свой личный извилистый путь, который их к этой ошибке привел. А разработчик потом недоумевает где именно может происходить ошибка и каждый шаг считает существенным. Одна сотрудница так и не могла понять почему это важно, спорила со мной, ровно пока я не выдала ей интерна в помощь. Посмотрев на баги интерна и оказавшись по другую сторону баррикад, она быстро поняла, почему это проблема.
2) Схожее с предыдущим: в баге указывается, например, «браузер Хром». Идешь уточнить, и точно: это не означает, что ошибка воспроизводится только в Хроме, это тестировщик тестировал лишь в Хроме, вот его и указал. А воспроизводится ли в других браузерах (или в других версиях браузера), и существенная ли это информация в данном случае — его не волновало.
3) Из той же оперы: создать заковыристый баг, но не предположить, что это может быть багом только у конкретного пользователя, не проверить с другим эккаунтом — разработчик тратит время пытаясь понять, почему у него это не воспроизводится, и в результате выясняется, что смотреть надо в конкретный профиль конкретного пользователя.
4) Выдуманные соображения о том, что является или не является ожидаемым результатом. Даже если есть подробная документация, она не всегда может охватить все пограничные ситуации. Поэтому тестировщик уверенно создает баг, вместо того, чтобы уточнить у ответственного за требования, а совпадает ли его представление с представлением тестировщика. И если в компании каждый баг не проходит через человека, знакомого со всеми требованиями и способного выловить подобные штуки, то частенько в итоге чинят то, что сломано не было. Или, в лучшем случае, просто тратят чужое время.
Первый текст вполне понятен опытному разработчику. Но годность статьи от этого не страдает.
В больших компаниях тебе редко описывает баги Наталья 80го левела, такие быстро взлетают над остальными. А у «обычных» тестеров другая крайность наблюдается — нифига не описывать вообще. Пример:
«нужная функциональность не работает»
тут смотрим на КПДВ в начале страницы
В больших компаниях тебе редко описывает баги Наталья 80го левела, такие быстро взлетают над остальными. А у «обычных» тестеров другая крайность наблюдается — нифига не описывать вообще. Пример:
«нужная функциональность не работает»
тут смотрим на КПДВ в начале страницы
Sign up to leave a comment.
10 правил хорошего тона при описании багов