- ... или Мое ли это дело - постить "чужие" баги?
- Читатель t-gra затронул весьма интересные вопросы которые, между прочим, живо интересовали меня самого еще на заре моей QA карьеры. Разобью их на два основных:
- 1. Хочу поинтересоваться твоим мнением по поводу разделения продукта на области с назначением ответственным за каждую область отдельного инженера. Что, все так делают?
- 2. И если инженер видит баг (даже, положим, критический баг) в другой области - это повод для него закрыть на этот баг глаза, либо это повод обвинить "хозяина" области в том, что он не нашёл баг первым?
На первый вопрос ответить сравнительно легко.
Да, все, как правило, разделяют области продукта между инеженерами, если инженеров в команде больше чем 2. Причем разделение по областям примерно симметрично тому, что делается в команде программистов. Зачем это делается? В основном преследуются следующие цели:
Да, все, как правило, разделяют области продукта между инеженерами, если инженеров в команде больше чем 2. Причем разделение по областям примерно симметрично тому, что делается в команде программистов. Зачем это делается? В основном преследуются следующие цели:
- Инженер становится опытным специалистом в cвоей области продукта, что однако не освобожает его от знания других областей, хотя-бы на базовом уровне. Что это дает?:
- более глубокое (профессиональное) тестирование
- более предсказуемое планирование тестирования, т.к. специалист более адекватно оценивает объем и время необходимого и достаточного тестирования
- при правильном управлении тестами и планировании тестирования само тестирование может проводиться любым другим инженером команды, не специализирующимся на этой области, по готовым тестам, написанным специалистом
- Симметричность распределения областей позволяет работать инженеру и программисту как-бы в паре. Таким образом это улучшает уровень коммуникции между командами, что в свою очередь приводит к:
- установлению определенной степени доверия между программистом и инженером
- быстрому обмену информацией между ними, а следовательно, меньшим временным затратам на изучение новых фич и планировие тестирования
- лучшему пониманию каждым специфики работы другого
- и, как итог - сокращению времени жизни дефекта
- Распределение областей в больших проектах служит одним из способов нематериального поощрения. Ты лучше работаешь - заслужил более сложную и ответственную область.
Более того, в очень больших проектах, по областям специализируют не только отдельных инженеров, но и целые команды.
А вот второй вопрос, бывает, учит меня чему-нибудь и по сей день.
Примерно 5 лет назад, я начинал инженером в команде, тестировавшей патчи для корпоративного продукта. Казалось-бы, продукт протестированный, продается, что там еще такого можно найти? Но находились существенные дефекты и помимо регрессий связанных с патчами. Я тоже поначалу не знал тогда что делать в такой ситуации. Понимал только, что оставлять без внимания это нельзя, но и подставлять "хозяев" области не горел особым желанием. Поэтому, я обращался к ним с описанием проблемы - а они говорили: "...да, серьезная проблема, мы о ней ничего не знаем, оформляй дефект..."... и все... никакого шума или паники. Никто не говорил мне - "...да ты ничего не понимаешь! ищи дефекты в своей области..." - и не пытался потом этот дефект оформить задним числом и т.д., никто не боялся того что дефект оформит кто-то другой и это может послужить причиной последующего обвинения в недостаточном качестве тестирования. А чего, собственно, паниковать-то? Этот дефект никто кроме меня до сих пор не обнаружил, никто из пользователей еще не жаловался, продукт продается как и продавался, для проекта ничего не изменилось, просто нашли еще один, очередной дефект, и он будет устранен как и все остальные в порядке приоритета.
Значит, как бы ни был серьезен дефект, решил я, грамотные инженеры считают, что скорее его обнаружить и исправить более важно, чем замять и пытаться "не попасть под раздачу". Поэтому, я взял за правило, если обнаружил дефект в чужой области - обязательно оформлять. При этом проконсультпроваться на предмет дефекта с хозяином области бывает очень полезно. Он быстро ответит, известный дефект или нет, есть ли связанные с ним дефекты, поможет лучше понять и изучить проблему, и оформить дефект профессиональнее, кто как не он, в конце-концов, знает свою область лучше других. А Вам это сэкономит время, даст новое знание об этой области, и поможет поддерживать командный дух в себе и других. Информационный поток внутри команды, проекта - это его движущая сила, кто выбивается из него - делает ошибку.
Ни в коем случае не пытайтесь отделаться отпиской по электронной почте типа: "...я тут у тебя нашел проблему, вот описание, разберись...". Электронная почта никогда не заменит надежности даже самой примитивной багтрэкинг системы. Вы будете уверены что "выполнили свою миссию", а адрессат этого письма не получит или не поймет что вы там наспех написали и отложит напотом, потому что не сможет адекватно оценить сходу важность или принадлежность проблемы. Ему придется воспроизвести дефект снова, чтоб описать правильно, снять скриншоты, логи,... и где гарантия что ему удастся его воспроизвести по той информации, что вы предоставили неформально в тексте своего письма?
У пилотов ВВС США есть правило, действующее в зоне боевых действий - обнаружил вражескую систему ПВО - уничтожь, независимо от того, какая у тебя боевая задача. Помните, что хуже пропущенного дефекта - потерянный дефект, т. к. у Вас остается иллюзия, что этот дефект зарегистрирован, а на самом деле... Нравится Вам это или нет, но в конечном счете, ответственность за оформление дефекта всегда лежит на том, кто его обнаружил.
А как же быть с обвинениями, наверное, спросите вы?
Многое зависит от цели, которую преследует обвинитель, от того, что стоит у него на первом месте.
Я считаю, что дефект следует в первую очередь адекватно оценить, отреагировать на него соответсвенно оценке и проконтролировать его исправление, а не раздувать, потому что Вы его нашли первым. Мы ведь не в гонках участвуем. Безусловно, если проект на пороге релиза, а Вы находите критический дефект в чужой области, то надо немедленно сообщить о нем хозяину области и его тимлиду, но нет смысла раздувать шумиху по всем инстанциям. Если до релиза действительно не так много времени, то это только помешает. Найденная проблема может оказаться действительно серьезной и чреватой дополнительными затратами на тестирование и может повлиять на дату релиза. Поэтому реагировать на нее надо быстро. Надо локализовать причину, понять нет ли еще других таких же проблем связанных с этой, оценить риски и быстро скорректировать планы на тестирование. В компаниях, разрабатывающих коммерческое ПО, среди вопросов "Кто виноват?" и "Что делать?" на первом месте стоит "Что делать?", потому что в противном случае виноваты будуь все, и вполне справедливо, т. к. в тот момент пока мы разбираемся "Кто виноват?" мы упускаем драгоценнейшее время на ответ на вопрос "Что делать?". А ответ на вопрос "Кто виноват?" оставьте хозяину области и его начальству.
А вот второй вопрос, бывает, учит меня чему-нибудь и по сей день.
Примерно 5 лет назад, я начинал инженером в команде, тестировавшей патчи для корпоративного продукта. Казалось-бы, продукт протестированный, продается, что там еще такого можно найти? Но находились существенные дефекты и помимо регрессий связанных с патчами. Я тоже поначалу не знал тогда что делать в такой ситуации. Понимал только, что оставлять без внимания это нельзя, но и подставлять "хозяев" области не горел особым желанием. Поэтому, я обращался к ним с описанием проблемы - а они говорили: "...да, серьезная проблема, мы о ней ничего не знаем, оформляй дефект..."... и все... никакого шума или паники. Никто не говорил мне - "...да ты ничего не понимаешь! ищи дефекты в своей области..." - и не пытался потом этот дефект оформить задним числом и т.д., никто не боялся того что дефект оформит кто-то другой и это может послужить причиной последующего обвинения в недостаточном качестве тестирования. А чего, собственно, паниковать-то? Этот дефект никто кроме меня до сих пор не обнаружил, никто из пользователей еще не жаловался, продукт продается как и продавался, для проекта ничего не изменилось, просто нашли еще один, очередной дефект, и он будет устранен как и все остальные в порядке приоритета.
Значит, как бы ни был серьезен дефект, решил я, грамотные инженеры считают, что скорее его обнаружить и исправить более важно, чем замять и пытаться "не попасть под раздачу". Поэтому, я взял за правило, если обнаружил дефект в чужой области - обязательно оформлять. При этом проконсультпроваться на предмет дефекта с хозяином области бывает очень полезно. Он быстро ответит, известный дефект или нет, есть ли связанные с ним дефекты, поможет лучше понять и изучить проблему, и оформить дефект профессиональнее, кто как не он, в конце-концов, знает свою область лучше других. А Вам это сэкономит время, даст новое знание об этой области, и поможет поддерживать командный дух в себе и других. Информационный поток внутри команды, проекта - это его движущая сила, кто выбивается из него - делает ошибку.
Ни в коем случае не пытайтесь отделаться отпиской по электронной почте типа: "...я тут у тебя нашел проблему, вот описание, разберись...". Электронная почта никогда не заменит надежности даже самой примитивной багтрэкинг системы. Вы будете уверены что "выполнили свою миссию", а адрессат этого письма не получит или не поймет что вы там наспех написали и отложит напотом, потому что не сможет адекватно оценить сходу важность или принадлежность проблемы. Ему придется воспроизвести дефект снова, чтоб описать правильно, снять скриншоты, логи,... и где гарантия что ему удастся его воспроизвести по той информации, что вы предоставили неформально в тексте своего письма?
У пилотов ВВС США есть правило, действующее в зоне боевых действий - обнаружил вражескую систему ПВО - уничтожь, независимо от того, какая у тебя боевая задача. Помните, что хуже пропущенного дефекта - потерянный дефект, т. к. у Вас остается иллюзия, что этот дефект зарегистрирован, а на самом деле... Нравится Вам это или нет, но в конечном счете, ответственность за оформление дефекта всегда лежит на том, кто его обнаружил.
А как же быть с обвинениями, наверное, спросите вы?
Многое зависит от цели, которую преследует обвинитель, от того, что стоит у него на первом месте.
Я считаю, что дефект следует в первую очередь адекватно оценить, отреагировать на него соответсвенно оценке и проконтролировать его исправление, а не раздувать, потому что Вы его нашли первым. Мы ведь не в гонках участвуем. Безусловно, если проект на пороге релиза, а Вы находите критический дефект в чужой области, то надо немедленно сообщить о нем хозяину области и его тимлиду, но нет смысла раздувать шумиху по всем инстанциям. Если до релиза действительно не так много времени, то это только помешает. Найденная проблема может оказаться действительно серьезной и чреватой дополнительными затратами на тестирование и может повлиять на дату релиза. Поэтому реагировать на нее надо быстро. Надо локализовать причину, понять нет ли еще других таких же проблем связанных с этой, оценить риски и быстро скорректировать планы на тестирование. В компаниях, разрабатывающих коммерческое ПО, среди вопросов "Кто виноват?" и "Что делать?" на первом месте стоит "Что делать?", потому что в противном случае виноваты будуь все, и вполне справедливо, т. к. в тот момент пока мы разбираемся "Кто виноват?" мы упускаем драгоценнейшее время на ответ на вопрос "Что делать?". А ответ на вопрос "Кто виноват?" оставьте хозяину области и его начальству.
Комментариев нет:
Отправить комментарий