Как мне поощрить моего менеджера поддерживать автоматизированные тесты?

Широко распространено мнение, что автоматические тесты (и TDD) приносят пользу процессу разработки программного обеспечения следующим образом:

• экономит время (сокращает время выхода на рынок) [ссылка]

• улучшает качество и снижает общую стоимость владения [ссылка]

• улучшает командный дух (одним из источников недовольства разработчиков являются рутинные, повторяющиеся задачи) [ссылка]

• снижает затраты на адаптацию (разработчики меньше боятся что-то менять и ломать)

Зная все это, почему некоторые менеджеры до сих пор не «разрешают» или не поощряют написание автоматизированных тестов? Я думаю, вы все видели это: «у нас нет времени на тесты» или «давайте сначала выложим это, а затем следующий Q мы уделим время тестам» или «смета с тестами слишком велика, давайте пропустим тесты». .'

Есть отличный набор эпизодов подкаста You Are Not So Smart на одну тему: Эффект обратного огня:

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

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

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

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

1. Менеджер не видит рациональности (то есть ценности) в автотестах

1. Менеджер когда-то был очень умным программистом, скорее всего, индивидуальным вкладчиком. Либо им действительно удалось удержать в голове весь программный AST и контекст, либо, что более вероятно, они думали, что удержали его.

1. У менеджера есть «количество функций» в качестве KPI, и они подталкивают команду к тому, чтобы сделать как можно больше в кратчайшие сроки, не заботясь о качестве (гарантии занятости).

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

1. Компания сосредоточена на подготовке к продаже и каждый хочет доставить как можно больше в кратчайшие сроки

1. Мотивация менеджера «по CV»: он не планирует долго оставаться в компании, а добивается быстрых (1-2 года) результатов и уходит

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

Я просто попытаюсь встать на место менеджера и дать вам несколько идей о том, как помочь ему помочь вам.

Знаменитое высказывание Марка Твена:

для очень многих проблем есть решение, которое является «простым, очевидным — и неправильным.

Я был бы рад, если бы вы просто предоставили менеджеру рациональные аргументы, и он одобрил внедрение автотестов.

Однако даже в этом акте предоставления рациональных аргументов можно отметить некоторые моменты:

Тон голоса

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

Если вы стремитесь внедрить автотесты, а не запугивать своего менеджера или коллег-разработчиков, сделайте себе одолжение — звучите позитивно, сформулируйте предложение как что-то вроде «посмотрите, какие позитивные изменения мы можем получить, если мы внедрим автотесты», и добавьте несколько примеров.

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

Стоимость внедрения и опасения

Если ваш руководитель одобрил автотесты на предыдущем этапе — отлично.

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

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

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

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

Менеджер «знает лучше»

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

Психологи называют этот эффект — [Предвзятость ложного консенсуса] (https://www.sciencedirect.com/science/article/abs/pii/002210317790049X).

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

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

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

Нехватка доверия

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

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

Это сводится к доверию: спросите себя — доверяет ли ваш руководитель вам и команде в реализации и поддержке изменений?

Как строится доверие? Он строится на людях, выполняющих обещанное.

Что мы можем здесь сделать? Начните с себя — докажите, что вы заслуживаете доверия.

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

Менеджер отдела «Manual QA» боится не расти

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

Карьерная лестница иногда выглядит так: менеджер начинает с QA-лида, «выращивает» свою команду с 5 до 10 QA-инженеров, затем нанимает еще 5, таким образом становится главой QA-отдела, и ему подчиняются 2 QA-руководителя команды.

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

Можем ли мы что-нибудь здесь сделать?

Единственный совет, который я могу придумать: покажите менеджеру очевидные преимущества, которые он может получить от автотестов:

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

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

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

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

Некоторые причины, по которым менеджеры не хотят поддерживать автоматизированное тестирование, очень зависят от контекста, и поэтому невозможно дать общий совет.

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