В замешательстве, какую Severity ставить багу
#1
Отправлено 17 августа 2012 - 09:39
Добрый день.
Тестированием я занималась не так долго и с тех пор много воды утекло, все это время (5 лет) я занималась другими вещами. Конечно, что-то забыла, сейчас теорию почитала - вспомнила.
Хочу вернуться в эту область сейчас. На данный момент при тестировании приложения (тестовое задание) столкнулась со следующей проблемой:
Приложение позволяет создавать и редактировать некий каталог, имеющий иерархическую структуру. Корневой элемент каталога имеет параметр - полный путь к каталогу (вводится в текстовое поле). Остальные элементы имеют параметры (вводятся в текстовые поля), соответствующие именам папок в файловой системе (указано в инструкции пользователя, других документов, описывающих требования к приложению, нет).
Приложение сохраняет каталог в виде xml-файла. Что с этим файлом на практике должно происходить дальше - создаются ли на его основе каталоги в файловой системе или нет, неизвестно (ответ на этот вопрос я получить не имею возможности).
Известно, что полный путь к каталогу должен указывать на существующую директорию, известно, что параметры элементов, соответствующие именам папок в файловой системе, должны удовлетворять требованиям, предъявляемым к именам папок в Windows (выяснено уточняющими вопросами).
В ходе выполнения тест-кейсов обнаружилось, что поле пути может иметь неверный формат, указывать на несуществующую папку, не обрабатывает конечные и начальные пробелы, допускает использование в именах папок запрещенных символов и т.п.
С одной стороны, если в дальнейшем создаваемый xml файл используется для создания каталогов файловой системы, ошибки такого рода являются критическими. С другой стороны, в рамках работы с текущим приложением они не вызывают сбоев и не приводят к потере данных, и являются просто функциональными багами, т.к. не выполняется требование.
Какую Severity лучше поставить в данном случае?
Заранее спасибо.
#2
Отправлено 17 августа 2012 - 09:53
#3
Отправлено 17 августа 2012 - 10:18
#4
Отправлено 22 августа 2012 - 00:07
#6
Отправлено 22 августа 2012 - 21:24
Я сама пользуюсь (по давней привычке) довольно "мелкодробленным" шагом - 6 вариаций, от блокирующего до косметического дефекта. В условиях, когда и баг-репорт, и отчет по тестированию пишутся "в свободной форме" (то, что я услышала, а, точнее, увидела в ответе на свой вопрос касательно принятого оформления), я выкрутилась, дополнив баг-репорт legend с указанием, какая важность в каких случаях используется.Tagira, я понял вашу ситуацию, но вы не описали, как вы (сами или согласно доведённой до вашего сведения инструкции) дифференцируете уровни критичности, а самое главное - что вас беспокоит? Вы, как тестировщик, подробно описали проблему и риски. Допустим, менеджер проекта рассматривает следующие возможные уровни severity: 1-"смертельно"; 2-"опасно"; 3-"возможны проблемы"; 4-"криво". Ну выберите вы 1 или 2 или 3 и что? Самое главное, чтобы он по отношению к вам не видел ни паникёра и ни неадекватного специалиста в сравнении с severities, заданных вами для других багов. Я, как тестер, указал бы 2, а какой Priority задаст менеджер и исходя из каких соображений вас уже не касается, - вы молодец, сделали своё дело, вам спасибо. Судить о решении менеджера будут другие люди, которые, если потребуется, обратятся и выслушают ваше мнение.
Да, именно так в итоге и сделала. Возможно, это несколько неправильно с т.з. оформления, но в комментариях в подобным ошибкам я указывала, что в случае, если сформированный xml-документ будет использоваться для создания файлового каталога, баг имел бы другую важность, и почему.При выполнении тестового задания самое главное не то как вы проставите северити, а то как вы объясните почему вы поставили такую северити.
Выбираете систему оценок и оцениваете найденные баги, в каких-то местах объясняете почему такая оценка.
Хочу выразить огромную благодарность всем без исключения откликнувшимся.
#7
Отправлено 23 августа 2012 - 13:18
1) Немного критики в ваш адрес: не нравится ни ваша нерешительность, ни терминология типа "выкрутилась"... Похоже на проблемы с рабочей атмосферой, которые влекут параноидальность, перестраховку в мелочах. Уверяю вас, по большому счёту никто (кому по-настоящему есть, чем заниматься) на severity особо не смотрит, если только оно не волшебное. Главное, чтобы чётко и лаконично было описание бага, а не Баллада о баге.
2) Не понятно, почему Лично вы пользуетесь мелко дробленным шагом из 6 вариаций, что это за ноу-хао в процессе обеспечения качества со свободной формой багрепорта? Разве в багтрекере для выбора severity не используется dropdown, предустановленный менеджером с пояснением системы оценок?
Совет: не погружайтесь в нездоровый формализм, а например, добейтесь/убедите менеджера, что для качества программного продукта в части данной проблемной функциональности при создании xml к нему требуется xsd-описание для его автоматической валидации, т.е. девелоперы должны разработать xsd и включить в решение. А вам, как специалисту по "белому ящику", в последствие будет необходимо проверить хорошо ли написана xsd, чтобы надёжно защищать xml от ошибок.
#8
Отправлено 23 августа 2012 - 22:16
Подождите благодарить...
1) Немного критики в ваш адрес: не нравится ни ваша нерешительность, ни терминология типа "выкрутилась"... Похоже на проблемы с рабочей атмосферой, которые влекут параноидальность, перестраховку в мелочах. Уверяю вас, по большому счёту никто (кому по-настоящему есть, чем заниматься) на severity особо не смотрит, если только оно не волшебное. Главное, чтобы чётко и лаконично было описание бага, а не Баллада о баге.
2) Не понятно, почему Лично вы пользуетесь мелко дробленным шагом из 6 вариаций, что это за ноу-хао в процессе обеспечения качества со свободной формой багрепорта? Разве в багтрекере для выбора severity не используется dropdown, предустановленный менеджером с пояснением системы оценок?
Совет: не погружайтесь в нездоровый формализм, а например, добейтесь/убедите менеджера, что для качества программного продукта в части данной проблемной функциональности при создании xml к нему требуется xsd-описание для его автоматической валидации, т.е. девелоперы должны разработать xsd и включить в решение. А вам, как специалисту по "белому ящику", в последствие будет необходимо проверить хорошо ли написана xsd, чтобы надёжно защищать xml от ошибок.
Если вы внимательно читали мое первое сообщение, то должны были увидеть, что я выполняла тестовое задание. Ни о какой системе баг-треккинга в данном варианте речи не шло. И уж если на то пошло, то 6 вариаций - это не мое know-how; severities в баг-треккере, который мы использовали на моем предыдущем месте работы, были настроены именно так. И именно в виду отсутствия у меня столь вожделенного dropdown-а я "выкрутилась" (как бы вам ни нравилось данное слово - а как иначе назвать этакие "костыли"?), используя legend - во избежание двусмысленности.
Разумеется, перед тем, как оформлять тестовое задание, я поинтересовалась в компании, для которой это задание выполнялось, в какой форме они хотят получить от меня ответ и что он должен в себя включать. К моему большому сожалению, я не смогла получить на этот вопрос более внятного ответа, нежели тот, что был приведен выше (как, к слову и на некоторые другие, да хотя бы вот на тот же вопрос, каким образом будет использоваться (и будет ли) созданный приложением xml-документ). Я в общем и целом имею убеждение, что, принимая решение о возможности предложить претенденту вакантную должность, человек, ответственный за принятие этого решения, будет руководствоваться не только и не столько количеством обнаруженных багов, но и их качеством, а так же адекватностью оценки важности бага, плюс оформлением. Исходя из этих убеждений, я склонна делать все настолько хорошо (это, впрочем, касается не только выполнения тестовых заданий, я вообще перфекционист по жизни), насколько мне это позволяет время, если я действительно заинтересована в работе именно в этой компании (а я заинтересована).
В свете всего, сказанного выше, позвольте мне применительно к данному конкретному случаю счесть некорректными ни ваше предположение о проблемах с рабочей атмосферой, ни ваш совет добиться чего-либо от менеджера.
Ну и вернусь к первой строке вашего сообщения. Я не вижу ничего дурного в том, чтобы поблагодарить всех, кто потратил свое время, отвечая ли на мой вопрос, выясняя ли обстоятельства, критикуя ли меня. Такова уж моя натура - я порой до зубовного скрежета корректна и вежлива ;) А потому вам - спасибо!(еще раз)
#9
Отправлено 24 августа 2012 - 00:17
Подождите говорить спасибо......я склонна делать все настолько хорошо... до зубовного скрежета...
Вы не прокомментировали совет быть лаконичной, не писать баллады.
И ещё немного критики: хвалите себя молча, а то слушать про ваш зубовный скрежет неприятно.
Если ближе к делу, то багрепорт - это "в жизни" хорошо шаблонизированный артефакт, и ваши фантазии о его оформлении ничего не стоят, а правильно оценивать критичность баги... по-моему для этого ума совсем не надо, по сравнению с прочими необходимыми тестерскими способностями и умениями, но это уже вам решать, с какой сильной стороны показать себя работодателю.
#10
Отправлено 24 августа 2012 - 07:34
Подождите говорить спасибо...
Вы не прокомментировали совет быть лаконичной, не писать баллады.
И ещё немного критики: хвалите себя молча, а то слушать про ваш зубовный скрежет неприятно.
Если ближе к делу, то багрепорт - это "в жизни" хорошо шаблонизированный артефакт, и ваши фантазии о его оформлении ничего не стоят, а правильно оценивать критичность баги... по-моему для этого ума совсем не надо, по сравнению с прочими необходимыми тестерскими способностями и умениями, но это уже вам решать, с какой сильной стороны показать себя работодателю.
Ну вы уж прям совсем придираетесь к девушке.
С каких пор говорить "спасибо" - плохо?
Автор, не слушайте его! Говорить "спасибо" очень полезно и очень приятно. В частности, своим коллегам, когда они отвечают на ваши вопросы - поддерживайте дружелюбную атмосферу на работе
negro, насчет лаконичности, я думаю, это только в плюс, когда на тестовом задании, не имея под рукой шаблона (выпадающего списка вариантов, ага), девушка дает описание тому, почему именно такой severity, и что это именно 2 из 5, а не 2 из 3, например.
С чего вы вообще взяли, что ее легенда - нечто огромное и не лаконичное?
Автор - ну, первый пост у вас великоват, надеюсь, в ответе на задание вы написали лаконичнее
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/
#11
Отправлено 24 августа 2012 - 11:35
Спасибо, я жизни я себе представляю хорошо шаблонизированный артефакт, и у меня баг-репорт оформлен по шаблону. Я не вижу ничего дурного в прикреплении поясняющей систему оценки записки. Вы - видите?Если ближе к делу, то багрепорт - это "в жизни" хорошо шаблонизированный артефакт, и ваши фантазии о его оформлении ничего не стоят, а правильно оценивать критичность баги... по-моему для этого ума совсем не надо, по сравнению с прочими необходимыми тестерскими способностями и умениями, но это уже вам решать, с какой сильной стороны показать себя работодателю.
Испытывать меня на прочность в принципе бесполезно - я в сети еще со времен фидонета и то, что "в интернете кто-то неправ" меня не задевает вообще ни разу.)
)Автор - ну, первый пост у вас великоват, надеюсь, в ответе на задание вы написали лаконичнее
#12
Отправлено 24 августа 2012 - 14:39
1) Ваша недружелюбная реакция в мой адрес противоречит тому, к чему и как вы призываете....уж прям совсем...не слушайте его!..
...поддерживайте дружелюбную атмосферу на работе...
2) Атмосфера на работе должна приводить к результату. Например, вы дружите с коллегой по работе и работаете с ним в спарринге, но его профессиональные качества очень низкие с уклоном в формализм, вам приходится что-то делать за него и в конце-концов ваша работа не обеспечивает качественного результата, и вы - слабое звено. Поэтому дружите дома! а на работе атмосфера должна быть рабочей: будьте профессиональны, коммуникабельны, корректны, результативны (извините, если где-то заметите тавтологию или увидели в моих предыдущих высказываниях выход за рамки этих принципов).
Испытывать на прочность я никого не собираюсь.
Надеюсь, что всем в коллегах не хотел бы видеть выкручивающихся, скрытных, многословных, прикрывающихся формализмом людей с "дипломатией улыбки".
#13
Отправлено 24 августа 2012 - 15:28
Позвольте теперь и мне дать вам один совет: "Не ставить диагноз по юзерпику". Психолог из вас, если честно, плохой.
На этом у меня все, поддерживать далее дискуссию с вами я не собираюсь. Спасибо за внимание.
#14
Отправлено 24 августа 2012 - 18:14
1) Ваша недружелюбная реакция в мой адрес противоречит тому, к чему и как вы призываете....уж прям совсем...не слушайте его!..
...поддерживайте дружелюбную атмосферу на работе...
2) Атмосфера на работе должна приводить к результату. Например, вы дружите с коллегой по работе и работаете с ним в спарринге, но его профессиональные качества очень низкие с уклоном в формализм, вам приходится что-то делать за него и в конце-концов ваша работа не обеспечивает качественного результата, и вы - слабое звено. Поэтому дружите дома! а на работе атмосфера должна быть рабочей: будьте профессиональны, коммуникабельны, корректны, результативны.
1) Я говорила о том, что нет ничего плохо в том, чтобы сказать человеку "спасибо" за помощь.
Где я говорила о том, что надо раскланиваться перед всеми?
2) Мне очень жаль, что у вас такой узкий кругозор в этом плане. Это все опыт, в принципе то. У каждого он свой. У кого-то его больше (я сейчас даже не о себе).
Но вот вообще не увидела связи - если вы с кем-то дружите = вы делаете за него всю работу о_О
Если ваша работа от этого страдает, то сфигали? Если не страдает - почему бы и не помочь?
Опять же, при чем тут вообще дружелюбная атмосфера и слово "спасибо"?
Дружелюбная атмосфера это совсем не то же самое, что и брататься с каждым коллегой, делая за него часть работы, еще и в ущерб себе)
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/
#15
Отправлено 24 августа 2012 - 20:25
Molechka, обратитесь к исходному вопросу Автора. Коротко его суть: одно приложение создаёт xml-файл с описанием путей файловой системы для... далее следует легенда Автора о данном приложении:
Извините, я не понял вашего вопроса:...создаются ли на его основе каталоги в файловой системе или нет, неизвестно (ответ на этот вопрос я получить не имею возможности)...
Я ничего не говорил о легенде Автора, она говорит сама за себя!...с чего вы вообще взяли, что ее легенда - нечто огромное и не лаконичное?..
Отбросим эмоции, поговорим как специалисты (я ни на что не претендую, кроме как подумать).
Мой кругозор подсказывает следующую Легенду: имеет место интеграция с другим приложением, использующим xml от первого, и, вероятнее всего на стороне второго валидируется корректность входных данных.
Вопрос: Molechka, если вы - тестировщик второго приложения и гарантируете, что оно корректно обрабатывает/находит ошибки входного xml (в противном случае вы будете виноваты, если из-за ошибки будут удалены, например, системные каталоги и т.п.), то какое severity должна задать Tagira багу, как тестировщик первого приложения, создающего некорректный xml?
#16
Отправлено 25 августа 2012 - 07:17
Вопрос: Molechka, если вы - тестировщик второго приложения и гарантируете, что оно корректно обрабатывает/находит ошибки входного xml (в противном случае вы будете виноваты, если из-за ошибки будут удалены, например, системные каталоги и т.п.), то какое severity должна задать Tagira багу, как тестировщик первого приложения, создающего некорректный xml?
Если я - тестировщик второго приложения и имею возможность ставить баги первому, то я фактически - Заказчик. Ну или сообщаю о проблеме Заказчику, а он сообщает первому приложению.
А все, что нашел Заказчик - это блокер :)
Если это действительно бага, конечно
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/
#17
Отправлено 25 августа 2012 - 17:40
#18
Отправлено 01 сентября 2012 - 21:33
#19
Отправлено 05 сентября 2012 - 21:23
1)тестеру надо уметь выкручиваться, например, в затруднительных ситуациях при создании багрепорта, для чего требуется подключить к нему легенду, куда лепить всё, что знаете разумного (типа, вы так понимаете), как способ прикрыть свои сомнения, а может и ошибки, чтобы в результате ещё и заявить себя, как думающего перфекциониста.
2)тестеру стоит сомневается только в высоком качестве тестируемого продукта и что в нём всё надёжно проверено.
Количество пользователей, читающих эту тему: 1
0 пользователей, 1 гостей, 0 анонимных