В субботу я проводил очередной тренинг “QA в Agile” и мы достаточно много времени уделили дискуссии на тему работы с дефектами в Agile. Мне кажется, что большая часть проблем в этой области возникает от непонимания конечной цели тестирования в Agile проекте и бюрократических устоев, которые достались по наследству и никуда не хотят уходить. Давайте разберемся…
Для начала, поговорим об определении дефекта. Не все так уж очевидно, как кажется на первый взгляд. Я для себя выделяю 4 типа “дефектов”: недочет, проблема, дефект и доработка. Давайте начнем с самого простого – с доработки. Представим себе итерацию в две недели и хорошую Scrum команду, которая стремится брать на себя реалистичный объем работ и выполнять его до конца итерации, предоставляя в результате рабочий продукт заказчику. Команда в первый день итерации пришла на планирование, все пользовательские истории были в деталях обсуждены, сформулированы приемочные критерии, оговорены приемочные тесты, было задано много вопросов от тестировщиков и разработчиков. Все ушли с четким пониманием, что надо делать на этом коротком интервале времени.
И вот идет уже третий день итерации и разработчики передают на тестирование первую пользовательскую историю. Тестировщик садиться ее тестировать и в процессе тестирования до него доходит – существует сценарий, о котором все забыли на планировании. Как вы думаете, работает он или нет? Естественно нет! Потому что о нем никто не задумывался в момент реализации. Если он работает, то это скорее везение, чем нормальный ход событий. Можно ли назвать это дефектом? Конечно нет! Иначе можно назвать дефектом и любую другую функциональность, о которой никто не задумывался. Это доработка, которая может вылиться чуть ли не в отдельную пользовательскую историю.
Нужно ли заносить доработку в баг-трекер? Ни в коем случае! Это чревато проваленными итерациями. Тестировщик не в праве решать насколько важная это доработка и стоит ли она того, чтобы ее непременно сделали в этой итерации. Такого рода решение может принимать только представитель бизнеса: заказчик, менеджер продукта, Product Owner. Добавление доработки в баг-трекер может привести к раздуванию сроков работы над задачами в итерации, что и приведет к провалу. Вместо этого нужно сразу же сообщить стороне бизнеса о доработке и отправить ее в виде запроса в Backlog. Дальше она может быть добавлена в следующую итерацию, отклонена, понижена в приоритете или же в срочном порядке добавлена в итерацию (естественно, с удалением другой работы из этой итерации).
Теперь представим, что тестировщик находит сценарий, который работает не так, как договаривались на планировании. Является ли это дефектом? Тоже нет! Ведь мы еще не закончили официально работать над пользовательской историей – она не дошла до состояния “ГОТОВО” и ее не показали заказчику. Значит это временная недочет, а не дефект. Недоработки не нужно заносить в баг-трекер. Ведь в этом случае будет уходить много усилий на то, что в любом случае нужно исправлять как можно скорее (мы же хотим довести историю до конца). Тут стоит использовать легковесные средства: личное общение с разработчиком, отметку на доске задач о наличии недочета, сообщение в скайп, комментарии в переоткрытую задачу, автоматизированный скрипт для демонстрации недочета и т.д. Чем короче будет цикл обратной связи, тем быстрее недочеты будут устранены.
А что, если сценарий не из новых историй, а из реализованных ранее? Поздравляем! Вот тут вы действительно нашли дефект! Его обязательно нужно занести в баг-трекер и сообщить о нем стороне бизнеса для принятия решения о его устранении. Дальше с ним может случиться такая же история как с доработкой. Попытки тестировщиков продавить дефект на исправление в этой же итерации могут быть чреваты провалом. Причина одна – незапланированная работа, которая может отнять много времени.
Остался только один тип “дефекта” – проблема. Выглядит он следующим образом: тестировщик в ходе тестирования решил попробовать что-то нестандартное, например, ввел очень много символов в текстовое поле или быстро нажал кнопку обновления страницы 10 раз подряд. В результате приложение повело себя некорректно. Почему же это не дефект? Потому что в большая часть из этих сценариев никогда не будет повторена пользователем или заказчиком. А значит, никак не повлияет на работу продукта. Мы, конечно же, говорим не о примерах, где все данные пропадают из приложения в результате действий тестировщика. 😉
Но проблемы подобного рода также не стоит заводить в баг-трекере. Вместо этого их стоит обсуждать и вырождать в нефункциональные требования или чеклисты разработчиков. В приведенном мной примере с текстовым полем в нефункциональные требования уйдет “валидация длин всех текстовых полей”, а в чеклист разработчику “для всех форм на странице нужно не забывать делать валидацию на длину поля”. Добавление же в баг-трекер не принесет пользы. Маловероятно, что этим будут заниматься в скором времени, но при этом будет захламляться баг-трекер. Значит, станет тяжелее найти в нем нужную информацию и придется время от времени проверять ее валидность. Зачем тратить время на такие глупости? 🙂 Но, если очень хочется, можно устроить где-то в баг-трекере склад подобных проблем “на будущее”. Лучше, конечно, добавить автотест, который будет показывать в каком состоянии находится данная проблема.
А вы как работаете с “дефектами” у себя в проекте? И когда используете баг-трекер? Делитесь в комментариях!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Вы просто напрасно потратили время и деньги заказчика. Не стоит пытаться выдать себя за эксперта предметной области. Ваша цель – давать рекомендации, а не выбивать из кого-то что-то. Бизнес-решения должны принимать те, кто платит деньги.
Вы меня не поняли – я не призываю скрывать проблемы и дефекты от разработчиков или заказчика. Просто в адекватной команде их можно закрыть локально малыми силами, а не подымать лишний “шум”. Полный цикл дефекта стоит проходить, если у вас проблемная команда: “отдел” тестирования, удаленная команда разработчиков, разница во времени и т.д. В нормальной Agile команде все может быть на порядок проще…
База знаний полезна и важна, но существуют куда более приятные инструменты для ее ведения. Например wiki продукта, причем хорошо структурированные.
Вы так и не поняли для чего я ввел эту классификацию. Попробуйте перечитать статью спокойно еще раз. 🙂
Как вы можете утверждать, то тут баг, если вы не знаете требований. :))) А требования заключаются в том, чтобы давать возможность вносить небольшие комментарии, а не на несколько страниц. Для этой цели поле подходит вполне. И да, еще нет возможности импорта из файла, сохранения в PDF, возможности вставлять картинки и прикреплять файлы… Потому что это поле для небольших комментариев.
не согласен по всем пунктам
а) любой из 4-х моментов может быть дефектом, а может и не быть, причём вот даже если мы находим ошибку, которая воспроизводится во всех версиях продукта (ну не нашли её, либо тестировщики туда не смотрели вообще, либо проявлялась при определённых условиях, которые не были покрыты тестами, а тут тестировщик новый пришёл и тыкнул) – её могут классифицировать как “нам пофиг, всегда была и никто не требовал исправления, можем и не фиксить”.
б) даже “реквест” может быть багом, даже если в спеке написано не так. Дима вон не даст соврать – я местами тупо выбивал из кастомеров требование соответствовать, например, Microsoft UI Guidelines, которые, по мнению заказчика, не критичны ибо “врачи на интерфейс не смотрят”.
в) тестировщик должен быть экспертом-аналитиком программного обеспечения, в первую очередь. Он может разбираться в программировании, автоматизации, вебе и любой другой фигне, но главное – он должен разбираться в софте, понимать зачем он нужен, что делает и кто будет его пользовать и зачем. С веб-софтом ситуация сложнее ибо там не всегда все варианты просчитаешь, но вот по факту: тестировщик Майкрософт, который молча кивнул на убирание кнопки “вверх” из проводника – лох, даже если это было As Designed, тот факт, что кнопку “вверх” вернули подтверждает это.
4) если тестировщик считает, что “это баг” – это нужно писать. конечно он должен проанализировать, убедиться, что не дубликат, в некоторых случаях повторить воспроизводимость, можно уточнить дева или проконсультироваться с другими тестировщиками, что гоняли этот функционал, но в целом финальное решение “баг или не баг” должно быть всегда в сторону “баг”. В любом случае в процессе кто-то ОБЯЗАН ревьювить баги и принимать решения. Продукт овнер, дев лид, девелопер на которого заассайнили, но я своим всем (особенно новичкам) говорю всегда “не бойтесь статуса “не баг” или “так задумано” – эти статусы также важны для работы, благодаря им чистятся кейсы, уточняются текноты, улучшается документация и т.д.)
5) по “имейлам”: вот свежайшая ситуация – 6 лет назад было общение на стему спец-реквеста от одного клиента кастомеров, очень важного и крупного, там я предоставил специфическое решение по вопросам установки/удаления продукта через актив директори. Ессесно решение выслали, оно только для них, ни в какие текноты не попало. Продукт для этого клиента поддерживается, но новую версию они не покупают, точнее они купили один апдейт и дальше им не нужно (у мед учереждений США свои заморочки), таких клиентов несколько штук. И вот где-то полгода назад оказалось, что это же решение нужно другому кастомеру. Ессесно спросили меня, я поднял переписку, потратив на это пару минут и выслал солюшен с полным обоснованием, подводными камнями и вариантами решений без этого солюшена (имхо более правильными, тоже та ещё история). Если бы у меня его не было бы – всё это заняло бы дохера времени снова, чтобы написать, описать, уточнить. Таких ситуаций, особенно на крупных продуктах для специфических клиентов – у меня очень много. Чья это проблема – неважно, важно, что даже если база знаний по деталям дефектов и каким-то проблемам есть и она в мыле, в багах – это отлично. Если её нет – жопа. Я вот очень хочу посмотреть на организацию процесса в Майкрософт, которые саппортят паралельно кучу разных ОСей и с разными и с одинаковыми багами, с разными клиентами, интересно, как у них там 😉
И кстати, в данном поле ввода баг: оно маленькое и писать в него такой пост визуально неудобно. При этом использование в Опере расширения Textarea resizer приводит к тому, что границы поля можно вывести вправо куда угодно, при этом ширина сайта не увеличится автоматически (хотя на форумах и других сайтах – всё ок, ведёшь границу вправо, увёл слишком далеко – сайт растянулся), видимо жёстко зафиксирована максимальная ширина (если тянуть вниз – всё будет ок), после чего невозможно без рефреша страницы вернуть форму в нормальный вид, причём отрубается скролл, то есть ни мышкой, ни клавой, курсор ессесно заводится в невидимое пространство при печатании). Ну и на разрешении 1920х1200 сайт выглядит “узковатенько” )))
В продолжение нашего разговора, очень рекомендую посмотреть вот это гениальное выступление на тему настоящего тестирования в Agile команде: http://www.softwaretestingmagazine.com/videos/software-testing-lessons-from-extreme-programmers/. В самом конце там и про баги будет разговор. 🙂
Золотые слова, Николай
Тратьте и дальше свое время (= деньги заказчика) на эту очень важную работу. Описывайте “баги” во всех деталях, собирайте скриншоты и логи. Как можно больше используйте почту! Это надежный и супер-быстрый инструмент. Да и не пропадет ничего. Чуть что будете виноваты не вы… Я же вас не заставляю меняться. Тем более, если вы не хотите. 🙂
Во-первых, там в манифесте приписка есть, что бы не отрицаем важности того что справа “over processes and tools”, но ценим больше то, что слева “Individuals and interactions”.
Во-вторых, По скайпу и имейлу мы общаемся. И некоторые вопросы можно решить очень быстро. По крайней мере можно быстрее добится общего понимания важности проблемы. Но, потом, для более серьезных проблем, не таких как “поправить css или помеять слово lock на locked” все равно должен быть заведен баг. Чтобы его можно было потом обсудить либо позже, либо отложить, так как в данный момент разработчик заенимается другой не менее важной работой.
По поводу личного планирования задач, ну да я вот использую и блокноты и календари, и клейкие листочки, и имейлы в специальной папке. А вот тот разработчик, который ответственен за фикс проблемы — это не использует и логи в скайпе иногда теряет. А в багтрекере он никогда ничего не теряет. И может в любой момент поднять переписку и аттачменты в баге, чтобы войти в контекст проблемы.
Не надо иметь идеальную память – достаточно иметь Skype и блокнот с ручкой на столе. А еще лучше использовать что-то для личного планирования задач. Ну это мы совсем об идеальном разработчике? #trollface
Agile команда сидит вместе или же плотно общается на протяжении дня с использованием публичных каналов: Skype, видео. Если команда распределена, со сдвигом во времени и общается по почте – она не может называться Agile. Читайте Agile принципы, которым это противоречит. #trollface
А по поводу того, что у вас не работает – сразу видно, что вы соблюдаете принцип “Individuals and interactions over processes and tools”. Только interactions идут через инструменты и процессы… #trollface
Начиная с комментария #18, давайте поставим ударение на контексте, в котором будут работать что “недочеты, доработки проблемы” репортить не нужно.
На мой взгляд, их репортить не нужно только в случае идеальной команды, когда разработчики в том числе обладают идеальной памятью, сильно замотивированы и без проблем общаются друг с другом. Ну, тогда да, возможно все описанное выше и будет работать.
Но, в случае аутсорса и распределенной команды, когда все таки есть барьер в общении, в том числе связаный с разницей по времени, все описаное выше является багом, который должен быть зарепорчен.
Но, и в этой ситуации такой процесс можно назвать Гибким, потому что в целом вся команда разделяет и следует ценностям Agile.
А недоработка, “недочет, проблема — это не баг и его репортить не нужно” — это не работает, по крайней мере в контексте моего проекта.
Вам никто не говорил, что вы склонны к максимализму? Пару комментариев назад вы предлагали сравнивать Agile процесс на корректность с Agile манифестом. Вот вам откуда берется мое утверждение:
Working software over comprehensive documentation
А отсюда берутся:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Working software is the primary measure of progress.
Так что из ваших же слов следует, что команда, которая этому не соответствует – не Agile команда. И при чем тут “идеальная” команда или “идеальный” Agile?
>> . Я веду речь про нормальную Agile команду, где люди
>> понимают свою главную цель – делать качественный
>> продукт.
Вот как раз слов про “идеальную Agile команду в вакууме” в начале поста и небыло.
Ну, конечно, если взять идеальную клманду, в которой каждый участник понимает, что его цель — делать качественный продукт. Нет даже не продукт, а Продукт. На 100% замотивирован тем, что он работает с Продуктом и делает его лучше. А сам процесс сделан от корки до корки лучших практик Agile…
Ну, тогда да. Все вышеописанное будет работать в данном контексте.
Только где же взять такую идеальную Agile команду?
Вот бы хоть на какую-нибудь статистику глянуть, сколько таких команд реально в мире существует, а сколько считают себя такими идеальными.
Очень правильно сказано! Но, вернитесь к началу статьи. Я веду речь про нормальную Agile команду, где люди понимают свою главную цель – делать качественный продукт. 🙂
Разработчик разработчику рознь. Некоторые девелоперы готовы даже недочеты исправлять “на месте”, при первом обращении тестировщика. Тогда, когда другие – даже полностью нерабочий функционал, который задеплоили и передали заказчику пол года назад, считают “доработкой”. А оформление серьезных эксепшинов с высоким приоритетом приводит к долгому и мучительному исправлению, с ругательствами, недовольством и огромным количеством претензий (мол, как ты мог завести дефект “на меня”, я же мега гуру). А в конечном итоге, после исправления дефект переводится в статус “не воспроизводится”))).
Вот для таких кодеров часто полезно оформлять в баг-трекер абсолютно все: доработка, недочет, дефект, проблема, руководствуясь принципом: “Лучше всего дурь из головы выбивается неоднократным наступлением на грабли.”
Ну вот это как раз то, про что я говорил. Каждый свой дибиловатый рецепт выдумывает, который вкусен только ему и называет это солянкой. :)))
Согласен. Я стремлюсь к тому, чтобы команда готовила солянку по рецепту. Только тогда она получается правильная и вкусная.
На этом сайте можно найти более 75 разных рецептов солянки.
http://www.povarenok.ru/recipes/category/46/~1/
#сарказм, #trollface
Тут скорее также как и в ресторане – есть солянка по рецепту, а есть месиво, которую тоже выдают за солянку. И вы ее едите, потому что уже заплатили и кушать хочется. А многие ходят туда, где солянка вкусная и правильная. Такие места есть… 😉
Спасибо за вопрос! Постараюсь пояснить. Вы планировали фичу оформления заказа. Обсудили все детали, все сделали как договорено. А потом в процессе тестирования вы наткнулись на то, что при оформлении нету проверки товаров на наличие на складе (новый сервис, который недавно добавили и о нем просто забыли). Соответственно, есть риск, что после заказа сложится ситуация, когда товаров всем не хватит и надо будет пользователя уведомлять. У вас есть выбор – как “честный” тестировщик сразу напасть на программиста и надавить на его “здравый смысл”. Это займет у него еще один день разработки и что-то другое не успеется. Альтернатива очень простая – сообщить заказчику и добавить эту доработку в самый топ бэклога. А если останется время в итерации, то ее можно взять и сделать. А может заказчик и не посчитает такую доработку важной, потому что товары поставляются каждый день и исключение случится чисто теоретически, с чем он сможет жить дальше. Надеюсь, стало понятно, что я имел ввиду. 🙂
Мне вообще интересно, существуют ли команды, работающие на “чистом” Agile? Складывается впечатление что в итоге на каждом проекте получается своя “сборная солянка”.
Объясните пожалуйста, на счёт “доработки”. Ситуация : “Существует сценарий, о котором никто не задумывался и он – не работает. ”
В смысле:
Я прохожу по фиче каким-то хитрым сценарием и у меня валится эксэпшен (например).. Это не баг, просто никто не подумал, что можно так пройтись? Давайте ничего с этим не делать?
Или вы имеете ввиду, что просто когда использовали фичу, возникла мысль, что можно ПРИКРУТИТЬ новую функцинальность, кнопАчку и всё такое? Типа Enhanced Request – тогда , можно и не заносить..
Разъясните плиз 😉
Да. Если ничего не работает – выбрасываем все.
Но, это не в том смысле, что типа:
– У меня компьютер не работает!
– А вы его в розетку включили?
– Ой, а разве нужно было?
Нет, сначала нужно попробовать. Сделать все с верой в то, что оно таки заработает. И если таки не заработает – то выбросить.
Но, не в том смысле, что Скрам не работает – давайте его выбросим. А в том, что: ну окей. Дейли стендапы не работают как надо. Мы можем без них обойтись и заменить чем-то?
– Да, можем. И без них можно собратся когда нужно и все обсудить.
– Тогда выбрасываем.
– Выбросили. Не, все таки стало хуже. Давайте вернем, но немного видоизменим…
А методология у нас – солянка сборная, которая все же работает (насколько эффективно с методологией XYZ сказать не могу, потому что не было возможности сравнить)
Для меня все что работает в контексте данного проекта – это правильно. Все что не работает или работает плохо – нужно выбросить или видоизменить.
Тут снова вы немного перебарщиваете. А если ничего не работает, то все выбрасываем? Здравый смысл у всех разный. Да и сравнивал я бы процесс на Agile-ность не по манифесту, а по 12-ти Agile принципам: http://agilemanifesto.org/principles.html. Манифест чересчур философский, но до тех же принципов дойти можно. По поводу тестирования – нужно смотреть на конкретную методологию, которую вы выбрали для себя. Например, в XP обязательны автоматизированные приемочные тесты, которые получаются после планирования. В Scrum говорится о полном понимании и разборе требований на планировании.
Уточню «про никто не», это скорее относятся к одному взятому проекту, чем ко всем проектам в целом. За все проекты, я говорить не могу, потому как на всех не был ?
Для меня «Agile» – это тот процесс, который не противоречат Agile манифесту (http://agilemanifesto.org/).
Когда должно делаться тестирование: до, после или вместо разработки – это уже до думки и выводы отдельных людей. Я не говорю, что эти выводы не правильные, но я знаю, что работать это будет не везде.
И для меня синоним аджайл – это здравый смысл. Что работает – берем, что не работает – выбрасываем.
Ой-ой-ой! Это вы зря в конце про “никто не…” – я знаю очень много команд, где юнит-тесты пишут и вики ведут. Да и требования в Agile подходах надо “тестировать” на этапах груминга и планирования, а не когда задача уже сделана. В том, что вы говорите, нет проблемы. Просто не называйте это Agile, тогда это “такой себе ваш процесс”. 😉 Да и зависит он непосредственно от вас, а не от меня или еще кого-то.
1. Я сам за то, чтобы тестировщик находился недалеко от разработчика, и чтобы вместе они сконцентрировались на разработке одной фичи. В то время, как разработчик пишет код – тестировщик сконцентрирован только на там, как он будет этот код тестировать. Каждому разработчику – по тестировщику. Или по два, как в Microsoft.
Но, в других ситуациях, как тестировщику определить что фича закончена и ее можно тестировать? В таком случае разработчик должен сказать, что он завершил фичу «Dev Done» и она передана на тестирование. После того, как тестировщик скажет, что завершил тестировани – тогда Done для фичи в целом.
2. Баг-треккер – может быть и не лучшее место для требований, но на тех проектах где я работал – мы использовали багтреккер для хранения багов и предложений (Enhancement/Request), которые сначала были багами, а потом превращались в требования.
3. Значит, требования были неверными. В требованиях тоже полно багов, и тестирование начинается именно с тестирования требований. В таком случае нужно завести баг, что требования противоречат здравому смыслу. Значит требования нужно будет изменить (ведь это Agile, мы привыкли к тому, что требования не точные и часто меняются :).
Я не настаиваю на том, что баг трекер – это самое лучшее место для требований. Но, для многих других команд так и есть. Просто потому, что все считают, что писать юнит тесты – это круто, но их никто не пишет, потому что считают, что проектная вики – это круто, но заниматься ей никто не хочет. Просто потому, что так сложилось годами – и все уже привыкли к баг трекеру, как источнику знаний. Потому, что мы знаем, что этот подход – работает. А то, что какой-либо другой подход лучше и эффективней – так это еще доказать нужно.
1. Функциональность не может быть уже “Done”, если она не прошла тестирование. Это анти-Agile. 😉
2. Не доделана функциональность может быть по как минимум двум причинам: ее не предполагали или по вине разработчика. В первом случае это пропущенное требование и к баг-трекеру это отношения не имеет. Во втором – это недочет, который обязан быть исправлен в итерации, а иначе где тот пресловутый “DONE”???
3. Про красную кнопку – это не баг. Так было задумано по дизайну, исходя из требований. Не факт, что измененный цвет не вызовет еще больших проблем. Причем, я же не говорю, что такие проблемы не надо анализировать и делать выводы. Вот только в баг-трекере им не место. Мой посыл – из такого рода проблем надо накапливать базу знаний для команды, а баг-трекер – не самое удачное место для такой базы знаний.
И тут я хотел категорически поспорить со всем, кроме определения дефекта – но воздержался, потому что на каждом проекте ситуация разная, используются разные подходы и инструменты, виденье и процесс разработки.
Поэтому тут я изложу разницу между своей практикой и практикой, описанной в этой статье.
Во-первых, читая пост я споткнулся о слово «доработка». Для меня доработка – это процесс исправления недоделанной функциональности разработчиками, а для меня, как для тестировщика – такого статуса для дефекта не существует. Не обсудили, не дописали – это все недочет. Вопрос, стоит ли заносить его в багтрекер?
Если функциональность уже “Done” (например, 15 минут назад) – то да, стоит обязательно. Просто потому, что сейчас разработчик переключился на другую фичу и неизвестно когда он вернется назад.
Если функциональность еще «в разработке», то, скорее всего не стоит. Если уж очень хочется, то можно написать email или сказать устно, если разработчик сидит рядом. Или проапдейтать чеклист, о котором известно также разработчику. Либо создать сценарий, который бы тестировал эту ситуацию. Но, написать баг можно действительно только после того, как кусок работы, в котором есть эта ошибка действительно помечен как «завершен».
То, что подразумевается под проблемой – это однозначно баг. Когда мы говорим, что нужна формочка, которая добавляет новый товар в интернет магазине, то мы подразумеваем что:
Поле с ценой должно валидироваться, а потому что человек случайно может опечататься. Например, ввести «1000э» (Ой, случайно нажал на «э», когда нажимал на Enter)
После с именем товара не должно превышать длину поля в Базе данный, чтобы товар
«Игрушка детская, Медвежонок голландской фирмы Нахертенлихт»
не обрезался до:
«Игрушка детская, Медвежонок голландской фирмы Нахер»
Ну, во что бы превратился планинг-миттинг, если бы мы обсуждали каждую техническую деталь:
1. И текстовое поле должно отображать данные на веб-странице
2. И текстовое поле должно отображать данные на веб-странице, взятые из базы данных, а не как в прошлый раз
3. И текстовое поле должно отображать данные на веб-странице, взятые из базы данных, для корректного товара, а не как в прошлый раз
4. И текстовое поле должно сохранятся при отправке страницы, а не как в прошлый раз
5. И текстовое поле должно валидировать данные при сохранении, а не как в прошлый раз
6. И текстовое поле должно сохранять данные для корректного товара, а не как в прошлый раз
….
Мы не оговариваем эти технические детали, потому что качественная техническая реализация – это само собой разумеющееся дело.
И это не глупости. Если есть проблема – то она должна быть зарепорчена. Да, можно и нужно организовать такой склад проблем в багтрекере, и назвать эго Бэклогом.
Но, опять же, стоит сказать, что для каждого проекта есть техники и правила работы, которые показали свою эффективность. Методики, описанные в данном посте подходят для одних команд, но совсем не подходят для других, которые работают в разных контекстах.
Ведь очень важно и то, над каким приложением работает команда. Если это команда Твиттера – то любой баг важен. Любая недоработка должна быть зарепорчена. «Мне неудобно твитить» – это очень серьезный баг. «Я не различаю цвета, и не могу найти красную кнопку на зеленом фоне» – это серьезный баг. JAWS не различает элементы сайта на сайте налоговой США? – это очень серьезный баг, нарушение закона, Section 508.
Если это Интерпрайз приложение – то на некоторые баги в интерфейсе, можно просто забить.
Если известно, что с админкой будут работать только высококвалифицированные люди, которые никогда не ошибаются – то и на валидацию можно забить.
Все зависит от контекста, в котором работает команда.
Но при этом беклог тоже может физически вестись в том же бегтрекере (JIRA + Greenhopper например). И в этом случае туда можно добавлять доработки. При этом важно, чтобы они не были занесены как баги или на текущую итерацию 🙂
Ну вы как раз попадаете под определение проекта с бюрократическим прошлым. 😉 Никто не задумывается, сколько лишнего времени тратится тестировщиками на подобную работу. Да и Agile такую команду, где все находятся далеко друг от друга, тяжеловато назвать. Поэтому мужайтесь!
И уже привыкнув к такой системе, честно говоря для меня дико звучат слова “не стоит заводить в баг-трекере” 🙂
Мы репортим в багтрекер абсолютно все. Даже вопросы с уточнениями по функционалу. Нас просят заводить все дефекты даже не взирая на то, что некоторые из них получают статус Rejected или Will not fix. Возможно особенность в том, что команда разбита на части и бизнес-аналитики, разработчики и тестировщики находятся далеко друг от друга.