«

»

Май 11

Мысли о баг-репортах. Часть II.1. «Description» оно же «Описание»

Часть I здесь

Реальные описания дефектов, которые я встречал, и некоторые — делал сам 😉

«Использовав поиск я получил java script ошибку»
«Не получается скопировать на флешку логи»

«Поведение программы не соответствует здравому смыслу»
Или просто копирование заголовка.

Один из моих самых любимых примеров: «Горизонт города завален» (хорошо, что баг создавал художник для художников. Шедеврально, тем не менее)
Весьма детальные описания, не так ли?

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

«У меня что, нет более важной работы, чем писать детальное и подробное описание?» Нет, нет, конечно же есть. Очень важная — погнать тестировать приложение дальше. А дефект? Да на пальцах можно будет объяснить программисту. Да хоть 10 дефектов. Ведь главное найти миллионы и миллиарды ошибок и… И вообще программист уточнит!
Вышенаписанное — ересь, а не руководство к действию.

А если серьезно, всё это, конечно, здорово: и драйв от нахождения ошибок и адреналин от того, что было потрачено несколько часов,  найдено несколько простых действий и вуаля — приложение ломается так, что мама-не горюй. Только вот, не надо забывать, что секретарей сидящих рядом с тестировщиком, для стенограмм ошибок, как-то не замечено на просторах IT отрасли. Или есть такие счастливцы? 🙂

Пишите простые и однозначные шаги, с нумерацией.
Почему бы не написать как для робота:

  1. Встать в начало координат (точка 0,0)
  2. Сделай шаг вперёд.
  3. Повернись по часовой стрелке на 90°.
  4. Сделать шаг вперёд.
  5. Сделать шаг вперёд.
  6. Повернуться против часовой стрелки на 90°
  7. Повернуться против часовой стрелки на 90°

Ведь не сложно?

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

Резонный вопрос — зачем нумерация?
Представьте ситуацию, когда вы дефект обсуждаете по телефону, и необходимо прояснить какой-нибудь шаг.
Ситуация когда нет нумерации:
— Ну в третьем шаге — я не могу повернуть, у меня валится ошибка!
— В третьем, это в каком? Откуда счёт начинаем?
— Это тот шаг, который после шага впёред.

Весело, да?:)
Это хорошо ещё, если форматирование без нумерации не поменяли, и не сделали всё описание в одну строчку. Поверьте, такое бывает.

Часть II.2 здесь.

Поделиться в соц. сетях

Опубликовать в Facebook
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Яндекс

4 комментария

3 пинга

Перейти полю для комментария

  1. Ellesta

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

    1. Сергей Атрощенков

      А случаи, которые тестируются дополнительно — нумеруются? 🙂

      1. Ellesta

        Не совсем поняла вопрос.
        Попробую на примере. Я тестирую финансовое приложение. В описании сказано, что был создан ордер и там-то появилась такая-то ошибка. Дефект в статусе Fixed, мне нужно проретестить и убедиться. Но есть несколько типов ордеров. Я проверяю один такого же типа как в дефекте и еще 3 дополнительно. Соответственно, получаю пункты 1, 2, 3, 4 с результатами ретеста 🙂

        1. Сергей Атрощенков

          Понял, спасибо 🙂

  1. Мысли о баг-репортах. Часть I. «Title» он же «Заголовок» | BarbaricQA.com

    […] II.1 здесь Tweet Поделиться Запись опубликована в рубрике […]

  2. Итоговое руководство по составлению отчетов об ошибках. | BarbaricQA.com

    […] Мысли о баг-репортах. Часть II.1. «Description» оно же «Описани… […]

Комментарии были заблокированны