Разная специфика работы, разная специальность
Начнем с того, что разработчики и тестировщики — два совершенно разных племени, живущих в одном межгалактическом космическом корабле под названием «Проект». Разрабы — беспощадные космические волки, чья цель закинуть в продакшен как можно больше фич за минимальное время. Тестеры же с бдительные сторожа, охраняющие качество продукта от любых посягательств. Но истинная причина проблемы совсем в другом: менеджмент в интересах бизнеса продавливает разработку делать быстрее и больше. Как результат страдает качество кода на выходе, а тут уже тестировщики потирают руки, не упустив возможности поиронизировать над коллегами.
Естественно, между этими двумя лагерями часто возникают трения.
В разгар таких баталий менеджеры проекта нервно крутятся вокруг, пытаясь погасить пожар. Но все — тщетно. А меж тем это именно они обязаны примерить враждующие лагери.
Психологический аспект
Разработчики действительно «созидают», вкладывая свои знания, опыт и творческий подход в создание продукта. Это естественно приводит к эмоциональной привязанности к результатам своего труда. Тестировщики, в свою очередь, выполняют критически важную роль «стражей качества», что может восприниматься как критика или недоверие к работе разработчиков.
Разница в целях
Цель разработчика — создать функционирующий продукт в рамках заданных сроков и требований. Цель тестировщика — обеспечить качество продукта путем выявления потенциальных проблем. Эти цели могут казаться противоречащими друг другу, хотя на самом деле они направлены на общий результат — качественный продукт.
Для разработчика найденный дефект может восприниматься как личная неудача или недостаток профессионализма. Для тестировщика же это просто часть рабочего процесса и возможность улучшить продукт.
Ну и в условиях жестких дедлайнов найденные дефекты могут восприниматься разработчиками как угроза срыва сроков, что усиливает напряжение в отношениях.
Проблемные зоны: проверьте 7 причин
Какие же именно сложности могут возникать между разрабами и тестерами? Сейчас узнаем.
Различия рабочих словарей
Особенно актуально для команд, которые общаются на разных языках. Ну и конечно — количество сленговых выражений, акронимов и сокращений в нашей индустрии просто запредельное. Зачастую стороны буквально не могут понять друг друга. Допустим, тестировщик говорит про инцидент, выявленные в ходе root cause analysis. А разработчик — просто его не понимает.
Решение: устраивать регулярные мозговые штурмы согласования используемых терминов. Выпустить внутренний глоссарий для новичков.
Токсичная корпоративная культура
Последствия такой культуры:
Обратная ситуация: токсичная культура для разработчиков
Хотя реже, но встречаются ситуации, когда корпоративная культура становится токсичной для разработчиков:
Последствия:
Влияние на межличностные отношения
Токсичная корпоративная культура, независимо от того, направлена ли она против QA или Dev, негативно влияет на межличностные отношения:
Пути решения проблемы
Для создания здоровой корпоративной культуры и улучшения отношений между QA и Dev необходимо:
Роль руководства
Ключевую роль в создании здоровой корпоративной культуры играет руководство компании:
Психологические различия
Эта теория основывается на идее, что создание чего-либо, в том числе программного кода, является актом творчества. Разработчики вкладывают в свою работу не только профессиональные навыки, но и часть своей личности. Это приводит к нескольким важным последствиям:
Эмоциональная привязанность к коду
Страх несовершенств
Защитная реакция
Сложность принятия критики
Из-за глубокой личной вовлеченности в процесс создания кода, разработчикам может быть сложно отделить критику их работы от критики их самих как профессионалов.
Развитие эмпатии
Поощрение открытого диалога
Работа над принятием критики
Обучение конструктивной обратной связи
Плохое понимание общего процесса и зависимостей друг от друга
Когда стороны плохо понимают восприятие, мотивацию друг друга, конструктивный диалог становится трудноосуществим. Пример: тестировщик объясняет джуну явление severity в тестировании, говорит о необходимости учёта контекста при определении серьёзности. Но разработчик просто не понимает о чем идет речь и зачем вообще дефекту присваивать какие-то приоритеты.
Нехватка времени и ресурсов
Решение: изначально закладывать в плановые графики время на полноценную коммуникацию, выстраивание процессов. Бить колокол перед начальством при дефиците!
Удаленная работа. Распределенные команды
Решение: включать современные инструменты коммуникации. Для постоянного присутствия на связи пробовать наиболее подходящие инструменты (Zoom, Slack, Notion). И вводить традицию физических встреч раз пару раз в неделю, хотя бы.
