Pull to refresh

Война миров: программисты vs. тестировщики!

Agile *
Sandbox

Когда-то я был тестировщиком. Помню, как в те далекие времена порой был крайне недоволен программистами:
Эти вечные сомнительные доводы «это не баг, это фича» или «если это и баг, то незначительный, пусть остается».

Да как же остается, если система колом встает!?

Потом я стал программистом. И всё изменилось – меня начали жутко бесить эти бесконечные возвраты на доработку:
То им это не нравится, то тут не работает! Да нафига было вообще в этом окне контекстное меню вызывать и вставлять нечитабельные символы!? Как они вообще до этого додумались!? Бред же, в боевом режиме так ни один пользователь не сделает!

Не буду править, пусть остается!

В общем, классика – вражда программистов и тестировщиков.

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

Процесс


В те времена у нас был очень простой и понятный процесс разработки:

Задачи --> Программирование <--> Тестирование --> Релиз

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

А что, это же пример идеальной инкапсуляции!

У программистов
  • на вход: новые задачи и возвраты из тестирования.
  • на выход: передача задач в тестирование.

У тестировщиков
  • на вход: задачи от программистов.
  • на выход: возврат задач программистам и официальный выпуск версии.

Собственно, процесс не плох сам по себе – каждый живет в своем мире и занимается любимым делом.

Цель


Но ведь у этого процесса есть вполне конкретная конечная цель – выпускать качественное ПО с нужным функционалом в срок.

Собственно, в этот момент и начинаются проблемы.

Проблемы


Однажды приходит менеджер и начинает напоминать о конечной цели.

Типичная ситуация:
Менеджер приходит к программистам и спрашивает «когда?», а они отвечают «не знаем, мы все сделали, спроси у тестировщиков».

Менеджер идет к тестировщикам с тем же вопросом «когда?», а они ему отвечают «разработка только утром выдала сборку, мы только приступили к тестированию, и точно будет возврат – тут багов уже много вылезло, поэтому мы не знаем когда будет выпуск – спроси у программистов».

И менеджер начинает ходить по кругу туда-сюда, а релиза все нет и нет.

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

Вот некоторые правила, которые сформировались в нашем отделе спустя несколько месяцев изнурительной работы менеджера:
  • Совместное планирование. Версия планируется заранее. На планировании присутствуют и программисты и тестировщики. Благодаря этому, все заранее знают, что им предстоит делать. Например, это позволяет тестировщикам заранее начать составлять планы тестирования и подготавливать необходимое тестовое окружение.
  • Разработка в бранчах. Разработчик не вливает новых задач в основную ветку до тех пор, пока все уже влитые задачи не будут протестированы. Это позволяет избежать «снежного кома», т.е. эффекта накопления большого количества наполовину сделанных задач в основной ветке. И так же не дает бездельничать программистам – они всегда могут делать следующую задачу в бранче.
  • Маленькие версии. Это попытка сократить разработку в бранчах, ведь это накладные расходы на мердж, актуализацию кода и повторное тестирование. Если делать маленькие версии, то можно работать сразу в основной ветке.
  • Ничегонеделанье. Ещё одна попытка сократить разработку в бранчах. Когда в бранчах накапливается много задач, и разработка сильно убегает вперед от тестирования, то программистам разрешается просто ничего не делать, чтобы ещё больше не убегать вперед.
  • Раннее информирование. Например, тестировщик приступил к тестированию задачи. Задача большая, но он уже сразу нашел дефект. Он сообщает об этом программисту сразу при обнаружении, а не в конце, когда все тестирование завершено. Или наоборот, программист ещё во время разработки сообщает тестировщику о нюансах реализации, чтобы тот заранее подготовил тест-план. Это вроде как позволяет распараллелить работу программиста и тестировщика.

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

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

Более того, взаимоотношения между программистами и тестировщиками не улучшались – как была вражда, так она и осталась.

Осознание


Прошло ещё немало дней и ночей, когда я много думал о причинах происходящего, о поведении людей, об их эмоциях, потребностях и мотивах.
А потом вдруг всё стало ясно!
Да ведь сама структура такого подхода, когда «одни программируют – другие тестируют» порождает конфликт между программистами и тестировщиками.

И вся суть этого конфликта в том, что У НИХ РАЗНЫЕ ЦЕЛИ!

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

Решение


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

Причем цель очевидную – выпуск качественного релиза в срок.

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

Ясно, что изменить цели оказалось делом не простым. Но поскольку я полностью проникся логикой своих мыслей – то был готов сломить любое сопротивление изменениям!

Вот основное, что было сделано:
  1. Изменена организационная структура отдела. Вместо отделов разработки и тестирования сформированы команды, в которых собраны и программисты и тестировщики.
  2. Переезд. Вновь сформированные команды получили по отдельной комнате. Теперь не было ситуации, когда тестировщики и программисты сидят в отдельных комнатах и живут своей жизнью.
  3. Пропаганда. Естественно, пришлось сказать немало пламенных речей о том, для чего и почему мы затеяли реорганизацию. И главное – донести до всех общую цель, для чего мы вообще здесь все собрались. Поскольку люди все грамотные, а идеи логичные – пропаганда получилась легкой и успешной.
  4. Увольнение. Увы, но кто-то не согласился с новыми идеями. Но оно и к лучшему, они уступили дорогу тем, кто теперь приносит куда больше пользы!

И все эти усилия того стоили! Эффект оказался просто поразительным!
  • Напряженные отношения между программистами и тестировщиками исчезли, как будто и не было.
  • Появилась взаимная поддержка, продукты стали качественнее.
  • Программисты стали помогать тестировщикам, указывая на узкие места, которые стоит дополнительно проверить.
  • Изменилось общее отношения к обнаруживаемым дефектам. Никто никого не считает виноватым. Даже наоборот, разработчик благодарен тестировщику, что тот помог сделать продукт лучше!
  • Все договоренности о взаимодействии программистов и тестировщиков стали выполняться сами собой – потому что все поняли их эффективность.
  • В общем, все заработало как часы – регулярные релизы, качественный продукт.

На глазах, за какие-то полгода, произошло настоящее преображение!

Вывод


У любого конфликта всегда есть истинная причина. У типичного конфликта между программистами и тестировщиками истинная причина – это разные цели. Стоит поставить перед ними одну общую цель – и все сразу изменится! Программисты и тестировщики станут лучшими друзьями, всегда будут помогать друг другу, а от этого выиграют все – и программисты, и тестировщики, и менеджеры, и продукты, и компания!
Tags:
Hubs:
Total votes 66: ↑52 and ↓14 +38
Views 14K
Comments Comments 37