Для начала введем понятие:
Тестировщик класса «тролль» — сотрудник отдела тестирования, радующийся найденному багу в программном продукте, и жаждущий сообщить об этом разработчику с присущей данному событию эмоциональностью.
Я — тестировщик класса «тролль», полностью это осознаю, горжусь и считаю единственно верным подходом.
Распространенные аргументы против данного подхода
Комментарии от гуру-тестирования
«Такое поведение присуще начинающим тестировщикам, которые не понимают всей сути процесса разработки и тестирования в частности»
Вряд ли… Этап «кликерства» я проходил. Не спорю, непомерная радость от найденных багов присуща всем начинающим тестировщикам. Речь идет о другом. Тестировщик, находя баг, показывает результат своей работы. И чем сложнее повторить этот баг и чем критичнее он, тем больше удовлетворения тестировщик получает при его регистрации. Считаю это адекватной реакцией. Тестировщик работал, тестировщик нашел, тестировщик вправе быть удовлетворенным своей работой.
Чем меньше тестировщик радуется найденному багу, тем меньше он их хочет находить. Чем меньше хочется находить, тем меньше они ищутся. Чем меньше ищутся, тем меньше находятся. Чем меньше находятся, тем больше пропускаются.
В итоге: чем меньше радости от бага — тем хуже получается продукт. Вот такая вот нехитрая логика.
Комментарии от менеджеров
«Такое поведение тестировщиков создает негативную атмосферу в коллективе и постоянные конфликты»
У всех свои тараканы. К тому же, повторюсь, я не имею ввиду начинающих тестировщиков, кричащих «Бааааг!!!!» по малейшему поводу.
Польза таких взаимоотношений в том, что так рождается конкуренция. А конкуренция в профессиональном плане важна для обеих сторон. С этим сложно поспорить.
Что плохого в том, что разработчику постоянно тыкают в его ошибки? Это понижает его самооценку? У него пропадает все желание работать в такой команде? А если замечания обоснованны? Если разработчик сам в этом виноват? Может быть он просто не может признать свои ошибки? Это уже проблема восприятия и самоорганизации. Это уже к психологу.
Баги — это естественный и непременный атрибут при разработке. Все бажат. Все. И тестировщики, кстати, тоже.
Комментарии от несведущих программистов
«Тестировщики, знай себе, ходят и кричат о найденных ошибках. Их-то никто не проверяет»
Проверяет. Заказчик. И осознание того, что тестировщик пропустил баг давит на его нервную систему гораздо сильнее, чем на программиста.
Комментарии от приверженцев Agile
«Существует общекомандная ответственность за качество продукта. Таким поведением тестировщик „отстраняется“ от коллектива. Нужно пытаться улучшить продукт, а не критиковать его».
Если где-то написано, что критический взгляд на продукт не приветствуется в условиях гибкой разработки, дайте ссылку. Я хочу на это посмотреть.
В одной из книг по гибкому тестированию я нашел очень хорошую фразу, отражающую отношение к работе в целом: «Квалификация без мотивации — ничто!». И желание пропустить как можно меньше багов и есть та самая мотивация. Чем меньше удовольствия от нахождения багов, тем меньше мотивация. Таково мою сугубо-личное скромное ИМХО.
Советы о том, как вместо тестировщика-«тролля» не стать тестировшиком-«занудой»
Не старайтесь во чтобы то ни стало найти хоть какой-то баг. Да, все баги не найдешь. Поиск багов не должен превращаться в паранойю. Стремясь за количеством, можно понизить качество. Чем критичнее баги вы находите, тем ценнее вы как специалисты. Но помните: каждый баг должен быть зафиксирован.
Умейте обосновывать найденный баг. Вам часто будут говорить эту давно избитую фразу «Это не баг, это — фича». Поэтому, прежде чем давать волю эмоциям, удостоверьтесь, что это действительно баг. Иначе, рискуете попасть в неловкую ситуацию. Но если вы точно уверены в своей правоте, идите и доказывайте это.
Сохраняйте в себе это деструктивное желание чего-нибудь сломать. Оно поможет вам получать удовольствие от своей работы.
И помните!
Тестирование — это не профессия и не род деятельности. Это призвание.
ссылка на оригинал статьи http://habrahabr.ru/post/178873/
Добавить комментарий