Вероятно, все читали в умных книжках по тестированию, что лучше всего заносить баги по ходу их нахождения. Тестируешь – нашел баг – завел в баг-трекер – тестируешь дальше.
Но на практике очень многие тестировщики (в том числе и я) не придерживаются такого подхода. На то есть несколько причин и на этот счет каждый имеет свое мнение и свои причины.
Лично мне не удобно отрываться от процесса тестирования. Когда находишься «в потоке» и все мысли и чувства заострены под нахождение багов, то заведение отчетов об ошибках «здесь и сейчас» очень отвлекает, выбивает из процесса.
Конечно, если в процессе тестирования находится по багу в час, то тут нет никаких проблем, чтобы сразу же занести баг в трекер. Но попадаются (и не редко) такие проекты где «баг на баге сидит и багом погоняет». В такой ситуации заводить баги сразу же при их нахождении не очень удобно. Даже совсем не удобно. На переключение между тестированием и занесением уходит довольно много времени. Поэтому, я считаю вполне оправданным занесение багов не во время самого тестирования, а чуть позже.
Единственное, что я считаю неприемлемым – это заносить все найденные баги в конце дня. Во-первых, их тогда очень нудно описывать. Во-вторых, очень велика вероятность провтыкать какой-то баг и не занести. И в-третих, это плохо сказывается на здоровье программистов :), которые не видя в течении дня ни одного нового бага, радуются и спокойно, с чистой совестью собираются себе домой… И тут вдруг обнаруживают несколько десятков багов. А-а-а!!! Так и до нервного срыва недалеко :)
Я заношу баги после каждой логически законченной части тестирования. Например, после завершения проверки какой-то функциональности программы или после тестирования какой-то формы. То есть, части должны быть не большими.
А для того, чтобы не забыть баги очень удобно по ходу тестирования делать скриншоты. Ведь практически на каждый баг можно сделать скриншот. А по скриншотам уже очень легко вспоминать суть бага. Также можно делать заметки на бумаге. Завязывать узелки на память :) ... у каждого свои методы.
PS: Про узелки на память - это шутка.
А ещё лучше процесс тестирования записывать как видео, а к багу прилагать кусочек с комментариями, что в нем не так :)
ОтветитьУдалитьЯ, правда, так не делал - не тестировщик (но сочувствующий) - музыка навеяла :)
Ага! Представляю как разработчики (которые зачастую даже описание бага внимательно не читают)будут сидеть и смотреть это видео :)
ОтветитьУдалитьЯ записывала несколько раз воспроизведение бага на видео, но только для особо сложновоспроизводимых багов. Для большинства обычных багов это однозначно не работает.
Неправда,
ОтветитьУдалитьвидео очень много показать может.
Как быть с багами, которые разработчик не может репродуцировать?
Разработчик, может увидеть скрытые детали, которые на его компе не проявляются
Это как в пословице, лучше один раз увидеть, чем сто раз услышать(прочесть)
Я ж не говорю, что видео это плохо. Видео очень помогает в сложных случаях, и конечно с багами, которые разработчик не смог воспроизвести.
ОтветитьУдалитьЯ говорю о том, что записывать видео для всех багов - это перебор. Согласитесь, что большинство багов прекрасно воспроизводится. И простых скриншотов более чем достаточно.
Кстати, в последнее время при появлении сложного бага, я предпочитаю не видео записывать, а лично показывать баг разработчику с помощью программ, которые позволяют шарить шарить экран и в это время разговаривать - GoToMeeting, TeamViewer.
ОтветитьУдалитьМы активно используем эти программы для проведения онлайн митингов, так как у нас распределенная команда.
Все просто =), каждый работает так, как ему удобнее. Новички по началу придерживаются зачитанных в блогах и книжках правил, но со временем у каждого появляется своя тактика.
ОтветитьУдалить