Home

Автор: Майкл Болтон (Michael Bolton).

Оригинал статьи: http://www.developsense.com/blog/2018/12/pressing-the-green-button/

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

На конференциях, митапах и в социальных сетях тестировщики систематически сообщают мне, что они должны "дать добро" на продукт или деплой перед тем, как продукт выпущен в продакшен, или уйдет на ревью к клиенту. Тестировщики заявляют, что после того, как они проделали какую-то работу по тестированию, они должны "одобрить" или "отклонить" продукт. Вот типичный дословный отчет от одного из них:

"В моем нынешнем контексте, несмотря на мои обоснованные возражения, на меня смотрят как на привратника, и я нахожусь на такой позиции в рабочем процессе, которая буквальным образом предоставляет мне зеленую кнопку "одобрения" и красную кнопку "отклонения". Я должен выбрать нужную кнопку после "проведения контроля качества" рабочего продукта. Отдельным бонусом  идет список противоречивых требований заказчика и/или набросок с кучей примечаний (зачастую противоречащих устным запросам, которые нигде не фиксировались)".

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

Тестировщик продолжает:

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

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

Некоторые тестировщики рады авторитету, встроенному в функцию "одобрения" или "отклонения" продукта. Большинство, однако, чувствует себя несколько некомфортно. С моей точки зрения, ощущать дискомфорт нормально.

С точки зрения позиции Rapid Software Testing, одобрение или отклонение чего бы то ни было – это не задача тестировщика. Задача тестировщика – выявить причины для уверенности, что кто-либо значимый может одобрить или отклонить что-либо, и объяснить основания для этой уверенности. Решения насчет того, что делать с продуктом, включая одобрение и отклонение, принадлежат роли под названием "Менеджмент".

Если вы находитесь в такой же ситуации, как вышеупомянутый тестировщик, и кто-то дает вам право одобрять и отклонять продукты, и вы хотите быть менеджером – это ваш шанс! Хватайте его за хвост – но не делайте этого, не получив должность и авторитет менеджера (о зарплате забывать тоже не стоит). Если вам предлагают одобрять или отклонять продукт, не повышая вас до менеджера, я рекомендую вежливо отказаться и сделать контрпредложение – например, такое:

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

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

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

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

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

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

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

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

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

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

Нажатие "Отклонить" означает, что "Я знаю о проблеме или у меня есть причины полагать, что в этой области может быть проблема, которую я еще не выявил". Другими словами, отклонение означает, что я вижу риск, что в продукте или в тестировании есть нечто, о чем менеджеры или разработчики должны знать. Более "отклонение" ничего не значит.

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

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

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