воскресенье, 20 июня 2010 г.

Живут, как тестировщик с программистом

картинка для привлечения внимания


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

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

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

Конечно, все работают ради разного: кто-то ради зарплаты, кто-то ради решения интересных задач, кто-то ради получения бесценного опыта. Но для достижения личных целей нужно работать в направлении целей проекта, продукта, компании. Тогда будет и зарплата, и опыт, и интересные задачи. Судите сами, если бы целью программиста был выпуск качественного продукта, успех проекта, процветание компании, и он бы работал на это, то это бы просто автоматически работало на его личную цель. И при таком раскладе никогда не прозвучит «это не баг», потому что любое подозрение на баг таким специалистом принимается и рассматривается.

Как раз сейчас я краем глаза смотрю запись гран-при Канады Формулы 1.

Феноменальный пример слаженной, однонаправленной командной работы. Есть 2 части команды: собственно, перформер, пилот, человек, который на виду, который пожинает лавры в глазах публики, но который на каждой пресс-конференции говорит про работу всей команды, и есть та самая команда-тыл, которая смотрит на его работу на трассе, анализирует её и говорит в шлемофон: «Кубица сменил резину на жесткую, Барикелло тоже, не дай себя обойти». А теперь представьте, что команда отлавливает ошибки пилота и злорадно сообщает ему «Из-за того, что ты не сменил резину на прошлом пит-стопе, потерял 2 секунды во время дождя». Как только части команды начинают работать друг против друга – она обречена на провал!

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

Признаки того, что ваши программисты и тестировщики не Правильные:

- от тестировщиков звучат фразы «наколбасил им багов, пусть теперь разгребают»

Это идет от старших тестировщиков и от общей атмосферы в коллективе. Я ещё не видела ни одного неопытного тестировщика, который бы думал так с самого начала.
Если старший коллега хочет вырастить злобное чудовище, которое радуется при нахождении бага не потому, что теперь пользователь получит на одну ошибку меньше, а потому, что насолил программисту, то ему стоит продолжать в духе «Давай, сынок, покажем этим кодерам, что за какашку они выпустили бы без нас ». Но если он хочет, чтобы тестирование работало не против программирования, а совместно с ним на качество продукта, и ведет себя соответственно, то никогда в его команде не будет такого.

- от программистов слишком часто звучит презрительное «это не баг»

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

- программист не проверяет результат своей работы перед передачей в тестирование

«Моё дело писать код, а их дело проверять», «Ну а их-то зачем понанимали?» - можно услышать в таких командах. Это элементарное отсутствие гигиены, работа ради «отписаться». Где вы видели журналиста, который не перечитывает свою статью перед тем, как передать её в редактуру? Если в коллективе есть программист, который проповедует такой подход, его нужно как можно скорее ликвидировать. Какой бы он ни было классный специалист.

- тестировщики заносят баги, не интересуясь их дальнейшей судьбой

Это позиция «с моей стороны пуля вылетела» с другой стороны.
Цель тестирования – найти как можно больше ошибок в приложении, безусловно, имеет право на жизнь на определенных этапах тестирования. Только в этом определении не хватает второй части. Исправить. В силах тестировщиков донести важность важных багов до программистов и честно сказать про низкий приоритет низкоприоритетных. Если программисты знают, что их тестировщики зря хайприорити не поставят, то они серьезно относятся к каждому такому багу. А вот массированная атака багами без интереса к их дальнейшей судьбе, без подвижек в сторону облегчения их локализации, действительно является результатом работы только на себя.

- эффективность работы тестировщиков измеряется количество найденных багов, а мера качества работы программистов обратно зависит от этого количества

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

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

Уверена, что список можно продолжить.

При этом, чувствуете? В первом и четвертом случае корень проблемы в Просто Тестировщиках, во втором и третьем - в Просто Программистах, а в пятом - в Просто Менеджерах. Если у вас одна их таких ситуаций, смотрите, от кого исходит этот вирус и искореняйте его.





7 комментариев:

bfrolov комментирует...

Очень правильная статья :)
К сожалению именно команды у которой общие цели, я лично встречал крайне редко, но очень надеюсь что они все-таки существуют в немалом количестве.

Julia Nechaeva комментирует...

их есть у нас! приходи в гости :)

CorWin комментирует...

очень толково, спасибо. все дело именно в том, что общая цель подменяется частными. и команда начинает идти не туда. все очень верно подмечено. и выводы отличные

Artem комментирует...

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

Анонимный комментирует...

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

Arch1S комментирует...

Сразу видно что человек первый год в такой свере, описывает самое простое, которое не описал человек с более большим опытом.
Человек с опытом над такой фигнёй даже и не задумывался

Анонимный комментирует...

Извините Юля, но если програмер ХАЛЯВЩИК и не заинтересован в выпуске хорошего продукта, нужно идти к ПМ-у обяснить ситуацию и решить вопрос раз и навсегда.

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

Настоящий специалист ВСЕГДА поблагодарит тестера который помог ему сделать качественный релиз и обьязательно уведомит того же ПМ-а о хорошей работе. И только в таком тиме будет настоящий успех.

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

-Павел