Или вот так
Bug report - you are what you write.
Взято из книжки "Lessons Learned in Software Testing" (Cem Kaner, James Bach, Bret Pettichord):
Bug report - это главный рабочий продукт деятельности большинства тестировщиков. Благодаря этому документу у других людей составляется впечателение о вас как о профессионале. Чем лучше ваши отчеты об ошибках, чем лучше ваша репутация.
Для программистов ваш отчет - жизненно важная информация. Хороший отчет делает хорошую репутацию. Слабый отчет создает для разработчиков дополнительную нагрузку (и по их мнению, совершенно излишнюю). Если ты будешь тратить их время на ненужные вещи, они будут пытаться избегать тебя и твоей работы.
А ведь не только разработчики читают твои отчеты.
Группа поддержки хочет знать, исправлена ошибка или нет. Менеджер хочет понимать, в каком состоянии находится проект, правда ли в нем столько критических задач, сколько он видит в списке. И что он сделает? Откроет их и начнет читать. А что будет, если описание проблемы абсолютно непонятно? Отношение к автору будет скорее раздраженное - зачем он такой фигней занимается, когда релиз на носу?!
Признайтесь хотя бы сами себе - всегда ли Ваши отчеты об ошибках идеальны? Откройте все задачи, созданные полгода назад - Вы смогли бы сейчас по этому отчету воспроизвести ошибку или проверить, актуальна она или нет?
Всегда помните о том, что Вы - это то, что и как Вы пишите...
Bug report - you are what you write.
Взято из книжки "Lessons Learned in Software Testing" (Cem Kaner, James Bach, Bret Pettichord):
Bug report - это главный рабочий продукт деятельности большинства тестировщиков. Благодаря этому документу у других людей составляется впечателение о вас как о профессионале. Чем лучше ваши отчеты об ошибках, чем лучше ваша репутация.
Для программистов ваш отчет - жизненно важная информация. Хороший отчет делает хорошую репутацию. Слабый отчет создает для разработчиков дополнительную нагрузку (и по их мнению, совершенно излишнюю). Если ты будешь тратить их время на ненужные вещи, они будут пытаться избегать тебя и твоей работы.
А ведь не только разработчики читают твои отчеты.
Группа поддержки хочет знать, исправлена ошибка или нет. Менеджер хочет понимать, в каком состоянии находится проект, правда ли в нем столько критических задач, сколько он видит в списке. И что он сделает? Откроет их и начнет читать. А что будет, если описание проблемы абсолютно непонятно? Отношение к автору будет скорее раздраженное - зачем он такой фигней занимается, когда релиз на носу?!
Признайтесь хотя бы сами себе - всегда ли Ваши отчеты об ошибках идеальны? Откройте все задачи, созданные полгода назад - Вы смогли бы сейчас по этому отчету воспроизвести ошибку или проверить, актуальна она или нет?
Всегда помните о том, что Вы - это то, что и как Вы пишите...
Казалось бы - очевидная же мысль, которую каждый тестировщик понимает; но при этом не перестаю удивляться, как даже тестировщики с многолетним стажем позволяют себе такие отчёты об ошибках составлять, что попробуй по ним хоть что-то пойми... :(
ОтветитьУдалитьLike коммент :) Поддерживаю
УдалитьСпасибо за статью)
ОтветитьУдалитьда не за что :)
Удалить