Lesson 85
Слово Канеру:
Сообщайте о проблеме, не пытайтесь ее решить.
Без изучения лежащего в основе проблемы кода, вы не в состоянии знать все причины сбоя. Очень часто мы видим репорты в которых внимание тестировщика настолько направлено на причины сбоя, что в них нет достаточно данных для программиста, чтоб понять, что на самом деле видел тестировщик.
Некоторые программисты отклоняют репорты, «решения» которых неверны, не учитывая лежащей в основе проблемы. Не позволяйте легко отклонить ваш репорт.
Принять решение - что делать с багой - задача архитектора. Например, вы обнаружили сообщение об ошибке, исчезающее, как только пользователь двигает мышью, что создает проблемы для прочтения этого сообщения. Вы могли бы захотеть написать репорт так: «сообщение об ошибке должно находиться в модальном окне, пока пользователь не закроет его». Если вы так сделаете, то не удивляйтесь, если архитектор отправит вам записку с пожеланием не лезть не в свои дела. Дело в том, что есть несколько решений проблемы и архитектор выберет то, которое, как он считает, лучше подходит.
Другая проблема с репортами, ориентированными на решение проблем в том, что многие тестировщики настолько погружены в свое видение решения проблемы, что не могут предоставить ясную, понятную информацию о сбое. Если тестировщик неправильно понимает причину сбоя, предложенное им решение в лучшем случае ничего не стоит. А часто они еще хуже, чем бесполезные, так как тестировщик непреднамеренно пропускает важную информацию или пишет репорт, обращающий внимание программистов на неверные детали. Подобные иногда приносят много радости программистам. Вы не можете быть человеком, предположения которого насколько невежественны, что над ним смеются.
Лучший способ сообщить о проблеме исчезающего сообщения - сказать так: «сообщение об ошибке появилось, но я не смог его прочитать, так как оно исчезло, когда я передвинул мышь». Если у вас хорошие отношения с архитектором, вы могли бы добавить: «модальность диалога могла бы решить поблему». Заметим, что такое предположение не звучит как императив.
Если известно, что некоторые части программы должны работать строго определенным образом, то разницы между проблемой и отсутствием решения действительно нет. В потивном случае, вы переступаете черту.
Сообщайте о проблеме, не пытайтесь ее решить.
Без изучения лежащего в основе проблемы кода, вы не в состоянии знать все причины сбоя. Очень часто мы видим репорты в которых внимание тестировщика настолько направлено на причины сбоя, что в них нет достаточно данных для программиста, чтоб понять, что на самом деле видел тестировщик.
Некоторые программисты отклоняют репорты, «решения» которых неверны, не учитывая лежащей в основе проблемы. Не позволяйте легко отклонить ваш репорт.
Принять решение - что делать с багой - задача архитектора. Например, вы обнаружили сообщение об ошибке, исчезающее, как только пользователь двигает мышью, что создает проблемы для прочтения этого сообщения. Вы могли бы захотеть написать репорт так: «сообщение об ошибке должно находиться в модальном окне, пока пользователь не закроет его». Если вы так сделаете, то не удивляйтесь, если архитектор отправит вам записку с пожеланием не лезть не в свои дела. Дело в том, что есть несколько решений проблемы и архитектор выберет то, которое, как он считает, лучше подходит.
Другая проблема с репортами, ориентированными на решение проблем в том, что многие тестировщики настолько погружены в свое видение решения проблемы, что не могут предоставить ясную, понятную информацию о сбое. Если тестировщик неправильно понимает причину сбоя, предложенное им решение в лучшем случае ничего не стоит. А часто они еще хуже, чем бесполезные, так как тестировщик непреднамеренно пропускает важную информацию или пишет репорт, обращающий внимание программистов на неверные детали. Подобные иногда приносят много радости программистам. Вы не можете быть человеком, предположения которого насколько невежественны, что над ним смеются.
Лучший способ сообщить о проблеме исчезающего сообщения - сказать так: «сообщение об ошибке появилось, но я не смог его прочитать, так как оно исчезло, когда я передвинул мышь». Если у вас хорошие отношения с архитектором, вы могли бы добавить: «модальность диалога могла бы решить поблему». Заметим, что такое предположение не звучит как императив.
Если известно, что некоторые части программы должны работать строго определенным образом, то разницы между проблемой и отсутствием решения действительно нет. В потивном случае, вы переступаете черту.