среда, 3 февраля 2010 г.

Когда заносить баги в трекер?

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

Но на практике очень многие тестировщики (в том числе и я) не придерживаются такого подхода. На то есть несколько причин и на этот счет каждый имеет свое мнение и свои причины.

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

Конечно, если в процессе тестирования находится по багу в час, то тут нет никаких проблем, чтобы сразу же занести баг в трекер. Но попадаются (и не редко) такие проекты где «баг на баге сидит и багом погоняет». В такой ситуации заводить баги сразу же при их нахождении не очень удобно. Даже совсем не удобно. На переключение между тестированием и занесением уходит довольно много времени. Поэтому, я считаю вполне оправданным занесение багов не во время самого тестирования, а чуть позже.

Единственное, что я считаю неприемлемым – это заносить все найденные баги в конце дня. Во-первых, их тогда очень нудно описывать. Во-вторых, очень велика вероятность провтыкать какой-то баг и не занести. И в-третих, это плохо сказывается на здоровье программистов :), которые не видя в течении дня ни одного нового бага, радуются и спокойно, с чистой совестью собираются себе домой… И тут вдруг обнаруживают несколько десятков багов. А-а-а!!! Так и до нервного срыва недалеко :)

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

А для того, чтобы не забыть баги очень удобно по ходу тестирования делать скриншоты. Ведь практически на каждый баг можно сделать скриншот. А по скриншотам уже очень легко вспоминать суть бага. Также можно делать заметки на бумаге. Завязывать узелки на память :) ... у каждого свои методы.

PS: Про узелки на память - это шутка.


6 комментариев:

  1. А ещё лучше процесс тестирования записывать как видео, а к багу прилагать кусочек с комментариями, что в нем не так :)

    Я, правда, так не делал - не тестировщик (но сочувствующий) - музыка навеяла :)

    ОтветитьУдалить
  2. Ага! Представляю как разработчики (которые зачастую даже описание бага внимательно не читают)будут сидеть и смотреть это видео :)

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

    ОтветитьУдалить
  3. Неправда,
    видео очень много показать может.
    Как быть с багами, которые разработчик не может репродуцировать?

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

    Это как в пословице, лучше один раз увидеть, чем сто раз услышать(прочесть)

    ОтветитьУдалить
  4. Я ж не говорю, что видео это плохо. Видео очень помогает в сложных случаях, и конечно с багами, которые разработчик не смог воспроизвести.

    Я говорю о том, что записывать видео для всех багов - это перебор. Согласитесь, что большинство багов прекрасно воспроизводится. И простых скриншотов более чем достаточно.

    ОтветитьУдалить
  5. Кстати, в последнее время при появлении сложного бага, я предпочитаю не видео записывать, а лично показывать баг разработчику с помощью программ, которые позволяют шарить шарить экран и в это время разговаривать - GoToMeeting, TeamViewer.
    Мы активно используем эти программы для проведения онлайн митингов, так как у нас распределенная команда.

    ОтветитьУдалить
  6. Все просто =), каждый работает так, как ему удобнее. Новички по началу придерживаются зачитанных в блогах и книжках правил, но со временем у каждого появляется своя тактика.

    ОтветитьУдалить