Feeds:
Posts
Comments

Archive for the ‘Баг-трекер’ Category

Во-первых, под словом “Workflow” в Mantis подразумевается “Переходы состояний процесса”. Но мне проще сказать “воркфлоу”, нежели “переходы состояний”.

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

Хотя там есть даже язык “волапюк”…

В третьих, нужно покопаться в коде приложения.

Залогинившись под административным аккаунтом, переходим на страницу “manage > Manage Configuration > Workflow Transitions

По-русски: “управление > Управление конфигурацией > Переходы состояний процесса“.

По-простому: http://вашMantis/manage_config_workflow_page.php

По-умолчанию в Mantis присутствуют следующие статусы:

  • new
  • feedback
  • acknowledged
  • confirmed
  • assigned
  • resolved
  • closed

Есть еще связанный статус ‘reopened’, но рассматривать его пока незачем.

Логика связей между статусами очень грамотная и продуманная, но подходит не всем и не всегда.

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

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

Но добавить новый статус и дальновиднее, и интереснее 🙂

По причинам удобства, хотелось, чтобы статус ‘active’ можно было устанавливать наиболее быстро и просто, без постоянного развертывания выпадающего списка статусов…

Блин, это сделать даже быстрее, чем разъяснить.

Также встал вопрос про статусы ‘acknowledged’ и ‘confirmed’. Вопрос встал такой – нафига нам эти статусы? Мы ими не пользуемся. Надо бы их прибить.

Понеслось!

(more…)

Advertisements

Read Full Post »

Обращение к нации

Дорогой разработчик,

в нашем мире существуют люди, которые могут найти баги даже в идеально написанной тобою программе. Обороняться от такой несправедливости бессмысленно, поэтому лучше это дело упорядочить.

Для этого используются системы управления дефектами вроде “Mantis”.

  • Да, можно называть дефекты багами. Главное не в названии, главное в том, что их надо чинить.

(more…)

Read Full Post »

Для самомнения вердикт “Can’t reproduce” не так страшен как “Not a bug“, но – тоже неприятно.

Официальщина:

Не могу воспроизвести” означает только то, что работник, ответственный за починку дефекта, не смог его воспроизвести на билде, указанном в описании дефекта.

Почему не смог?

  1. Из-за разницы в конфигурации компьютеров

    В веб-отрасли это бывает реже, чем в десктопных приложениях. Но бывает. Но редко.

  2. В описании бага отсутствуют какие-то шаги или нюансы

    А вот это очень серьезно, и идет прямым минусом в карму тестировщику. После ревью баг будет переоткрыт, что неприятно ни им, ни нам, ни этим, которые за всеми нами приглядывают.

  3. Дефект уже починен в более новом билде, а девелопер как раз и проверяет это дело на этот самом “обновленном”

    Это самое противное и требующее рассмотрения.

Третья причина является проблемой из-за того, что входит в противоречие с официальным толкованием статуса “Не могу воспроизвести”:

Дефект проверяется на билде, указанном в описании дефекта.

Дефект, зарегистрированный в версии 1.9, отложен и принят к
рассмотрению в версии 1.12. Высока вероятность того, что в 1.12 он уже
будет как-то починен? Если рассматривать ситуацию абстрактно, то
вероятность весьма, весьма, гм, вероятна.

А если так, то является ли преступлением против системы треканья багов проверить исторический баг на новом билде, и заявить, что “не могу воспроизвести”?

Не является.

Но проверять дефект на обновленном билде, как правило – на текущем – это потенциальная брешь и проблема. Предположим, не воспроизводится. А ну как он, зараза, снова всплывет? Мы точно знаем, почему этот гадёныш не воспроизводится?

Единственно верное решение:

Поставить билд 1.9, воспроизвести, понять, отчего это произошло, и убедиться в том, что в билде 1.12 эта проблема несомненно решена. Убеждаться – в коде.

И если дефект при проверке уже считается недействительным, нужно ставить ему статус “Fixed” с указанием билда, в котором баг считается починенным.

Что в действительности – возня со старым билдом может потребовать неоправданно много времени. “Единственно верное решение” может быть использовано только в том случае, если баг приоретизирован как “серьезный”.

Вышеизложенное написано в поисках уточнения: баг, который не воспроизводится на обновленном билде – он все-таки “Fixed”, или “Can’t reproduce”?

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

Read Full Post »

Заголовок бага:

Link to ‘enabled’ is not disabled

Read Full Post »

Всем тем, кто должен (или счастлив) работать с Jira, надо вызубрить правила форматирования текста в ее полях.

Используются стандартные wiki-принципы. Например, чтобы сделать заголовок второго уровня, следует написать “h2. ” в начале строки. Можно ставить пробел после “h2.”, а можно писать слитно.

Notation Comment
h1. Огромный заголовок

Огромный
заголовок

h2. Большущий заголовок

Большущий заголовок

h3. Большой заголовок

Большой заголовок

h4. Normal heading

Normal heading

h5. Small heading
Small heading
h6. Smallest heading
Smallest heading

Bold: *bold*

Italic: _italic_

Линк: [Test It Quickly|http://testitquickly.com] = Test It Quickly

UPD: рядом с каждым полем, которое допускает wiki-тэги есть желтый значок со ссылкой на полный список правил форматирования (на нем вопросительный знак). Он показывается только если в админке Jira для текстовых полей включено wiki-форматирование. Не все это знают и не все это включают.

Read Full Post »

Даже в Jira есть мелкие огрехи:

РедакАтируем профили

РедакАтируем профили

Read Full Post »

Когда-то Udaleator рассказывал мне о том, что в разработке важны буквально все мелочи, которые окружают разработчика. Вплоть до покрытия пола, по котором человек перемещается на кресле от одного стола к другому. Не скажу, что не был впечатлен, но до конца все это не осознавал.

Теперь я проповедую то же самое, особенно в отношении рабочего инструмента “багтрекер”. С точки зрения тестировщика у меня сложилось особое требование к подобному инструменту – быть удобным и скоростным при заведении баг-репортов.

Возможно, вопросы скорости работы багтрекера кажутся надуманными, но меня эта “надуманная” проблема иногда приводила к тому, что все баг-репорты, найденные в течение тестовой сессии, я записывал в Блокнот, и только ближе к вечеру начинал выкладывать все на трекер.

Даже обоснование этой задержке нашел – во время вечерного “занесения” описания багов волей-неволей пересматриваются, и уточняются, и от этого, мол, даже лучше… Это обоснование ошибочно.

Вот сквозь призму скорости заведения баг-репортов и поговорим о трех “ходовых” багтрекерах – Mantis, Bugzilla, Jira.

Мне также доводилось работать с трекерами типа Microsoft SharePoint Service (SPS) и CollabNet Enterprise Edition, но их в этом обзоре не будет.

Понаехали!
(more…)

Read Full Post »

Older Posts »

%d bloggers like this: