Home

Автор: Джон Эндрюс (John Andrews)

Оригинал статьи: https://testingfromthehip.wordpress.com/2016/12/14/raise-problems-not-bugs/

Перевод: Ольга Алифанова

Недавно я написал в своем твиттере примерно следующее:

"Когда рассказываете о чем-то, найденном в процессе тестирования, называйте это проблемой, а не багом. Вы поразитесь, насколько лучше вас начнут понимать".

Причина для этой статьи в том, что, по моему мнению, наша ценность как тестировщиков – это наша способность исследовать продукт и информировать команду о потенциальных проблемах. Мне нравится слово "проблема" куда больше, чем "баг", и я постараюсь объяснить, почему.

Первая причина: "Баг" предполагает, что мы привратники на пути качества.

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

Вторая причина: "Баг" может означать, что вам не нужна помощь.

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

Третья причина: "Баг" может предполагать, что все требуемое уже сделано.

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

Четвертая причина: "Баг" предполагает, что что-то нужно исправить.

Эта классификация предполагает, что в ПО есть проблема, нуждающаяся в исправлении. Она действительно в нем нуждается? Откуда вы это знаете, откуда такая уверенность?

Пятая причина: "Баг" предполагает, что у пользователя будет проблема с тем, что вы нашли.

Если вы называете что-то "багом", то вы можете предполагать, что реальный пользователь тоже столкнется с проблемой, которую вы нашли. Но столкнется ли он с ней? Откуда вы это знаете? То, что кажется вам проблемой, может не быть проблемой для пользователя. Выясните это, если можете.

Шестая причина: "Баг" может звучать оскорбительно для разработчиков.

Когда вы называете что-то багом, это звучит угнетающе для команды, и особенно для разработчиков. Люди могут прдеположить, что что-то было упущено или неверно внедрено разработкой. Однако проблема может проистекать из плохого дизайна, противоречивых или отсутствующих требований, устаревшей спецификации, плохого удобства использования или неверного/ошибочного тестирования. Говоря о чем-то, как о "проблеме", вы подключаете всю команду к расследованию исходных причин ее возникновения. Вы не ищете виноватых, вы не определяете причины проблемы неверно. Хотите – верьте, хотите – нет, но многие ваши коллеги обожают расследовать причины проблем не меньше, чем вы!

Седьмая причина: "Баг" может вызвать скепсис

Поиск потенциальных багов – это, безусловно, важная часть нашей работы. Но когда мы определяем что-то как баг, то коллеги могут начать относиться к этому скептически. "Ну ты нашел еще один баг, отправь его разработчику, который за него отвечает". Лучше, если ваши коллеги более вовлечены в этот процесс. Я выяснил, что если я описываю нечто как проблему, всей команде интересно, в чем дело. А если я говорю о багах, коллеги, которых этот баг не затрагивает, не интересуются им. Сделайте так, чтобы вашим коллегам было интересно, чтов ы делаете!

Я не говорю о том, что вы не должны репортить баги. Конечно, некоторые из них очевидны. Однако постарайтесь, чтобы у вас вошло в привычку называть все, что вы находите, проблемами, потенциальными проблемами или наблюдениями, и понаблюдайте за реакцией команды. Я надеюсь, ваши коллеги откликнутся так же, как мои. Если это не так, не возвращайтесь к старым методам и трону ответственного за качество.

Продолжайте пробовать, и рано или поздно у вас получится.

Обсудить в форуме