Заметки об управлении дефектами

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

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

     Некоторые вещи общеизвестны, но я все равно их перечислю, чтобы не упустить ничего важного.

     Итак, список полезностей в управлении дефектами:

Поведение тестировщиков

1) Исправление дефекта проверяет тот, кто его подписал - Это прописная истина, впитанная с младых тестерских ногтей. Делать так хорошо, потому что автор баг репорта лучше всего знаком с ситуацией. Каким бы полным ни был отчет об ошибке, автор в процессе исследования бага видел множество мелочей, которые остались у него в памяти. И работал с приложением он определенным привычным именно ему образом.

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

2) Читайте дефекты коллег - Хотя бы те, которые связаны с тем, что вы тестируете. Особенно актуально читать баги, которые сыпятся во время тестирования текущего билда.

     Что это дает:

б) знание, какие дефекты уже обнаружены, а значит, вы не будете тратить время на тестирование и документирование багов, которые уже известны.

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

г) вы сможете прикрыть коллегу-тестера, если он недоступен, а у программистов есть вопросы.

Пример: на днях прочитала дефект коллеги, не поняла, спросила, мне все объяснили. Потом коллега ушла домой, а вечером у программиста возникли вопросы по данному багу. Благодаря тому, что меня вовремя просветили, программист сразу получил ответы и баг был пофикшен немедленно.

3) Разъясняйте интерфейс баг-трекера -  когда в проект приходит новый человек. Программист, тестировщик, технический писатель - кто угодно. Потратив пару минут на объяснения и показ того, что, где и как надо делать,  вы

а) экономите время и нервы коллеги, которые он растрачивал бы при самостоятельном ковырянии в системе. Он, конечно, разберется, но он потратит 20 минут, а вы объясните за 5. Также, это профилактика возможных проблем, которые могли бы возникнуть при неправильной работе с баг-трекером (например, случайное удаление бага или появление загадочных комментариев).

б) налаживаете контакт. Вы будете работать в одной команде – вот и покажите, что команда, это не только название, но и внимание друг к другу и взаимопомощь. Даже в таких мелочах. Человек гораздо охотнее будет с вами общаться и сотрудничать.

4) Разъясняйте жизненный цикл записи в багтрекере – новичкам. Смысл этого пункта идентичен предыдущему.

     Единственное различие в том, что вы объясняете. В предыдущем случае вы объясняли интерфейс баг-трекера (как добавить новый тикет, как изменить его состояние, как добавить комментарий, как настроить фильтр и пр.).

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

Например, в некоторых наших проектах у багов не используется состояние «Rejected» (см. картинка в начале поста). Вместо этого разработчик переводит дефект  в «Fixed» и в комментах пишет, что баг отклонен и по какой причине.

5) Перед подписанием дефекта проведите поиск в баг-трекере – А вдруг такой дефект уже есть? Удивительно, но это действие не всем тестировщикам кажется необходимым. В результате, плодятся дубли, а значит тратится время на исследование и подписание уже известных багов, на их отработку ПМом и т.д.

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

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

7) Если дефект не может быть проверен в текущем билде, оставляйте комментарий - Это нужно, чтобы держать под контролем «подвисшие» дефекты. Подвисшие – это те, исправления которых вошли в текущий билд, но не могут быть проверены по какой-то причине. Например, заблокированы другими багами. Или этот баг нужно проверить в другой специфической сборке. Сейчас вы это помните, но пройдет немного времени и мозг выгрузит эту информацию из памяти. И попробуйте потом с ходу дать объяснение по каждому багу, если ПМ спросит, а почему это не протестировано. Или вы сами будете мучительно вспоминать на какой конкретно баг завязан этот.

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

8) Прежде, чем подписывать предложения по усовершенствованию, получите согласие ответственного лица – Зависит от соглашений у вас в команде. Предложение по усовершенствованию – это когда дефекта формально нет, но вы видите, что имеет смысл кое-что улучшить и вы даже знаете, что конкретно. 

     Если баг в большинстве случаев программист обязан исправить, то внедрять усовершенствование он не обязан. Решение зависит от многих факторов, в т.ч. текущих приоритетов разработки и характера усовершенствования. Я обычно сначала согласовываю такие вещи со всеми заинтересованными лицами - с программистом, с ПМ-ом и др. - зависит от значимости усовершенствования. Предварительное согласование позволяет не плодить в баг-трекете заведомо отвергнутые записи. 

9) Пользуйтесь фильтрами - Обычно баг-трекер позволяет создавать выборки багов в соответствии с определенными условиями фильтрации.

     Например, у меня были такие выборки:

- мои реализованные дефекты (fiхed, которые подписала я)

- реализованные для меня (fiхed, которые подписала не я, но я теперь отвечаю за эту функциональность)

- все мои дефекты (все дефекты, подписанные мной, независимо от состояния)

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

Наличие правильно настроенных фильтров делает работу быстрее и удобнее.

Настрой уведомления!

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

     Поэтому подумайте, а не настроить ли вам ....

10) Уведомления об исправлении подписанного вами дефекта - Вообще, я пересматриваю список исправленных дефектов в начале нового билда.

     Но вот частный случай, когда такие уведомления могут быть полезны:

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

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

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

     Тут надо смотреть, как удобнее.

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

12) Уведомлять ПМ о подписании дефекта - Эти уведомления обязательны. ПМ должен немедленно узнать о баге, прочесть его и отреагировать.

13) Уведомлять руководителя команды тестирования о подписании дефекта – По необходимости. Тест тим лид железно должен знать о каждом обнаруженном баге, но у нас работа бывала организована так, что тест лид знал о багах еще до подписания их в трекер. Поэтому уведомления ему были не нужны. В остальных случаях они необходимы.

14) Уведомлять себя о подписании дефектов другими - Чтобы вы могли пойти и посмотреть, что подписали коллеги. Зачем читатать баги коллег я писала выше. Как вариант, можно без уведомлений просто пару раз в день заглядывать в список свежих багов.

15) Уведомлять программиста о назначении на него дефекта - Обязательно. Программист должен как можно быстрее узнать о баге, который он должен исправить.

16) Уведомлять программиста об отвержении дефекта - Обязательно. Программист должен как можно быстрее узнать, что баг все же не исправлен.

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

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