Сообщений в теме: 18

[Tagira]

UPD: Вопрос решен, благодарю за участие!

Добрый день.
Тестированием я занималась не так долго и с тех пор много воды утекло, все это время (5 лет) я занималась другими вещами. Конечно, что-то забыла, сейчас теорию почитала - вспомнила.
Хочу вернуться в эту область сейчас. На данный момент при тестировании приложения (тестовое задание) столкнулась со следующей проблемой:

Приложение позволяет создавать и редактировать некий каталог, имеющий иерархическую структуру. Корневой элемент каталога имеет параметр - полный путь к каталогу (вводится в текстовое поле). Остальные элементы имеют параметры (вводятся в текстовые поля), соответствующие именам папок в файловой системе (указано в инструкции пользователя, других документов, описывающих требования к приложению, нет).
Приложение сохраняет каталог в виде xml-файла. Что с этим файлом на практике должно происходить дальше - создаются ли на его основе каталоги в файловой системе или нет, неизвестно (ответ на этот вопрос я получить не имею возможности).

Известно, что полный путь к каталогу должен указывать на существующую директорию, известно, что параметры элементов, соответствующие именам папок в файловой системе, должны удовлетворять требованиям, предъявляемым к именам папок в Windows (выяснено уточняющими вопросами).

В ходе выполнения тест-кейсов обнаружилось, что поле пути может иметь неверный формат, указывать на несуществующую папку, не обрабатывает конечные и начальные пробелы, допускает использование в именах папок запрещенных символов и т.п.

С одной стороны, если в дальнейшем создаваемый xml файл используется для создания каталогов файловой системы, ошибки такого рода являются критическими. С другой стороны, в рамках работы с текущим приложением они не вызывают сбоев и не приводят к потере данных, и являются просто функциональными багами, т.к. не выполняется требование.

Какую Severity лучше поставить в данном случае?
Заранее спасибо.

[Future]

Я привык к 4-ёх уровневой системе, где 1-ый уровень это критикал, а 4-ый минорный. Я бы поставил данному дефекту 3-ий уровень, с приоритетом 2 (где 1, делаем сегодня, а 2 в ближайший выпуск, 4 -ый как-нибудь). Объясняю почему, приложение запускается, если да, то это уже не 1-ый уровень. Функционал работает как надо, при условии корректных данных - ответ да, значит не второй.

[Tagira]

Future, спасибо за мнение!

[negro]

Tagira, я понял вашу ситуацию, но вы не описали, как вы (сами или согласно доведённой до вашего сведения инструкции) дифференцируете уровни критичности, а самое главное - что вас беспокоит? Вы, как тестировщик, подробно описали проблему и риски. Допустим, менеджер проекта рассматривает следующие возможные уровни severity: 1-"смертельно"; 2-"опасно"; 3-"возможны проблемы"; 4-"криво". Ну выберите вы 1 или 2 или 3 и что? Самое главное, чтобы он по отношению к вам не видел ни паникёра и ни неадекватного специалиста в сравнении с severities, заданных вами для других багов. Я, как тестер, указал бы 2, а какой Priority задаст менеджер и исходя из каких соображений вас уже не касается, - вы молодец, сделали своё дело, вам спасибо. Судить о решении менеджера будут другие люди, которые, если потребуется, обратятся и выслушают ваше мнение.

[LeshaL]

При выполнении тестового задания самое главное не то как вы проставите северити, а то как вы объясните почему вы поставили такую северити.
Выбираете систему оценок и оцениваете найденные баги, в каких-то местах объясняете почему такая оценка.

[Tagira]

Tagira, я понял вашу ситуацию, но вы не описали, как вы (сами или согласно доведённой до вашего сведения инструкции) дифференцируете уровни критичности, а самое главное - что вас беспокоит? Вы, как тестировщик, подробно описали проблему и риски. Допустим, менеджер проекта рассматривает следующие возможные уровни severity: 1-"смертельно"; 2-"опасно"; 3-"возможны проблемы"; 4-"криво". Ну выберите вы 1 или 2 или 3 и что? Самое главное, чтобы он по отношению к вам не видел ни паникёра и ни неадекватного специалиста в сравнении с severities, заданных вами для других багов. Я, как тестер, указал бы 2, а какой Priority задаст менеджер и исходя из каких соображений вас уже не касается, - вы молодец, сделали своё дело, вам спасибо. Судить о решении менеджера будут другие люди, которые, если потребуется, обратятся и выслушают ваше мнение.

Я сама пользуюсь (по давней привычке) довольно "мелкодробленным" шагом - 6 вариаций, от блокирующего до косметического дефекта. В условиях, когда и баг-репорт, и отчет по тестированию пишутся "в свободной форме" (то, что я услышала, а, точнее, увидела в ответе на свой вопрос касательно принятого оформления), я выкрутилась, дополнив баг-репорт legend с указанием, какая важность в каких случаях используется.

При выполнении тестового задания самое главное не то как вы проставите северити, а то как вы объясните почему вы поставили такую северити.
Выбираете систему оценок и оцениваете найденные баги, в каких-то местах объясняете почему такая оценка.

Да, именно так в итоге и сделала. Возможно, это несколько неправильно с т.з. оформления, но в комментариях в подобным ошибкам я указывала, что в случае, если сформированный xml-документ будет использоваться для создания файлового каталога, баг имел бы другую важность, и почему.

Хочу выразить огромную благодарность всем без исключения откликнувшимся.

[negro]

Подождите благодарить...
1) Немного критики в ваш адрес: не нравится ни ваша нерешительность, ни терминология типа "выкрутилась"... Похоже на проблемы с рабочей атмосферой, которые влекут параноидальность, перестраховку в мелочах. Уверяю вас, по большому счёту никто (кому по-настоящему есть, чем заниматься) на severity особо не смотрит, если только оно не волшебное. Главное, чтобы чётко и лаконично было описание бага, а не Баллада о баге.
2) Не понятно, почему Лично вы пользуетесь мелко дробленным шагом из 6 вариаций, что это за ноу-хао в процессе обеспечения качества со свободной формой багрепорта? Разве в багтрекере для выбора severity не используется dropdown, предустановленный менеджером с пояснением системы оценок?

Совет: не погружайтесь в нездоровый формализм, а например, добейтесь/убедите менеджера, что для качества программного продукта в части данной проблемной функциональности при создании xml к нему требуется xsd-описание для его автоматической валидации, т.е. девелоперы должны разработать xsd и включить в решение. А вам, как специалисту по "белому ящику", в последствие будет необходимо проверить хорошо ли написана xsd, чтобы надёжно защищать xml от ошибок.

[Tagira]

Подождите благодарить...
1) Немного критики в ваш адрес: не нравится ни ваша нерешительность, ни терминология типа "выкрутилась"... Похоже на проблемы с рабочей атмосферой, которые влекут параноидальность, перестраховку в мелочах. Уверяю вас, по большому счёту никто (кому по-настоящему есть, чем заниматься) на severity особо не смотрит, если только оно не волшебное. Главное, чтобы чётко и лаконично было описание бага, а не Баллада о баге.
2) Не понятно, почему Лично вы пользуетесь мелко дробленным шагом из 6 вариаций, что это за ноу-хао в процессе обеспечения качества со свободной формой багрепорта? Разве в багтрекере для выбора severity не используется dropdown, предустановленный менеджером с пояснением системы оценок?

Совет: не погружайтесь в нездоровый формализм, а например, добейтесь/убедите менеджера, что для качества программного продукта в части данной проблемной функциональности при создании xml к нему требуется xsd-описание для его автоматической валидации, т.е. девелоперы должны разработать xsd и включить в решение. А вам, как специалисту по "белому ящику", в последствие будет необходимо проверить хорошо ли написана xsd, чтобы надёжно защищать xml от ошибок.

Если вы внимательно читали мое первое сообщение, то должны были увидеть, что я выполняла тестовое задание. Ни о какой системе баг-треккинга в данном варианте речи не шло. И уж если на то пошло, то 6 вариаций - это не мое know-how; severities в баг-треккере, который мы использовали на моем предыдущем месте работы, были настроены именно так. И именно в виду отсутствия у меня столь вожделенного dropdown-а я "выкрутилась" (как бы вам ни нравилось данное слово - а как иначе назвать этакие "костыли"?), используя legend - во избежание двусмысленности.

Разумеется, перед тем, как оформлять тестовое задание, я поинтересовалась в компании, для которой это задание выполнялось, в какой форме они хотят получить от меня ответ и что он должен в себя включать. К моему большому сожалению, я не смогла получить на этот вопрос более внятного ответа, нежели тот, что был приведен выше (как, к слову и на некоторые другие, да хотя бы вот на тот же вопрос, каким образом будет использоваться (и будет ли) созданный приложением xml-документ). Я в общем и целом имею убеждение, что, принимая решение о возможности предложить претенденту вакантную должность, человек, ответственный за принятие этого решения, будет руководствоваться не только и не столько количеством обнаруженных багов, но и их качеством, а так же адекватностью оценки важности бага, плюс оформлением. Исходя из этих убеждений, я склонна делать все настолько хорошо (это, впрочем, касается не только выполнения тестовых заданий, я вообще перфекционист по жизни), насколько мне это позволяет время, если я действительно заинтересована в работе именно в этой компании (а я заинтересована).

В свете всего, сказанного выше, позвольте мне применительно к данному конкретному случаю счесть некорректными ни ваше предположение о проблемах с рабочей атмосферой, ни ваш совет добиться чего-либо от менеджера.

Ну и вернусь к первой строке вашего сообщения. Я не вижу ничего дурного в том, чтобы поблагодарить всех, кто потратил свое время, отвечая ли на мой вопрос, выясняя ли обстоятельства, критикуя ли меня. Такова уж моя натура - я порой до зубовного скрежета корректна и вежлива ;) А потому вам - спасибо!(еще раз)

[negro]

...я склонна делать все настолько хорошо... до зубовного скрежета...

Подождите говорить спасибо...
Вы не прокомментировали совет быть лаконичной, не писать баллады.
И ещё немного критики: хвалите себя молча, а то слушать про ваш зубовный скрежет неприятно.

Если ближе к делу, то багрепорт - это "в жизни" хорошо шаблонизированный артефакт, и ваши фантазии о его оформлении ничего не стоят, а правильно оценивать критичность баги... по-моему для этого ума совсем не надо, по сравнению с прочими необходимыми тестерскими способностями и умениями, но это уже вам решать, с какой сильной стороны показать себя работодателю.

[Molechka]

Подождите говорить спасибо...
Вы не прокомментировали совет быть лаконичной, не писать баллады.
И ещё немного критики: хвалите себя молча, а то слушать про ваш зубовный скрежет неприятно.

Если ближе к делу, то багрепорт - это "в жизни" хорошо шаблонизированный артефакт, и ваши фантазии о его оформлении ничего не стоят, а правильно оценивать критичность баги... по-моему для этого ума совсем не надо, по сравнению с прочими необходимыми тестерскими способностями и умениями, но это уже вам решать, с какой сильной стороны показать себя работодателю.

Ну вы уж прям совсем придираетесь к девушке.

С каких пор говорить "спасибо" - плохо?
Автор, не слушайте его! Говорить "спасибо" очень полезно и очень приятно. В частности, своим коллегам, когда они отвечают на ваши вопросы - поддерживайте дружелюбную атмосферу на работе

negro, насчет лаконичности, я думаю, это только в плюс, когда на тестовом задании, не имея под рукой шаблона (выпадающего списка вариантов, ага), девушка дает описание тому, почему именно такой severity, и что это именно 2 из 5, а не 2 из 3, например.
С чего вы вообще взяли, что ее легенда - нечто огромное и не лаконичное?

Автор - ну, первый пост у вас великоват, надеюсь, в ответе на задание вы написали лаконичнее

[Tagira]

Если ближе к делу, то багрепорт - это "в жизни" хорошо шаблонизированный артефакт, и ваши фантазии о его оформлении ничего не стоят, а правильно оценивать критичность баги... по-моему для этого ума совсем не надо, по сравнению с прочими необходимыми тестерскими способностями и умениями, но это уже вам решать, с какой сильной стороны показать себя работодателю.

Спасибо, я жизни я себе представляю хорошо шаблонизированный артефакт, и у меня баг-репорт оформлен по шаблону. Я не вижу ничего дурного в прикреплении поясняющей систему оценки записки. Вы - видите?
Испытывать меня на прочность в принципе бесполезно - я в сети еще со времен фидонета и то, что "в интернете кто-то неправ" меня не задевает вообще ни разу.)

Автор - ну, первый пост у вас великоват, надеюсь, в ответе на задание вы написали лаконичнее

)

[negro]

...уж прям совсем...не слушайте его!..
...поддерживайте дружелюбную атмосферу на работе...

1) Ваша недружелюбная реакция в мой адрес противоречит тому, к чему и как вы призываете.
2) Атмосфера на работе должна приводить к результату. Например, вы дружите с коллегой по работе и работаете с ним в спарринге, но его профессиональные качества очень низкие с уклоном в формализм, вам приходится что-то делать за него и в конце-концов ваша работа не обеспечивает качественного результата, и вы - слабое звено. Поэтому дружите дома! а на работе атмосфера должна быть рабочей: будьте профессиональны, коммуникабельны, корректны, результативны (извините, если где-то заметите тавтологию или увидели в моих предыдущих высказываниях выход за рамки этих принципов).

Испытывать на прочность я никого не собираюсь.
Надеюсь, что всем в коллегах не хотел бы видеть выкручивающихся, скрытных, многословных, прикрывающихся формализмом людей с "дипломатией улыбки".

[Tagira]

negro,
Позвольте теперь и мне дать вам один совет: "Не ставить диагноз по юзерпику". Психолог из вас, если честно, плохой.
На этом у меня все, поддерживать далее дискуссию с вами я не собираюсь. Спасибо за внимание.

[Molechka]

...уж прям совсем...не слушайте его!..
...поддерживайте дружелюбную атмосферу на работе...

1) Ваша недружелюбная реакция в мой адрес противоречит тому, к чему и как вы призываете.
2) Атмосфера на работе должна приводить к результату. Например, вы дружите с коллегой по работе и работаете с ним в спарринге, но его профессиональные качества очень низкие с уклоном в формализм, вам приходится что-то делать за него и в конце-концов ваша работа не обеспечивает качественного результата, и вы - слабое звено. Поэтому дружите дома! а на работе атмосфера должна быть рабочей: будьте профессиональны, коммуникабельны, корректны, результативны.

1) Я говорила о том, что нет ничего плохо в том, чтобы сказать человеку "спасибо" за помощь.
Где я говорила о том, что надо раскланиваться перед всеми?

2) Мне очень жаль, что у вас такой узкий кругозор в этом плане. Это все опыт, в принципе то. У каждого он свой. У кого-то его больше (я сейчас даже не о себе).

Но вот вообще не увидела связи - если вы с кем-то дружите = вы делаете за него всю работу о_О
Если ваша работа от этого страдает, то сфигали? Если не страдает - почему бы и не помочь?

Опять же, при чем тут вообще дружелюбная атмосфера и слово "спасибо"?
Дружелюбная атмосфера это совсем не то же самое, что и брататься с каждым коллегой, делая за него часть работы, еще и в ущерб себе)

[negro]

Да подождите уходить от сути дискуссии, переходить на эмоции (со спасибо моему коту, собаке...)!

Molechka, обратитесь к исходному вопросу Автора. Коротко его суть: одно приложение создаёт xml-файл с описанием путей файловой системы для... далее следует легенда Автора о данном приложении:

...создаются ли на его основе каталоги в файловой системе или нет, неизвестно (ответ на этот вопрос я получить не имею возможности)...

Извините, я не понял вашего вопроса:

...с чего вы вообще взяли, что ее легенда - нечто огромное и не лаконичное?..

Я ничего не говорил о легенде Автора, она говорит сама за себя!

Отбросим эмоции, поговорим как специалисты (я ни на что не претендую, кроме как подумать).

Мой кругозор подсказывает следующую Легенду: имеет место интеграция с другим приложением, использующим xml от первого, и, вероятнее всего на стороне второго валидируется корректность входных данных.
Вопрос: Molechka, если вы - тестировщик второго приложения и гарантируете, что оно корректно обрабатывает/находит ошибки входного xml (в противном случае вы будете виноваты, если из-за ошибки будут удалены, например, системные каталоги и т.п.), то какое severity должна задать Tagira багу, как тестировщик первого приложения, создающего некорректный xml?

[Molechka]

Вопрос: Molechka, если вы - тестировщик второго приложения и гарантируете, что оно корректно обрабатывает/находит ошибки входного xml (в противном случае вы будете виноваты, если из-за ошибки будут удалены, например, системные каталоги и т.п.), то какое severity должна задать Tagira багу, как тестировщик первого приложения, создающего некорректный xml?

Если я - тестировщик второго приложения и имею возможность ставить баги первому, то я фактически - Заказчик. Ну или сообщаю о проблеме Заказчику, а он сообщает первому приложению.

А все, что нашел Заказчик - это блокер :)
Если это действительно бага, конечно

[negro]

Хорошо бы, если кто-то кое-чему научился...

[Tagira]

Оу, как я вижу, все проблемы из-за недопонимания, как обычно. legend - это письменное пояснение к обозначениям, используемым мною в bug-report. Извините, если кого-то это ввело в заблуждение Я имела в виду, что помимо обозначения severity в цифровом варианте, я отдельно дополнила баг-репорт файлом, в котором кратко пояснила, какому уровню что соответствует. Надеюсь, таким образом все разночтения устранены =)

[negro]

И в завершении, чтобы для остальных читателей данной темы была хоть какая-то польза, им надо выбрать одно из двух:
1)тестеру надо уметь выкручиваться, например, в затруднительных ситуациях при создании багрепорта, для чего требуется подключить к нему легенду, куда лепить всё, что знаете разумного (типа, вы так понимаете), как способ прикрыть свои сомнения, а может и ошибки, чтобы в результате ещё и заявить себя, как думающего перфекциониста.
2)тестеру стоит сомневается только в высоком качестве тестируемого продукта и что в нём всё надёжно проверено.