среда, 28 ноября 2018 г.

Зачем нужно обоснование в баге

Когда вы заводите задачу, ее нужно «продать» команде. Вы должны убедить разработчика, что:

  • это действительно баг;
  • его необходимо исправить;
  • его нужно исправить именно так, как мы сказали.

Казалось бы, зачем? Все же люди умные в команде. Раз я поставил задачу, значит, это баг! Значит, надо фиксить!

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

Шаги для воспроизведения
Загрузить отчет, посмотреть на итоговую цифру. 
Результат
57,6 
Ожидаемый результат
57.9

То реакция будет примерно такой:



Почему это баг? И, главное, в чем именно баг?

  • Должна быть точка вместо запятой?
  • Должно быть 9 вместо 6?
  • И то, и то надо исправить или все же баг один, а во втором месте я просто опечаталась?

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

Дальше ситуация развивается еще интереснее. Коллега-тестировщик читает ваш баг, у него появляются вопросы «Но почему?», он приходит с ними к вам. Вполне возможно, что действительно надо именно так. И вы даже поясняете, почему. Устно. Одному коллеге.





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

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



А вот записали бы в баге сразу то, что говорите устно — никто бы не отвлекал! Хотя отвлечение коллегой — не единственная причина записать обоснование.

Я не только тестирую свое приложение, но и общаюсь с Заказчиками. В том числе принимаю их хотелки и пожелания. А потом завожу задачи в нашем баг-трекере. 
Как-то приходит ко мне разработчик: 
— Оль, вот тут твоя задача TEST-555. Ты хочешь, чтобы задача Х умела преобразовывать любой формат даты. А нафига?? Это делать долго, при этом никому не нужно. 
— Нужно! Мне Заказчик жаловался, что у них дата приходит в другом формате и обработка файла в итоге падает. 
— А кто жаловался? Давай уточним, откуда такие данные идут. 
— Хм... А и правда, кто? 
Тут я с ужасом понимаю, что... Я не помню, кто меня просил о доработке! Вот кто-то просил, это помню. А кто именно — нет. А я с шестью разными Заказчиками общаюсь...
Как мне найти исходный запрос? Он может быть в почте, но там шесть папок заказчиков. Название письма может не совпадать с содержимым, ведь обычно как происходит:
  • Мы пишем письмо «Описание релиза 3.8».
  • Заказчик читает в нем «задача обработки телефонов» и в голове щелкает «О, телефоны! Точно! Я же хотел вот это спросить...»
  • Он пишет нам свой вопрос, который вообще не про релиз, но заголовок остается «Описание релиза 3.8»
  • ...
 А еще некоторые заказчики мне звонят. Или пишут в скайп. Или в телеграмм. Так где же мне найти ответ, как вспомнить, кто и зачем меня просил о доработке?

Это только в идеальном мире баги правятся сразу же. В реальной жизни их могут отложить на релиз-другой. За это время вы можете просто забыть, почему задачу нужно делать «именно так, а не иначе». Чтобы не забывать, запишите обоснование.

Я провожу курсы для начинающих тестировщиков. Вот где особенно нужно обоснование! А то иногда читаешь и понять не можешь, «но зачем это делать??». Всякие космолеты ребята предлагают, вплоть до «Сделать новогодний подарок клиентам, оставившим у нас более 100 тысяч рублей — скидку 5%. Остальные нищеброды остаются без скидок».

Учитесь обосновывать свою точку зрения! Будете перечитывать свои же баги спустя год, и еще скажете мне «спасибо!» Wink ;)

См также:
Паттерны и антипаттерны обоснования багов (ВИДЕО) — о том, как правильно обосновывать
Как заводить задачи в баг-трекер — что еще нужно, кроме обоснования

PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков

Комментариев нет:

Отправить комментарий