Продолжу практику выписывания интересных советов из книжки Lesson Learned in Software Testing (№ 153), в вольном переводе (глядишь, заинтересуетесь и прочтете их все уже в оригинале):
Вы - адковат Заказчика. В конечном счете ваша работа - сообщать о проблемах, с которыми могут столкнуться пользователи. У программистов и менеджеров могут возникнуть трудности с понимаем этих проблем. В таком случае, вам придется сообщать неприятные новости. Но вас и не должны любить за это. Но если вы найдете вероятную проблему и связно и понятно сообщите о нем, то заслужите уважение. И, когда вы описываете проблему, придерживайтесь следующих принципов:
1. Описывайте багу четко. Шаг за шагом, выкинув все ненужные телодвижения. Кратко, но понятно. Описывайте симптомы аккуратно. Сделайте так, чтобы ваш баг-репорт был просто для восприятия и воспроизведения. Ваша работа будет иметь ценность благодаря тому, что вы покажите тем самым уважение к времени разработчика.
2. Базируйте свои суждения на наблюдении за поведением продукта. Часто вы используете продукт чаще, чем кто-либо еще. Что делает вас экспертом во внешнем взаимодействии с программой. Но при этом вы не являетесь экспертом во внутреннем поведении. Ну так и сообщайте о том, что вы видите и не тратьте много времени на попытки понять первопричину проблемы.
3. Если бага не воспроизводится, покажите, как вы пытались ее воспроизвести. Когда вы заносите в баг-трекер невоспроизводимую ошибку, хорошее впечатление оставляет уже то, что вы провели некое исследование, указали, что и как делали, какие инструменты использовали. И плохое впечатление оставит тот факт, что вы быстро сдались и сбросили эту работу на программистов при первой же трудности. Покажите уважение ко времени разработчиков, напишите о том, что пытались сделать сами, без их помощи!
4. Доставляйте плохие новости напрямую. Не идите в обход людей, с которыми еще хотите нормально работать. Скажите им, что эскалируете проблему выше, прежде чем сделать это.
5. Не говорите, что знаете то, чего на самом деле не знаете вовсе. Например, если вы не знаете, насколько серьезна проблема, не выдумывайте приоритет. Или узнайте его (у технической поддержки, например), или сидите тихо.
6. Не преувеличивайте в своих баг репортах. Не минимизируйте проблему и не запугивайте или не умасливайте игнорированием или сокрытием того, что вы видели. Спрячьте свое оружие - если вы видите проблему, сообщите о ней и эскалируйте, если вы чувствуете, что это необходимо. Стройте репутацию честного парня и заслужите уважение.
7. Если вы честны, можете развивать свою компетентность. Если вы не честны, ваша компетентность никого не волнует.
По-моему, автор очень и очень прав по всем пунктам! Ну вот разве что сейчас я бы поспорила насчет "вы не знаете, что творится в коде", многих туда пускают. А многих и не пускают, так что замечание справедливое.
Всегда помните о правиле 20 минут! Сначала поизучайте проблему сами, а только потом просите о помощи, цените время своих коллег!
Вы - адковат Заказчика. В конечном счете ваша работа - сообщать о проблемах, с которыми могут столкнуться пользователи. У программистов и менеджеров могут возникнуть трудности с понимаем этих проблем. В таком случае, вам придется сообщать неприятные новости. Но вас и не должны любить за это. Но если вы найдете вероятную проблему и связно и понятно сообщите о нем, то заслужите уважение. И, когда вы описываете проблему, придерживайтесь следующих принципов:
1. Описывайте багу четко. Шаг за шагом, выкинув все ненужные телодвижения. Кратко, но понятно. Описывайте симптомы аккуратно. Сделайте так, чтобы ваш баг-репорт был просто для восприятия и воспроизведения. Ваша работа будет иметь ценность благодаря тому, что вы покажите тем самым уважение к времени разработчика.
2. Базируйте свои суждения на наблюдении за поведением продукта. Часто вы используете продукт чаще, чем кто-либо еще. Что делает вас экспертом во внешнем взаимодействии с программой. Но при этом вы не являетесь экспертом во внутреннем поведении. Ну так и сообщайте о том, что вы видите и не тратьте много времени на попытки понять первопричину проблемы.
3. Если бага не воспроизводится, покажите, как вы пытались ее воспроизвести. Когда вы заносите в баг-трекер невоспроизводимую ошибку, хорошее впечатление оставляет уже то, что вы провели некое исследование, указали, что и как делали, какие инструменты использовали. И плохое впечатление оставит тот факт, что вы быстро сдались и сбросили эту работу на программистов при первой же трудности. Покажите уважение ко времени разработчиков, напишите о том, что пытались сделать сами, без их помощи!
4. Доставляйте плохие новости напрямую. Не идите в обход людей, с которыми еще хотите нормально работать. Скажите им, что эскалируете проблему выше, прежде чем сделать это.
5. Не говорите, что знаете то, чего на самом деле не знаете вовсе. Например, если вы не знаете, насколько серьезна проблема, не выдумывайте приоритет. Или узнайте его (у технической поддержки, например), или сидите тихо.
6. Не преувеличивайте в своих баг репортах. Не минимизируйте проблему и не запугивайте или не умасливайте игнорированием или сокрытием того, что вы видели. Спрячьте свое оружие - если вы видите проблему, сообщите о ней и эскалируйте, если вы чувствуете, что это необходимо. Стройте репутацию честного парня и заслужите уважение.
7. Если вы честны, можете развивать свою компетентность. Если вы не честны, ваша компетентность никого не волнует.
По-моему, автор очень и очень прав по всем пунктам! Ну вот разве что сейчас я бы поспорила насчет "вы не знаете, что творится в коде", многих туда пускают. А многих и не пускают, так что замечание справедливое.
Всегда помните о правиле 20 минут! Сначала поизучайте проблему сами, а только потом просите о помощи, цените время своих коллег!
Комментариев нет:
Отправить комментарий