Почему это токсичный вопрос и что вам следует задать вместо него
На следующий день после выпуска важный клиент сообщает о серьезной ошибке в производственной среде. Звучат сигналы тревоги, гудят пейджеры и разлетаются электронные письма. Команда бросает все и взрывается в аварийном режиме, когда исправление быстро внедряется в производство. Обновление проверено, покупатель успокоен, и все вздыхают с облегчением. Позже менеджеры встречаются со старшими менеджерами на закрытых встречах, чтобы обсудить такие вещи, как «как-это-могло-случиться» и «почему-это-никогда-больше не повторится».
На следующий день те же самые менеджеры, все еще не оправившиеся от жареного теста, полученного накануне, обращаются к контролю качества и спрашивают: «Почему вы не нашли ошибку?»
Многим этот вопрос кажется очевидным, и большинство менеджеров задают его с позиции честного исследования и понимания. QA играют важную, почти центральную роль в поиске ошибок. В производственной среде была обнаружена ошибка, поэтому следующий естественный шаг - спросить QA, почему они не обнаружили ошибку.
К сожалению, это не совсем здоровый вопрос. Даже с хорошими намерениями, прямой запрос QA приведет к токсичной культуре обвинений. Есть вопрос, который следует задать, но он тонко, но очень важен, и он не направлен на QA.
Прежде чем мы перейдем к этому, давайте поговорим немного о том, почему «Почему вы не нашли эту ошибку?» так плохо.
QA, Bug Nets и качество программного обеспечения
Многие команды нанимают человека или роль, посвященную качеству, обычно называемую QA, QE или «тестировщиком». Для простоты я назову их все QA. Эти люди обладают глубоким пониманием предметной области, являются критически мыслящими людьми, которые бросают вызов предположениям, упиваются творческим разрушением и являются экспертами в обнаружении тонких, незаметных и тонких ошибок, которые коварно обнаруживаются, несмотря на все усилия групп разработчиков по созданию качественного программного обеспечения.
Учитывая это описание, легко думать о QA как о сети, вылавливающей ошибки. Ошибки непреднамеренно создаются разработчиками, и QA - это сеть, которая существует для отсеивания этих ошибок, прежде чем они будут переданы в производство. Эта метафора QA-as-a-bug-net все еще довольно распространена в умах многих команд и менеджеров.
Таким образом, когда ошибка действительно попадает в рабочую среду, естественно посмотреть в сеть, чтобы определить, как дефект был устранен. Очевидно, в сети была какая-то дыра, и нам нужно ее найти и заткнуть. С другой стороны метафоры, была некоторая проблема с тестовым покрытием или выполнением, используемыми QA, и это необходимо идентифицировать и исправлять.
К сожалению, QA-as-a-bug-net - неверная метафора. Он неправильно упрощает сложную деятельность по разработке программного обеспечения до двухэтапного процесса: его создания и последующего тестирования. Строительство создает что-то, что может работать, и тестирование показывает, работает это или нет. Если это так, он идет в производство. Если этого не происходит, разработчики возвращают его обратно.
Качество - это не то, что может быть доказано одним шагом, человеком, воротами или сетью, независимо от времени или опыта. Исчерпывающего тестирования не существует, и выпуск программного обеспечения всегда будет сопряжен с риском.
Современную разработку программного обеспечения следует рассматривать как серию из сотен шагов, каждый со своими собственными действиями, связанными с качеством, и каждый по-своему повышает общую уверенность в программном обеспечении. Предполагать, что качество может быть доказано на одном этапе тестирования, выполняемом одним человеком или одной ролью, опасно наивно. Не существует идеальной сети, которая могла бы поймать все ошибки, и метафора QA-as-a-bug-net следует сжечь в мусорном ведре, а затем выбросить в середину глубочайшего океана.
Отказавшись от метафоры баг-сети, мы можем понять, почему прямо спрашивать QA: «Почему вы не нашли ошибку?» настолько токсичен: вопрос выделяет только одну роль, выполняющую один шаг, и возлагает на них ответственность, которую они одни не могут и не должны брать на себя. Вопрос слишком узкий; он сворачивает сложный процесс разработки программного обеспечения обратно в один этап, отвечающий за качество, а затем спрашивает, почему этот этап не удался. В вопросе подразумевается «вы» как ответственная сторона за отсутствие дефекта: ВЫ (QA) должны были найти ошибку, а ВЫ - нет.
Руководители из лучших побуждений, которые спрашивают QA: «Почему вы не нашли ту ошибку?» и непреднамеренно прямая вина за человека не настраивает их организацию на успех. Они пытаются быть полезными и делают это из лучших побуждений, но формулировка и цель вопроса делают их усилия контрпродуктивными. Это не вина сети, потому что нет сети.
Другие менеджеры понимают это, но все же задают вопрос. Хотя они и редки, они существуют. Эти лидеры сознательно ищут козла отпущения, а не результата. Им нужен кто-то, на кого можно указать пальцем и снять с себя вину. «Эта проблема с продуктом sev-1 не МОЯ вина, эти QA ПРЕДНАЗНАЧЕНЫ, чтобы найти все ошибки!». Работать на такого менеджера - все равно что стоянка под голубями - это лишь вопрос времени, когда ты начнешь заниматься этим.
Виноваты не только менеджеры. Есть много тестировщиков, которые сами усугубляют проблему. Они с гордостью берут на себя ответственность за защиту производства, за сеть без дыр, поскольку это дает им чувство цели и ценности в команде. Они осознают свою ошибку только тогда, когда во время вскрытия упаковки на предмет очевидного производственного дефекта какой-то менеджер поворачивается, указывает на них и спрашивает: «Почему ВЫ не нашли ошибку?».
Другие версии этого токсичного вопроса включают: «Готовы ли мы к производству?» и «Вы (QA) сертифицируете код?». Оба они представляют собой лишь превентивные версии оригинала, и оба предполагают, что QA может выполнять роль идеальной сети для выявления всех ошибок. По сути, оба вопроса говорят: «Обещай мне, что ошибок не будет!», Или, более прямо: «Давайте зафиксируем, что ваша репутация, а не моя, страдает, когда мы неизбежно обнаруживаем ошибки».
Принадлежность всей команды к качеству и лучший вопрос
Команды инженеров по-прежнему должны находить ошибки, а когда ошибки все же ускользают в производственную среду, они должны стремиться понять, как подобных проблем можно избежать в будущем. Итак, как нам сделать это без качественных сетей и без постановки якобы табуированного вопроса?
Антитезой мышления QA-as-a-bug-net является ответственность всей команды за качество и понимание того, что каждый человек в сложном, многоэтапном процессе разработки программного обеспечения играет определенную роль и ответственность за качество конечного продукта. Качество программного обеспечения - это неотъемлемая характеристика хороших процессов разработки - это результат, который происходит, когда многие вещи объединяются по-разному, и не может быть исключительной ответственностью одного человека или одной роли.
Поскольку кажется, что инженеры любят метафоры, думайте об этом так: высококачественное программное обеспечение похоже на здоровый сад. Вы не можете просто создать здоровый сад; Вы должны обеспечить наличие всех условий для здоровья, а затем позволить саду расти самим. Здоровье возникает естественным образом. Было бы глупо указать на воду и сказать: «Это ваша работа - заботиться о здоровье сада!». Так же глупо указать на QA и сказать: «Это ваша работа - обеспечивать качество программного обеспечения!».
Наиболее частая реакция разработчиков на приведенное выше утверждение - это что-то вроде: «Да! Я пишу модульные тесты! » а затем они с радостью возвращаются к перебрасыванию подозрительного кода через пресловутую стену перед перегруженным QA, предполагая, что их модульные тесты освобождают их от любой ответственности за качество.
Будучи отличным первым шагом, модульное тестирование само по себе не демонстрирует менталитет коллективной собственности, который я пытаюсь описать. Разработчики участвуют во многих этапах между идеей программного обеспечения и производственным развертыванием - от проектирования системы, сбора требований, профилирования до реализации, интеграции и развертывания. Все эти действия могут повлиять на качество, и все они должны иметь проверки и защиту (с участием разработчиков!) Для проверки качества и повышения уверенности.
Это не для того, чтобы выделить разработчиков как злодеев в нашей истории. Принадлежность всей команды к качеству на самом деле означает ответственность всей команды - все роли играют жизненно важную роль в успешной разработке качественного программного обеспечения.
Таким образом, возникает правильный вопрос: «Почему МЫ не обнаружили эту ошибку?» и, что более важно, вопрос должен быть адресован всей команде. Этот небольшой переформулировка вопроса и изменение аудитории правильно ставит под пристальное внимание каждую часть и каждого человека, вовлеченного в процесс разработки. Он правильно распределяет общие роли и все действия, чтобы определить изменения, которые могут эффективно и действенно предотвращать подобные дефекты в будущем.
Например: обзоры кода слишком скучны? Хорошо ли определены и проверены ли истории пользователей и критерии приемлемости? Достаточно ли тестового покрытия в тестах API? Должна ли команда UX проверять ресурсы пользовательского интерфейса на более раннем этапе процесса? Достаточно ли разнообразны данные испытаний? Действительно ли архитектура системы разложима? Проблемы в любой из этих и тысячи других частей процесса разработки могут на самом деле быть основной причиной проблем с качеством, а не тем фактом, что QA «пропустил» дефект. Новая постановка вопроса это понимает.
"Почему мы не нашли эту ошибку?" - это вопрос, который следует задавать часто и открыто, исходя из взаимного уважения и искреннего познания. Я действительно верю, что небольшое изменение в одном слове и целевой аудитории помогает сместить разговор с обвинений и козлов отпущения на размышления, подотчетность и улучшение.
Заключение
Специалисты по тестированию, не допускайте неудач, принимая на себя роль сети ошибок и защитника продукции. Возможно, сейчас вы чувствуете себя важным и ценным, но позже на вас неизбежно укажут длинный палец обвинения. Вы можете подумать, что вы качественный герой, но на самом деле вы будущий козел отпущения. Как тестировщик, вы являетесь экспертом в поиске дефектов, но ваше тестирование - это всего лишь одна часть сложной машины, которая должна быть исправной для создания высококачественного программного обеспечения.
Менеджеры, не задавайте вопросов, которые возлагают ответственность за качество на одного человека или одну роль. Хотя это может заставить вас чувствовать себя в большей безопасности, если у вас есть кто-то, кто несет единоличную ответственность за качество, вы не настраиваете свою команду на успех. Поймите, что каждый играет определенную роль в обеспечении качества, и создавайте среду, в которой критическое, открытое и честное обсуждение всего и всего, что влияет на качество, не просто терпимо, но ценится и поощряется.
