Когда вы заводите задачу, ее нужно «продать» команде. Вы должны убедить разработчика, что:
Казалось бы, зачем? Все же люди умные в команде. Раз я поставил задачу, значит, это баг! Значит, надо фиксить!
Но умные люди не любят действовать бездумно. Им надо понимать, что и зачем они делают. Тем более что разработчик может найти дополнительные подводные камни в коде, если поймет исходную задачу. А вот есть он увидит такой баг:
То реакция будет примерно такой:
Почему это баг? И, главное, в чем именно баг?
Из такого описания непонятно, почему должно быть именно так, и что конкретно здесь неправильно.
Дальше ситуация развивается еще интереснее. Коллега-тестировщик читает ваш баг, у него появляются вопросы «Но почему?», он приходит с ними к вам. Вполне возможно, что действительно надо именно так. И вы даже поясняете, почему. Устно. Одному коллеге.
Но потом баг читает другой коллега. Еще один тестировщик, разработчик, менеджер... Большая у вас команда? Каждый видит баг, не понимает, приходит к вам и отвлекает, отвлекает, отвлекает...
Вроде ответить на вопрос недолго. Но вы же мыслями в другой задаче уже. Это надо отвлечься от текущих дел, вспомнить, о чем идет речь, вспомнить, почему вы именно так считаете, пояснить... А потом возвращаешься к работе и понимаешь, что забыл, о чем думал, пока не отвлекли.
А вот записали бы в баге сразу то, что говорите устно — никто бы не отвлекал! Хотя отвлечение коллегой — не единственная причина записать обоснование.
Это только в идеальном мире баги правятся сразу же. В реальной жизни их могут отложить на релиз-другой. За это время вы можете просто забыть, почему задачу нужно делать «именно так, а не иначе». Чтобы не забывать, запишите обоснование.
Я провожу курсы для начинающих тестировщиков. Вот где особенно нужно обоснование! А то иногда читаешь и понять не можешь, «но зачем это делать??». Всякие космолеты ребята предлагают, вплоть до «Сделать новогодний подарок клиентам, оставившим у нас более 100 тысяч рублей — скидку 5%. Остальные нищеброды остаются без скидок».
Учитесь обосновывать свою точку зрения! Будете перечитывать свои же баги спустя год, и еще скажете мне «спасибо!»
См также:
Паттерны и антипаттерны обоснования багов (ВИДЕО) — о том, как правильно обосновывать
Как заводить задачи в баг-трекер — что еще нужно, кроме обоснования
- это действительно баг;
- его необходимо исправить;
- его нужно исправить именно так, как мы сказали.
Казалось бы, зачем? Все же люди умные в команде. Раз я поставил задачу, значит, это баг! Значит, надо фиксить!
Но умные люди не любят действовать бездумно. Им надо понимать, что и зачем они делают. Тем более что разработчик может найти дополнительные подводные камни в коде, если поймет исходную задачу. А вот есть он увидит такой баг:
Шаги для воспроизведения
Загрузить отчет, посмотреть на итоговую цифру.
Результат
57,6
Ожидаемый результат
57.9
То реакция будет примерно такой:
Почему это баг? И, главное, в чем именно баг?
- Должна быть точка вместо запятой?
- Должно быть 9 вместо 6?
- И то, и то надо исправить или все же баг один, а во втором месте я просто опечаталась?
Из такого описания непонятно, почему должно быть именно так, и что конкретно здесь неправильно.
Дальше ситуация развивается еще интереснее. Коллега-тестировщик читает ваш баг, у него появляются вопросы «Но почему?», он приходит с ними к вам. Вполне возможно, что действительно надо именно так. И вы даже поясняете, почему. Устно. Одному коллеге.
Но потом баг читает другой коллега. Еще один тестировщик, разработчик, менеджер... Большая у вас команда? Каждый видит баг, не понимает, приходит к вам и отвлекает, отвлекает, отвлекает...
Вроде ответить на вопрос недолго. Но вы же мыслями в другой задаче уже. Это надо отвлечься от текущих дел, вспомнить, о чем идет речь, вспомнить, почему вы именно так считаете, пояснить... А потом возвращаешься к работе и понимаешь, что забыл, о чем думал, пока не отвлекли.
А вот записали бы в баге сразу то, что говорите устно — никто бы не отвлекал! Хотя отвлечение коллегой — не единственная причина записать обоснование.
Я не только тестирую свое приложение, но и общаюсь с Заказчиками. В том числе принимаю их хотелки и пожелания. А потом завожу задачи в нашем баг-трекере.
Как-то приходит ко мне разработчик:
— Оль, вот тут твоя задача TEST-555. Ты хочешь, чтобы задача Х умела преобразовывать любой формат даты. А нафига?? Это делать долго, при этом никому не нужно.
— Нужно! Мне Заказчик жаловался, что у них дата приходит в другом формате и обработка файла в итоге падает.
— А кто жаловался? Давай уточним, откуда такие данные идут.
— Хм... А и правда, кто?
Тут я с ужасом понимаю, что... Я не помню, кто меня просил о доработке! Вот кто-то просил, это помню. А кто именно — нет. А я с шестью разными Заказчиками общаюсь...
Как мне найти исходный запрос? Он может быть в почте, но там шесть папок заказчиков. Название письма может не совпадать с содержимым, ведь обычно как происходит:
А еще некоторые заказчики мне звонят. Или пишут в скайп. Или в телеграмм. Так где же мне найти ответ, как вспомнить, кто и зачем меня просил о доработке?
- Мы пишем письмо «Описание релиза 3.8».
- Заказчик читает в нем «задача обработки телефонов» и в голове щелкает «О, телефоны! Точно! Я же хотел вот это спросить...»
- Он пишет нам свой вопрос, который вообще не про релиз, но заголовок остается «Описание релиза 3.8»
- ...
Это только в идеальном мире баги правятся сразу же. В реальной жизни их могут отложить на релиз-другой. За это время вы можете просто забыть, почему задачу нужно делать «именно так, а не иначе». Чтобы не забывать, запишите обоснование.
Я провожу курсы для начинающих тестировщиков. Вот где особенно нужно обоснование! А то иногда читаешь и понять не можешь, «но зачем это делать??». Всякие космолеты ребята предлагают, вплоть до «Сделать новогодний подарок клиентам, оставившим у нас более 100 тысяч рублей — скидку 5%. Остальные нищеброды остаются без скидок».
Учитесь обосновывать свою точку зрения! Будете перечитывать свои же баги спустя год, и еще скажете мне «спасибо!»
См также:
Паттерны и антипаттерны обоснования багов (ВИДЕО) — о том, как правильно обосновывать
Как заводить задачи в баг-трекер — что еще нужно, кроме обоснования
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Комментариев нет:
Отправить комментарий