Почему это «токсично» и как сформулировать вопрос правильно

После релиза пользователь сообщает о неприятном баге в продакшене. Звучат сигналы тревоги, жужжат уведомления и летают электронные письма. Команда бросает все и экстренно фиксит баг. Хотфикс проверен, пользователь успокоен, и все выдохнули с облегчением. Позже менеджеры встречаются с топ менеджерами на закрытых встречах, чтобы обсудить «как это могло случиться» и «почему это никогда больше не повторится».

На следующий день те же самые менеджеры, ещё не оправившиеся после вчерашнего допроса, обращаются к своим тестировщикам и спрашивают: «Почему вы не нашли этот баг?»

Многим этот вопрос кажется очевидным, и большинство менеджеров задают его искренне, желая разобраться. QA выполняют важную, почти центральную роль в поиске багов. Баг был обнаружен в продакшене, поэтому естественно возникает вопрос к QA, почему они его не нашли.

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

Прежде чем мы перейдем к этому вопросу, давайте немного поговорим о том, почему «Почему-вы-не-нашли-эту-ошибку?» так плохо.

Во многих командах есть человек(или роль), который занимается качеством, обычно их называют QA, QE или «тестировщик». Для простоты я буду называть их всех QA. Эти люди обладают глубоким пониманием предметной области, критически мыслят, бросают вызов предположениям, наслаждаются созидательным разрушением и являются экспертами в поиске хитрых, незаметных и неочевидных ошибок, коварно всплывающих на поверхность, несмотря на все усилия команды разработки по созданию качественного программного обеспечения.

Используя это описание, легко представить QA как «сеть», которая отлавливает ошибки. Ошибки непреднамеренно создаются разработчиками, и QA — это сеть, которая существует для того, чтобы отсеивать эти ошибки, прежде чем они попадут в продакшен. Эта мысль до сих пор довольно распространена в умах многих команд и менеджеров.

Таким образом, когда баг попадает в продакшен, довольно логично обратиться к «сети», чтобы определить, как дефект прошел через нее. Очевидно, в «сети» была какая-то дыра, и нам нужно найти её и заткнуть. С другой стороны, возможно, была некоторая проблема с тестовым покрытием или применением практик QA, это необходимо выявить и исправить.

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

Качество — это не то, что можно описать одним шагом, человеком, рамками или «сетью», вне зависимости от количества времени или опыта. Не существует такой вещи, как исчерпывающее тестирование(за исключением специфических продуктов), и всегда будет некоторый риск, связанный с выпуском программного обеспечения.

Современную разработку программного обеспечения следует рассматривать как последовательность из множества шагов, каждый из которых содержит ряд действий, связанные с качеством, и каждый по-своему повышает общую уверенность в программном обеспечении. Предполагать, что качество может быть обеспечено одним этапом тестирования, выполняемым одним человеком или ролью, очень наивно. Не существует идеальной сети, способной поймать все ошибки, и метафора QA-это-сеть-для-багов должна быть сожжена, а затем погребена в глубинах океана.

Отказавшись от метафоры QA-это-сеть, мы можем понять, почему прямой вопрос команде QA: «Почему вы не нашли баг?» настолько токсичен - вопрос выделяет всего одну роль, выполняющую один шаг, и накладывает на них ответственность, которую они одни не могут и не должны брать на себя. Вопрос слишком узок, он сводит сложный процесс разработки программного обеспечения к одному шагу, а затем уточняет, почему этот шаг не удался. В вопросе подразумевается «вы» как ответственная сторона за упущение дефекта: ВЫ (QA) должны были найти ошибку, но ВЫ этого не сделали.

Менеджеры, которые из лучших побуждений спрашивают QA: «Почему вы не нашли эту ошибку?» и непреднамеренно возлагая вину на человека, не приведут свою команду ни к чему хорошему. Они пытаются быть полезными и делают это из лучших побуждений, но формулировка и фокус вопроса делают их усилия контрпродуктивными. Сеть не виновата, потому что сети нет.

Другие менеджеры это понимают, но все же задают этот вопрос. Их мало, но они существуют. Эти люди сознательно ищут козла отпущения. Им нужен кто-то, на кого они могут указать пальцем. «Эта проблема с продуктом X — не МОЯ вина, это QA ДОЛЖНЫ были найти все ошибки!». Работать на такого менеджера все равно, что парковаться под голубями — это всего лишь вопрос времени, пока ты хлебнешь горя.

Виноваты не только менеджеры. Есть много тестировщиков, которые сами усугубляют проблему. Они с гордостью берут на себя ответственность, поскольку это дает им чувство ценности в команде. Они осознают свою ошибку только тогда, когда в post-mortem на критичный баг в продакшене какой-нибудь менеджер сошлется на них и спросит: «Почему ВЫ не нашли баг?».

Другие версии этого токсичного вопроса: «Готовы ли мы к продакшену?» и «Вы (QA) одобряете релиз?». Оба они являются просто упреждающими версиями оригинала, и оба предполагают, что QA может выполнять роль идеальной сети для отлова всех ошибок. По сути, оба вопроса говорят: «Обещайте мне, что ошибок не будет!», или, говоря прямо, «Давайте официально заявим, что ваша репутация, а не моя, пострадает, когда мы неизбежно найдем ошибки».

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

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

Самая частая реакция разработчиков на приведенное выше утверждение примерно такая: «Я пишу юнит тесты!» а затем они с радостью возвращаются к тому, чтобы подкинуть подозрительную задачу перегруженному QA, предполагая, что их тесты освобождают их от любой ответственности за качество.

Хотя юнит тестирование является отличной базой, но само по себе оно не дает полноценное обеспечение качеством, которое я пытаюсь описать. Разработчики участвуют во множестве этапов между идеей для новой фичи и выкаткой в продакшен — от проектирования системы, сбора требований, до реализации, интеграции и развертывания. Все эти действия могут повлиять на качество, и все они должны содержать активности по обеспечению качества(с участием разработчиков!)

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

Таким образом, правильной постановкой вопроса становится: «Почему МЫ не нашли этот баг?» и что еще более важно, вопрос должен быть адресован всей команде. Новая формулировка вопроса и изменение аудитории позволяет тщательно изучить каждый этап и каждого человека, вовлеченного в процесс разработки. Вопрос правильно распределяет ответственность, чтобы определить изменения, которые могли бы эффективно и действенно предотвратить подобные дефекты в будущем.

Например: не слишком ли поверхносты процедуры code review? Являются ли user stories и DOR четко определенными и поддающимися проверке? Достаточно ли тестового покрытия в api тестах? Должна ли команда UX дизайнеров проверять элементы пользовательского интерфейса на ранних этапах? Достаточно ли разнообразны тестовые данные? Является ли архитектура продукта действительно декомпозируемой? Проблемы в любой из этих и тысячи других частей процесса разработки могут на самом деле быть основной причиной проблем с качеством, а не тем фактом, что QA «пропустил» дефект. Новая формулировка вопроса позволяет это понять.

«Почему мы не нашли эту ошибку?» — это вопрос, который следует задавать часто и открыто, исходя из взаимного уважения и искреннего желания узнать новое. Я действительно верю, что небольшое изменение в одном слове помогает сместить фокус с обвинений и поиска козлов отпущения на размышления, подотчетность и улучшение.

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

Менеджеры, не задавайте вопросы, возлагающие ответственность за качество на одного человека или одну роль. Хотя вы можете чувствовать себя более защищенными, если кто-то несёт единоличную ответственность за качество, это не приведет ни к чему хорошему. Поймите, что каждый играет определенную роль в обеспечении качества, и создайте атмосферу, в которой острые, открытые и честные обсуждения всего и вся, что влияет на качество, не просто допускаются, но приветствуются и поощряются.