Положение секций ожидаемый результат/фактический результат в отчёте об ошибке
Как-то где-то (что бы не раскрывать имён и не указывать на личности, а то ещё чего обидется) мне указал ведущий тестеровщик в нашей команде на неправильность моего отчёта об ошибке. Я перечитал свой отчёт и не найдя ошибки попросил пояснить. Пояснения были буквально следующими:
— ТЛ: у тебя после шагов сначала указан ожидаемый результат, а должен быть фактический.
— Я:???
— ТЛ: такая постановка может обескуражить и запутать разработчика.
Скажу честно, для меня это не принципиально, гибкие методологии разработки на то и гибкие, что как договоритесь внутри команды — так и будет. Но всё же, интереса ради, чтоб услышать аргументацию я подлил масла в огонь:
— Я: этот диссонанс несовпадения ожидаемого результата после выполненных шагов как раз подчеркнёт наличие ошибки.
-ТЛ: нет, это не правильно!
Не припомнив никакого жёсткого стандарта на этот счёт, мне стало интересно откуда растут ноги таких предубеждений. Поискав несколько вариантов, я набрёл, скорее всего, на первоисточник в рунете www.protesting.ru/...testing/bugstructure.html со структурой «шаги-фактический результат-ожидаемый результат» и несколько последователей, скорее всего переработанный копи-паст
dou.ua/forums/topic/13389, habrahabr.ru/...y/docsvision/blog/264163, habrahabr.ru/post/156099
И даже точь-в-точь пояснение в бложике у братьев-белорусов: okiseleva.blogspot.com.by/...2015/05/blog-post_25.html
И тем не менее на просторах иностранных сайтов есть и другая структура «шаги-ожидаемый результат-фактический результат»:
www.softwaretestinghelp.com/...to-write-good-bug-report
Что примечательно, я ни разу, ни от одного разработчика/аналитика/дизайнера/ПМ или архитектора не слышал подобных претензий, что структура бага у меня не правильная. Замечания о неточностях в шагах или результатах были, но ни разу по структуре. Интересно мнение всех причастных к разработке.
Такое беспрекословное наследование первой написанной букве в рунете напомнило анекдот Из того же материала
[UPD 06/09/2016] Прошла почти неделя с момента опубликования опроса, счётчик проголосовавших медленно перешагнул первую сотню, настало время зафиксировать промежуточные итоги.
Я периодически посматривал на графики и варианты «в чём разница» и «фактический результат» шли ноздря в ноздрю, поочерёдно обгоняя друг-друга. Но фото-финиш основывающийся на первой сотне таков:
— 43 опрошенных считает что очерёдность не важна
— 40 опрошенных считает что фактический результат должен быть первым
— 17 опрошенных считает что ожидаемый результат должен быть первым
В разрезе специализаций ответили — 58 тестировщик, 36 разработчик, 5 аналитиков и 1 дизайнер.
Я приведу ответы первых двух групп, поскольку они наиболее многочисленны и именно между ними наиболее часто осуществляется диалог посредством багрепорта. Казалось бы и подходы должны быть едиными, но нет...
Таким образом совпадение есть — по 19 процентов и тестировщиков и разработчиков считают что очерёдность не важна. Но есть и разница, тестировщиков, считающих что фактический результат должен быть первым — больше чем таких же разработчиков более чем в 2 раза. Если же брать тенденции по первому ожидаемому результату, то с учётом пропорций тренды совпадают — 12 и 5 ответивших соответственно
Таковы были тенденции первых ста ответивших. Но опрос не окончен, вполне возможно что с течением времени и картина может изменится.
Актуальные интерактивный результат голосования
В разрезе всех специализаций
38 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівОх ёлки... Мне кажется, что на такие проблемы обращают внимание те люди, которым больше нечего делать... Есть общий стиль, который принят та проекте. Плюс баг-репорт должен быть такой, чтобы программер его понимал.
Когда тестировщик начинает создавать проблемы на месте «глобально это должно быть первое» — сразу начинаю понимать программеров, которые не уважают «всё это куа, потому что они фигнёй занимаются», т.к. вот это «глобально это должно быть первое» — как раз и есть та самая фигня.
На мой взгляд, должен быть сначала ожидаемый.
После прочтения шагов человек должен увидеть как оно должно работать.
Аффтар, ты делаешь проблему из ничего. Я, например, люблю форматирование пробелами — но когда прихожу на новый проект то форматирую, как все и не создаю тему на доу: «Форматирование кода или почему тимлид мудак». Такие дела.
А теперь представь себе, что правил пока нет. И вот тут надо их задать, и так, чтобы было удобно «не только лишь всем» (tm).
Музыкой навеяло:
А если вернуться в наш грешный мир — монетка это худший метод, какой можно придумать в подобных случаях.
Достаточно часто ситуация ведения форка чужого проекта, и там менять стиль — себе дороже.
В... мнэээ... заметно атеистическом сообществе (IT) любое притязание решить спор случайным фактором или вмешательством высших сил будет принят как явное действие выигравшей стороны решить спор обманным методом в свою пользу. Такой себе «силлогизм» на обратном направлении причинно-следственной и временно́й связи, и его грубая логическая контркорректность ничего не меняет.
Есть несколько примеров, как решались конфликты стандартов. Казалось бы, лучше даже бросить монетку и решить, чей вариант из равных лучше. Но в итоге надёжнее всего оказывалось решение не сделать на пользу никому, выработав какой-то третий стандарт, под который обе стороны будут адаптироваться. Например, работа с сигналами процессов Unix в финальном решении POSIX, которое не совместимо ни с исходным BSD, ни с SysV. Это пример успеха. Или ATM — его48-байтовый payload это худшее, как можно было решить — в итоге стало хреново обеим сторонам — но никто не почувствовал себя ущемлённым больше оппонента.
(Вот если бы сообщество было религиозным — это был бы лучший метод.)
В выборе «или-или» лучше добиться перевеса одной стороны и склонить всех к её решению, или вообще ничего не решить, пока сами собой позиции не сдвинутся...
Должно быть так как все делают на вашем проекте.
Ожидаемый должен идти в отчёте раньше фактического. Обоснование: связность логики изложения. Некорректный фактический результат имеет смысл только в сравнении с ожидаемым, значит, ожидаемый должен быть к этому моменту определён, а также произведено всё остальное необходимое введение в контекст. Так как отчёт это текст (ну, пусть с картинками и т.п.), который читается в порядке сверху вниз — правильный порядок это который аккуратно постепенно, не сбивая порядка, вводит в суть проблемы.
В этом случае тестировщик может просто последовательно идти по отчёту, не дёргаясь между секциями.
Также тут важно то, что тестировщик должен проверить по своим данным адекватность ожидаемого результата: если описанное не соответствует его ожиданиям, значит, у репортера ошибка или где-то расхождение в документации. Если всё это происходит в давно знакомой тестировщику области, он может по диагонали пробежаться по секции ожидаемого, но пропускать её совсем крайне нежелательно.
Чтобы для последующего быстро найти секцию фактического результата, использовать стандартные методы индикации частей текста (заголовками, оглавлением).
Хз откуда вообще взялась логика что вначале должен быть ожидаемый результат. Долго вползал в айти, за плечами двое курсов по тестированию, один бесплатный в лидерах рынка, плюс старт в жесткой забюрократизированной до нельзя американской конторе, где было четкое следование процессам. Сейчас же наоборот, полная противоположность, никакой бюрократии. Но общее одно, в багрепортах вначале Actual, потом Expected. Причем сейчас ожидаемый даже можно не писать, никто ничего не скажет. А вот без Actual разработчик может и не понять в чем трабл, если саммари не ясно составлено. Так что не буду оригинален и присоединись к тем, кто советовал слушаться лида
Вообще по хорошему писать более важные вещи сначала. Что вот более важное? Ожидаемый результат и реально получившийся?
Ну допустим возьмем к примеру баг типа
— нажимаю на кнопку
— Приложение падает
нужен здесь вообще ожидаемый результат «а должно было работать»?
или
— нажимаю «звонить»
— а оно не звонит а пишет ошибка
нужен здесь ожидамемый результат «а должно было звонить»?
Само собой даже если половина багов написаны в одном порядке а другая по-другому с этим можно жить и даже не замечать никаких неудобств. С другой стороны человеку, который смотрит за тем, что же там пишут джуниоры в тикетах, и не только за тем что бы там были ожидаемый — полученный реультат но и за их порядоком — большой плюс. Бюрократия все таки любит порядок, а описание багов это бюрократия...
Ты бы по-детальней поинтересовался тем, что это такое гибкие методолгии, и в каком именно месте они гибкие. К «что хочу то и ворочу» эти гибкость никакого отношения не имеет. Если ты посмотишь детальнее на тот же надоевший всем скрам то там ограничений что можно делать а что нельзя существенно больше чем в среднем «собранном на коленке» рабочем процессе.Не хотелось бы бы спорить с вымышленными персонажами аж80-го уровня-то, но всё же Individuals and interactions over processes and tools and That is, while there is value in the items on the right, we value the items on the left more.
Вообще, если бы мне такое сказали (пиши это сначала а не это) я бы скорее всего просто сказал бы «ну ок» и так бы и сделал. Настолько оно мне кажется неважным. Если бы для меня это было важно, то максимум спросил бы «почему именно так» (именно так бы и спросил а не
именно для упрощения этих самых коммуникаций), если бы мне это казалось неправильным, я бы даже попробовал убедить. Но стоит ли такая фигня того что бы её обсуждать?Хотите укоренить мнение своего визави в его правоте — затейте с ним спор)
нет варианта «очередность не важна, главное — зафиксировать раз и навсегда»
About Me
I’m Vijay (The cool guy in the below picture), a dude from Pune, India
Вы приводите в доказательства БЛОГ ЧУВАКА из ИНДИИ )
А перед этим девушки из Беларуси и почему-то у вас не вызвало это такую бурю эмоций)
А вы точно в айти работаете ? ))
Правильнее всего следовать принятому на проекте шаблону, дабы не сбивать с толку коллег меняющимися местами Actual result и Expected result от отчёта к отчёту
О порядке результатов кучу раз подчеркивают на каждом шагу, в книгах, на курсах и т.д. К чему этот пост на доу я хз 🙄
Вот вам сказали как надо делать в команде:
Actual result: Статья на доу
Expected result: Вы должны были последовать совету старшего товарища
Это было самое начало проекта, команда вновь-набранная, общих соглашений ни внутри команды, ни тем более с разработчиками не проводилось. Никакой инфы никто никому не передавал. И телепаты были в отпуске...
У нас тоже телепаты в отпуске, поэтому объясните кто вас надоумил писать первым экспектэд резалт? ) это на каких специальных курсах проходят или может учебник какой?
Я же написал что лично мне не принципиально, меня интересует в каких книгах и на каких курсах учат этой беспрекословной и как правило слабо аргументированной обязательности? Вы не задумывались почему в багрепортинговых системах после поля описания не введена в обязательном порядке сразу отдельное поле — Фактический результат, и затем отдельным полем Ожидаемый результат? А ведь это сократило бы время на написание хотя бы этих слов — сразу пишешь в подготовленные поля и делов-то. Мне кажется это сделано преднамеренно для сохранения гибкости. Кроме того, я не исключаю, что моё убеждение о равнозначности этих пунктов, может быть ошибочным — для этого я и затеял опрос. Если большинство респондентов ответит что им удобнее/привычнее/лучше читать фактический результат первым — ну что ж, это значит, что большинству так удобнее/привычнее/лучше — ни больше, ни меньше. Но это не означает что это правильно, а это нет. Естественно, что если в моей команде разработчикам будет удобнее так — я буду делать так как им удобнее. Для этого и существует договорённость. Вся загвоздка в том — что мнение большинства не всегда бывает истинной — всё-таки она вертится!)
А его сожгли )
Сжечь его — он написал ожидаемый результат после описания шагов!
Сожгли не его, а Джордано Бруно, и вопреки пропаганде сожгли его за политическую а не научную деятельность
Я рад твоей общей эрудиции не только в области гибких методологий. Мне только осталось не ясно что вызвало противоречие в вышеизложенном диалоге? У нас имена там не упоминаются совсем — так кого не его сожгли-то?)))
Что же касается:
то наверное не все способны понять, исправляю что бы было доходчивей:
<sarcasm>Сжечь его — он написал ожидаемый результат после описания шагов!</sarcasm>
Вообще вопрос яйца выеденного не стоит, Это такая мелкая мелочь спорить о которой не имеет смысла... Вот что меня насторожило, так это твое отношение к этому.
Мы с Тарасом прекрасно поняли друг-друга не называя имён. Ты же вставил коммент, что дескать попутали — не того сожгли. Вот мне стало интересно — кого с кем попутали и кого сожгли вместо?
Да признаю, есть за мной грех, люблю я таким людям, стремящимся в самом пустячном вопросе сказать своё весомое последнее слово, подлить масла в огонь. С меня не убудит, а им приятно)Ну привыкай же ш блин, публичный форум. Тут иногда таки вставляют.
Галилео Галилей. Это тебе про то кого не сожгли..
Сказал в диспуте слово последним — молодец)
М... Кто? Я или Галилей?
Если Галилей, то он это сделал вне зачетного времени.
Если я, то иди в лес со своими подолами.
Оба молодцы, первый за то что не сожгли, второй за умение вестись на провокации. Ладно, ставь уже точку последним — обещаю больше не передёргивать, а то вижу начинаешь срываться на личности.
Не вполне: я привык получать багрепорт в определенном формате. Привык, чтобы после ’Steps to reproduce’ было ’Actual result’. Когда обрабатываешь десятки багрепортов в день (на этапе активной разработки это нормально), то уже не обращаешь внимание на названия разделов репорта, а ориентируешься на их порядок. А, получив репорт с измененным порядком разделов, первое время думаешь: «А в чем проблема, собственно?» Потом разбираешься, конечно, но это же время...