Нашли проблему — завели задачу. Нашли другую — поставили новую. Если две задачи похожи — поставили связь между ними, большинство баг-трекеров позволяет это сделать.
Плюсы подхода:
Минусы:
Допустим, мы тестируем Дадату, которая умеет обрабатывать и стандартизировать данные. Туда можно грузить файлики с данными. И вот мы что-то заморочились и навыдумывали кучу ФИО, адресов, телефонов... Загрузили файл и огребли сразу несколько проблем:
— адрес из одних «ОоОоОо» рушит систему;
— телефон из всех девяток тоже все ломает;
— сложное ФИО не разобралось;
— более 1000 строк обработать нельзя, они просто удаляются;
— ...
Конечно, мы пока не знаем этих причин, у нас просто файлик рухнул из-за адреса. Что делать дальше? Я периодически сталкиваюсь с таким подходом:
— Ну вот ведь файлик есть, на нем падает! А дальше пусть разработчик разбирается, отчего.
Как будет выглядеть в таком случае баг? «Падает обработка файла». Отчего? Неизвестно, пока разработчик не посмотрит.
А дальше начинается пинг-понг:
Тут можно винить разработчика в том, что он не проверяет файл после исправления первого бага. Хотя на самом деле виноваты вы сами, не локализовав баг и поставив одну задачу вместо четырех.
Что мы имеем в итоге? Одна задача «падает файл», внутри которой два падения по самым разным причинам + зануление ФИО (вообще ничего общего с названием) + удаление строк из файла (тоже ничего общего с названием). Насколько это информативно? Думаю, понятно...
При этом на самом деле продукт то большой, под капотом скромной формочки скрывается мощная логика. Каждый компонент — отдельный большой участок кода:
И даже если баги в одном компоненте, но разные, ставьте разные задачи. А то ведь может один — простая опечатка в коде, исправить 2 минуты. А другой выглядит нестрашно, но исправление займет пару человеко-дней. Вот и получится, что висит задача «Телефоны странно обрабатываются» месяцами, хотя частично исправлена давно...
В общем, лучше локализовать первопричину бага и завести две понятные задачи вместо одной «Что-то пошло не так». Хотя, конечно, это не единственный подход.
Безусловно, бывают ситуации, когда проще поставить одну задачу на кучу мелких хочушек. Или на тестирование одного компонента первичное, или... Да разные причины могут быть для совмещения задач! Только лучше, чтобы они были осознанные, а не «там что-то упало, не знаю что, пусть разработчик смотрит».
См также:
Как заводить задачи в баг-трекер
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моих курсов, в частности, школы для начинающих тестировщиков
Плюсы подхода:
- Он помогает не продолбать какую-то ошибку (поставили баг на 15 пунктов — разработчик исправил только 13)
- Проще отслеживать статус — сколько из 15 пунктов исправлено?
- Проще искать — на точечный баг будет конкретное название, на комплексный — непонятно что.
Минусы:
- Когда тестируем большую фичу — приходится бегать по 30 связанным задачам, хотя половину можно записать одной строкой
- Если слишком увлечься, можно начать ставить разные баги на одну проблему (нелокализовали и пошли каждое проявление отдельно фиксировать)
Допустим, мы тестируем Дадату, которая умеет обрабатывать и стандартизировать данные. Туда можно грузить файлики с данными. И вот мы что-то заморочились и навыдумывали кучу ФИО, адресов, телефонов... Загрузили файл и огребли сразу несколько проблем:
— адрес из одних «ОоОоОо» рушит систему;
— телефон из всех девяток тоже все ломает;
— сложное ФИО не разобралось;
— более 1000 строк обработать нельзя, они просто удаляются;
— ...
Конечно, мы пока не знаем этих причин, у нас просто файлик рухнул из-за адреса. Что делать дальше? Я периодически сталкиваюсь с таким подходом:
— Ну вот ведь файлик есть, на нем падает! А дальше пусть разработчик разбирается, отчего.
Как будет выглядеть в таком случае баг? «Падает обработка файла». Отчего? Неизвестно, пока разработчик не посмотрит.
А дальше начинается пинг-понг:
- Разработчик подебажил, нашел причину с адресом, исправил.
- Тестировщик берет тот же файл, грузит — «не исправлено, все еще падает!»
- Разработчик опять смотрит — исправляет падение из телефонов. «Готово!»
- Тестировщик грузит файл — «Погоди, тут ФИО зануляется»
- Разработчик исправляет
- Тут тестировщик замечает, что в исходном файле было 3000 строк, а на выходе две куда-то потерялись
- ...
Тут можно винить разработчика в том, что он не проверяет файл после исправления первого бага. Хотя на самом деле виноваты вы сами, не локализовав баг и поставив одну задачу вместо четырех.
Что мы имеем в итоге? Одна задача «падает файл», внутри которой два падения по самым разным причинам + зануление ФИО (вообще ничего общего с названием) + удаление строк из файла (тоже ничего общего с названием). Насколько это информативно? Думаю, понятно...
При этом на самом деле продукт то большой, под капотом скромной формочки скрывается мощная логика. Каждый компонент — отдельный большой участок кода:
- ФИО (разбор, стандартизация)
- Адреса
- Телефоны
- Загрузчик файла
И даже если баги в одном компоненте, но разные, ставьте разные задачи. А то ведь может один — простая опечатка в коде, исправить 2 минуты. А другой выглядит нестрашно, но исправление займет пару человеко-дней. Вот и получится, что висит задача «Телефоны странно обрабатываются» месяцами, хотя частично исправлена давно...
В общем, лучше локализовать первопричину бага и завести две понятные задачи вместо одной «Что-то пошло не так». Хотя, конечно, это не единственный подход.
Безусловно, бывают ситуации, когда проще поставить одну задачу на кучу мелких хочушек. Или на тестирование одного компонента первичное, или... Да разные причины могут быть для совмещения задач! Только лучше, чтобы они были осознанные, а не «там что-то упало, не знаю что, пусть разработчик смотрит».
См также:
Как заводить задачи в баг-трекер
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моих курсов, в частности, школы для начинающих тестировщиков
Комментариев нет:
Отправить комментарий