w_bf (w_bf) wrote,
w_bf
w_bf

Categories:

Lesson 58

Друзья, эту уютненькую читают ПМы, тестировщики и программисты?
Как вы считаете, кто должен определять приоритет баг, приоритет работ по исправлению багов?
Проект еще не выдан клиентам. Но вроде уже скоро. Я - не знаю. По ощущениям - что-то не так. Что именно - не могу понять.

Ответ очень важен для меня, особо реквестирую в тред айронбага, картмендуума, астеникса, кодера 117, крузайдера, дибра, думтеста, джекса альтерго, конекошам, редфокса, феликса, ваху, френьку и вол-овл. Ну а кто аргументирует или расскажет, как у них - вообще молодцы.

Кто определяет приоритет багов?

Руководитель проекта
6(28.6%)
Лид тестеров
3(14.3%)
Лид аналитиков
3(14.3%)
Лид разработчиков
2(9.5%)
Три вышеперечисленных лида коллегиально
3(14.3%)
Тестеры коллегиально
3(14.3%)
Аналитики коллегиально
0(0.0%)
Разработчики коллегиально
1(4.8%)
Все вместе (можно, но проблематично)
0(0.0%)



Слово Канеру:

Ваш багрепорт представляет вас.

Обычно вы не присутствуете, когда читают ваш багрепорт. Когда ты пишешь репорт, ты просишь программиста (который не у тебя в подчинении) сделать еще кое-какую работу. Программисты редко имеют достаточно времени, чтоб починить все баги. Многие баги чинят спустя несколько часов - или через выходные. Вы же просите их потратить это время на багу, которую вы нашли.

В некоторых компаниях (особенно в тех, кде разработка подходит к концу), менеджеры решают, что исправлять. Лиц, принимающих решения, можно назвать группой контроля за изменениями. (В других компаниях эта группа называется командой проекта, командой сортировки, боевой командой, командой ревью багов). Эти люди определяют стоимость изменения, оценивают время и риски задачи.

Чтоб получить исправленную ошибку, ты должен убедить группу Контроля Изменений заапрувить работу по исправлению бага или убедить программиста исправить его по собственной инициативе (например поздно ночью, когда группа не работает. Убеждение людей за спиной группы может быть правильным решением в одних компаниях и неправильным в других, это зависит от вашей корпоративной культуры). Багрепорт - главное (часто единственное) средство убеждения людей. Вы можете иметь возможность защитить баг перед группой, но во многих компаниях только тестировщики (с тест-лидом и тест-менеджером обсуждают баги. От того, как хорошо вы защитите багу будет зависеть судьба вашего багрепорта.

Tags: bret pettichord, cem kaner, chapter 4, james bach, lessons learned in software testing, вопрос, лекции, программисты, процесс тестирования
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 34 comments