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

Тестировщик: Выпуск релиза надо отложить!

Разработчик: Почему, что случилось?

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

Если бы разработчики и тестировщики работали в МЧС:

— Алло! Приезжайте, здесь жёлтая двенадцатиэтажка горит!

— Ну, не знаю, у меня напротив такая же жёлтая двенадцатиэтажка, и она не горит.

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

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

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

Анцупов А. Я., Шипилов А. И. Конфликтология. М., 2009.

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

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

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

Артём Алексеев, ведущий разработчик:

Могу кратко поделиться опытом взаимодействия с инженерами тестирования aka QA.

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

И исходить тут хочется непосредственно от конечной цели — реализации некоторой конкретной «фичи».

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

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

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

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

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

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

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

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

Ирина, тестировщик:

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

Арсений, тестировщик:

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

Ну и ещё могли вести себя как хамло, с которым сложно взаимодействовать. Помогать периодически отказывались. У меня задача важная горит, а мне говорили мол «ну времени нет, потом». Хотя если выпустить задачу не успеем, то к нему будут претензии со стороны руководства.

Корень конфликта

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

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

Мы в «Иннотех», чтобы избежать столкновения двух структур в одном деле, пользуемся следующими принципами:

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

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

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

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

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

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

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

Вместо заключения

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