Программисты и тестировщики

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

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

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

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

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

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