Конфликт тестировщика и разработчика

Почему нужна эта статья?

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

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

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

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

Сторона разработчика

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

Сторона тестировщика

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

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

Таким образом, мы обнажили корень конфликта, который есть суть – разные цели! А когда у людей разные цели, как их не объединяй, они все равно будут идти каждый своей дорогой, по итогу – в разные стороны.

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

Рассмотрим,  что же нужно сделать, чтобы избежать столкновения двух структур в одном деле:

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

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

• Обе стороны должны помнить о единой цели – максимально качественно работающая система.

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

• Подключайте эмпатию, старайтесь учитывать чувства коллеги.

• Цели и задачи работы должны быть ясны. Не ленитесь лишний раз убедиться, что достигли взаимопонимания, спрашивайте себя, верно ли понял вас визави.

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

Вывод

Скажу просто:

• Когда тестировщики и программисты, если и не станут лучшими друзьями, но возьмутся друг другу помогать, от этого выиграют все.