Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

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

В любом случае, для меня это не имеет смысла.

Первая мысль, которая приходит в голову: «Я говорю о тестировании, а не о качестве. Почему сюда притягивается качество?» Тестировщики не обеспечивают качество. Тестировщики НЕ МОГУТ обеспечить качество. Тестировщики сейчас и никогда не «владели качеством» ни в каком смысле.

Но даже если отложить это в сторону, качество не должно считаться «ответственностью каждого». Вот почему меня беспокоит эта формулировка:

Аналогия с цепью

Что значит, что все ответственны за одно и то же, например за качество продукта? Представьте цепь. Если хотя бы одно звено ломается, ломается вся цепь. Более того, у каждого звена ровно одна и та же задача. Следовательно, каждое звено в цепи в некотором смысле несёт равную ответственность за целостность и работоспособность всей цепи. Но, что важно, ни одно звено не может отвечать за другое звено. В цепи звенья не «разговаривают» друг с другом (кроме передачи усилия ближайшим соседям), и ни одно звено не делает другое звено прочнее.

Если применить это к программному проекту, такая интерпретация означала бы, что каждый человек отвечает только за качество своей работы, а не за качество работы других. В таком сценарии никто даже не смотрит на качество продукта в целом. Это слабая система для получения качественного продукта.

Согласно аналогии с цепью, любой может быть ответственен за какую-то проблему качества, но не все будут ответственны за её отсутствие. Максимум, что можно сказать, — все внесли вклад в качество итогового продукта.

Полная избыточность

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

В таком процессе, если подойти к любому человеку и попросить объяснить и обосновать весь процесс тестирования продукта, он сможет уверенно и без колебаний рассказать всё. Если спросить другого, ответы будут достаточно согласованными. Более того, у каждого участника будет одинаковая глубина понимания и схожие стандарты качества.

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

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

Стадная ответственность

Одна из интерпретаций, которую я наблюдал в реальных проектах: «ответственность каждого» означает, что никто конкретно ничего не обязан делать и не отвечает ни за что, связанное с качеством. Вместо этого все вопросы адресуются «команде». Вопросы качества обсуждаются только всей командой целиком.

Это полная инверсия ответственности. В рамках такой логики никому не нужно думать о качестве, потому что в плохом качестве никто не будет обвинён. Команда становится козлом отпущения, потому что никто в команде не будет самой командой.

Это и есть мой страх, и это объясняет защитный и почти магический способ, которым эта фраза используется (вроде «Expecto Patronum!»), когда я иногда ставлю под сомнение практики тестирования в проекте.

Слабая избыточность

Я предполагаю, что хорошие люди, которые говорят, что качество — ответственность каждого, на самом деле говорят не об ответственности. Они говорят о совместном устремлении: все стремятся к чему-то хорошему. Все стараются делать хорошую работу. Все помогают друг другу делать хорошую работу. Любой, кто видит проблему, пытается её решить или добиться её решения.

Это похоже на аналогию с цепью, но с тем отличием, что звенья немного поддерживают друг друга. Звучит хорошо. Стремления всегда звучат хорошо! Но здесь нет настоящего обязательства по отношению к качеству. Вот почему:

Чтобы было настоящее обязательство к качеству:

1. Каждый должен придерживаться одинакового стандарта качества. Нельзя, чтобы люди тянули в разные стороны. Этого можно добиться только через тщательные обсуждения, споры и общую культуру. Это сложно, требует времени и социально рискованно.
2. Каждый должен обладать достаточными знаниями о качестве. Это означает, что либо все тестируют всё, либо одни тестируют определённые вещи и эффективно делятся этим знанием с другими. Проблема в том, что хорошее тестирование — это сложно. У кого-то к этому больше интереса, у кого-то меньше.
3. Каждый должен иметь контроль над качеством продукта. Без контроля обязательство бессмысленно. Что происходит, когда участники команды вступают в конфликт из-за контроля? Единственный способ избежать конфликта — иметь одинаковые навыки и суждения (что сложно) или разделиться на разные зоны ответственности внутри команды, что означает, что никто не контролирует всё (следовательно, не все одинаково ответственны за качество).

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

Моя рекомендация: отказаться от коллективизма. Принять ответственность на себя. Установить чёткие роли.

Если вам нужно отличное качество, необходимо локализовать и персонализировать ответственность. Это нужно сделать образом, минимизирующим конфликт интересов. Тестирование (нацеленное на поиск проблем) конфликтует с разработкой (нацеленной на устранение проблем).

• Каждый из нас должен знать свою работу и хорошо её выполнять.
• Каждый из нас должен знать, чего от него ожидает команда.
• Каждый из нас должен понимать свою роль в проекте.
• Любая сложная или непопулярная деятельность должна быть закреплена за конкретной ролью (иначе она просто не будет выполняться хорошо).
• Качество программного продукта в целом должно считаться ответственностью людей, которые контролируют проект.
• Качество любой части продукта должно быть ответственностью того, кто создал эту часть.
• Систематическое тестирование программного обеспечения должно быть ответственностью людей, специально погруженных в этот сложный процесс.
• Каждый в команде несёт ответственность за разумную поддержку всех остальных членов команды.