« Я тестер ! »

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

Доверие и безопасность.

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

Лучшим ответом на эти вопросы будет занятие позиции, при которой они просто не будут заданы, - предотвратить это можно через обучение и общение. Стоит начать с внесения ясности руководству о том, что будет протестировано, в самом начале проекта. Затем, когда вы найдете ошибку, вы можете сказать: «4 недели назад мы договорились о том, что будет протестировано – за рамки этого я не вышел.» Другой способ – образование: я знаю одного менеджера , который подарил своему начальству в качестве новогоднего подарка копию Perfect Software: And Other Illusions about Testing.

Предупреждение проблем – это хорошая цель, но боюсь, что это не поможет тестировщикам, которым приходится отвечать на такие вопросы прямо сейчас. Итак, моя цель сейчас – обезоружить вопрос, показать что такое осуждение не эффективно и направить команду на путь движения к честности, безопасности и командной работе. Делая это последовательно в итоге можете получить следующую ситуацию. Ваш новый вице президент задает похожий вопрос и тогда кто-нибудь из программистов или Product Managers объясняет ему на сколько данный вопрос нечестен. По крайней мере на это можно надеяться.

Думаю, что теории достаточно. Давайте представим, что вы только что услышали в свой адрес «Почему тестировщики пропустили эту ошибку?». Вот возможные пути ответа:

1. Выбор исходных данных.

Утверждают, что тестировщики должны были найти эту ошибку. Мы можем ответить, что действительно существует заслуживающая внимание причина, почему эта ошибка не была найдена. Далее несколько разъяснений, как я это использовал:

Давайте теперь немного поговорим о давлении расписания и как это влияет на фантазию тестировщиков…

Минуточку: Должны ли были тестировщики найти эту ошибку? Было ли у них достаточно времени? Где был человек, который знал о возможности проблемы? Был ли запрос на использование программных средств, которые позволят найти ошибки такого рода? Такая ситуация может быть хорошим временем, чтобы сказать «Используя данные условия среды разработки/тестирования, мы не должны ожидать, что тестировщики найдут ошибки такого рода. Если же мы хотим не отдавать такие ошибки заказчику, нужно изменить...»

3. Ответ вопросом.

Вместо ответа «вот почему мы не нашли эту ошибку», вам стоит ответить своим вопросом. Это меняет вашу роль, вы перестаете быть жертвой, и становитесь... кем-то, кто действительно пытается повысить качество.

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

Делая так, вы даете возможность интерпретировать эту ошибку шире – на пример, как эта ошибка появилась – это может спасти вас от враждебности и претензий.

Мой опыт говорит, что бывает три возможных пути развития событий: Команда разработчиков делает brainstorm и предотвращает подобные ошибки в будущем, или они пожимают плечами и говорят «ошибки случаются», или кто-то становится очень грустным. Первых два варианта выглядят хорошо. В третьем случае, иногда вы можете ответить «Я сам не люблю такие вопросы.» Но будьте осторожны. Вы должны знать тех, кому пишите. Мы стараемся построить дружественную атмосферу в команде.

4. Направление дискуссии.

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

Если ошибка на столько важна, что праздновать нечего, постарайтесь ввести самого вопрошателя в процесс проекта: «Это хороший вопрос, Иван. Ты считаешь, что тестировщики должны были найти эту ошибку? Я был бы рад услышать от тебя предложения о том, где бы мы могли улучшить свою работу.» Эта не защищает нас полностью от критики, но приглашает Ивана становится частью процесса, а не просто критиковать.

5. Измени тему.

В своей книге Quality Software Management, Volume III Jerry Weinberg говорит, что не подходящее поведение может спасти команду от критики. Он приводит такой пример: «Посмотрите, какой пятнистый кот на крыше. Как он туда попал?» Тяжело критиковать кого-то, когда смотришь на котенка. Но вам стоит знать людей, с которыми разговариваете, ведь часть людей будут задавать эти вопросы раз за разом.

Консультант по командной работе Pollyanna Pixton предлагает другой вариант: Просто откажитесь отвечать на неудобный или нечестный вопрос.

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

«Тряпка» или политик?

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

Да, это возможно. Традиционные альтернативы – отступление и успокаивание – могут быть менее болезненны. Если не считать того, что вы становитесь «тряпкой». Мой вам совет: знайте себе цену, и у вас будет что сказать в момент, когда вам зададут нечестный вопрос.

Да, начальник может быть зол. У вас может даже разгореться конфликт. Через пять лет, вы, возможно, будете работать на новой работе. Я предполагаю, что она будет лучше той, где вы работаете сейчас.