Home

Автор: Горбачик Лилия

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

Тем более интересно будет описать процесс тестирования в Open Source, который имеет явные отличия от процесса тестирования коммерческого продукта.

Начнем с начала: формирование  команды тестирования. В коммерческом продукте все ясно с этой стадией: набирается команда (новые сотрудники), либо привлекают сотрудников из других отделов, либо и то, и другое. Каждый из них понимает свою роль в проекте: 40 часов в неделю он будет делать то-то и то-то. Что же с командой тестирования в Open Source проектах? Тут не все так очевидно. Проекты могут быть маленькие, в которых нет специально выделенной и обозначенной роли тестировщика. В этом случае тестирование лежит на плечах самих разработчиков, которые выполняя публичную работу (т.е. пишут код, который доступен широкой публике), стараются сделать это максимально качественно. Есть еще пользователи этого Open Source продукта, которые  пишут найденные багги, обсуждают на форуме плюсы и минусы продукта, предлагают новые фичи. Есть большие проекты, в которых есть тестирование в качестве выделенной активности. Обычно, это уже состоявшиеся и развитые проекты, как например, линейка Mozilla.  Для таких проектов (обычно достаточно больших) привлекаются энтузиасты, поклонники различными способами. Во-первых, это пользователи, приверженцы данного продукта, которые решили внести вклад в развитие своего любимого продукта (или не совсем самого любимого, но перспективного и стоящего на их взгляд). Во-вторых, это пользователи, которые привлекаются из различных community путем агитации: призывы на форумах, ролики, сарафанное радио; специальные сайты, которые посвящены поиску волонтеров для Open Source проектов итд. Так же существует практика участия студентов, которые делают первые шаги, наращивают свои навыки на живом проекте. Зарубежные университетские преподаватели вовлекают студентов в участие Open Source проектов, чтобы приблизить лабораторные занятия к реальным условиям, научить студентов работать в команде.

Итак, есть некая группа людей, которые согласны участвовать (возможно, и не до конца уверены) в тестировании некого Open Source проекта. Но толпа – это еще не команда. Остается не менее важная задача – сделать команду (в которой неизвестное количество человек), наладить прозрачный процесс тестирования и взаимодействия между членами команды.

Для того, чтобы обучить новичка, в коммерческом проекте обычно нет налаженного и регламентированного процесса. В Open Source проекте, наоборот, это очень важный момент, который требует тщательной проработки и документации. Например, есть человек, который желает принять участие в тестировании Open Source проекта. Прежде всего, ему надо понять, как работает продукт, затем, как налажен процесс тестирования, какие есть активности, какие вспомогательные инструменты, какую помощь ждет от него проект. Обычно, для этих целей есть либо ознакомительные документы «Мы рады видеть вас», либо вики странички, содержащие информацию и ссылки. От того, насколько понятна и прозрачна эта первичная информация, какой энергетикой заряжает своего читателя, зависит, останется ли этот доброволец тестировать проект или нет. Поэтому, документации «Мы рады видеть вас» уделяется большое внимание. В ней с самого начала употребляется «мы – команда, нам важен именно твой вклад», чтобы свести сомнения новичка к минимуму.

Составление команды из независимых и хаотично присутствующих людей, на мой взгляд, это искусство и талант, нет, скорее талантище. Менеджер по тестированию (если таковой имеется), представляется в роли мастера на все руки. Он планирует все виды активности, делает соответствующий документ \ страничку на вики, со скоростью света распределяет (а потом и перераспределяет по тысяче раз) все намеченные на короткий период (обычно неделя - две) задания между участниками проекта, при нехватке людей вещает в широкополосном режиме, призывая на помощь энтузиастов,  делает отчеты, анализирует состояние, слабые места проекта. И самое главное, у него нет никакой уверенности в том, что все намеченное будет сделано.  Люди приходят, уходят, на них нельзя надавить, их можно только увлечь за собой. Вот такая несладкая картина вырисовывается. Но есть такие люди, которые хотят каждый день прожить на острие ножа. Наверно, именно они и исполняют роль тест менеджера open source проекта.

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

Заслуживает внимания и рассмотрения подход к средствам тестирования. Система баг-треккинга, framework для автоматических кейсов, система хранения кейсов обычно являются либо open source, либо самописными, что неудивительно.

Для open source проекта приоритетным и важным является автоматическое тестирование, т.к. единожды написанный тест будет еще долго служить проекту после ухода его автора. Автоматические тесты дают зеленый свет другим участникам проекта после сборки. Опять же, важным является не только написание бага \ теста, но и документирование. Все построено на том, чтобы писать баг \ тест понятным не себе, а окружающим. Твоя работа является публичной, а это организует. Зачастую, в коммерческих проектах к документированию своей работы относятся не так щепетильно.

Одни приходят, другие уходят, но процесс тестирования идет… Все держится на личной мотивации. Странно, там, где платят деньги, постоянно ищут мотивацию для сотрудников. В open source проекте ищут людей с мотивацией, другие просто проходят мимо.

Обсудить в форуме