View source for Системы, которых должен знать каждый QA

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

На самом деле, ситуация совершенно иная — в сильной, профессиональной команде разработчиков, когда неизбежно наблюдается профессиональная деформация психотипов, тестировщики являются онтологическим балансом для разработчиков.
----
Можно примерять различные модели командной работы и типологии личности (модели Адизеса, Белбина, Юнга), и во всех случаях, тестировщики («Администраторы» по Адизесу, и «Контроллеры» по Юнгу), равнозначно комплиментарны программистам («Производителям»  и «Предпринимателям» по Адизесу, «Анализаторам» и «Моторам» по Юнгу). Если программисты ориентированы на прорыв, риски и глобальные выигрыши (иначе это слабые, негодные программисты), на поиск наиболее экономичных стратегий реализации, то именно QA должны ограничивать эти процессы, страхуясь от рисков потери временных ресурсов  (''waste'' времени, кода) и потери потребителя (срыв сроков, нарушение требований, неудовлетворенность пользователя).
---

И в ситуации, когда тестировщики не имеют иерархических преимуществ («менеджер проекта=QA»), самый эффективный из конструктивных и неконфликтных путей системного контроля качества разработки, это создание и управление инфраструктурой разработки, такой, что не сильно затруднит, и даже поможет работе программиста, и при этом даст возможность QA-специалистам держать контроль над процессом — страхуясь от различных программистких рисков («потеря кода», «сброс кодовых бомб»,  «неизлечимо завшивевший багами код» …).

Это выглядит нескольно нонсенсом — разве не система контроля версий является инструментом программистов и только их самих? Увы, нет — предоставленные сами себе, программисты вполне могут разменять перечисленные риски на дополнительные проценты личной эффективности, и например, вместо централизованной VCS с защищенным системой непрерывной интеграции<ref>''Continuous Integration'', — концепция непрерывного тестирования по малейшему изменению в хранилище кода.</ref> основным стволом разработки, будут пользоваться партизанскими распределенными репозиториями на своих ноутбуках. Также не в их интересах учет трудозатрат, задач, трекинг ошибок.
Так что вполне вероятен вариант, что в новой команде (или сильно запущенной старой), будут отсутствовать ключевые системы поддержки грамотной разработки, и если вы QA — то мягко и эволюционно внедрить их — это ваш цивилизационный долг, бремя белого человека.
К тому же, сейчас опять-таки, часто нет границы по навыкам между программистом, и продвинутым тестировщиком-автоматизатором, — последний вполне может быть «круче» первого в программировании, и вся инфраструктура поддержки разработки нужна и тестировщику напрямую.

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

Конечно, раньше, выбор инфраструктуры был прерогативной менеджмента, но часто это приводило к жутко неоптимальному выбору («Корпоративный стандарт управления версиями = СистемаМонстр™»), демотивирующему программистов, и современный менеджер скорее коммуникатор/психолог, а технические вопросы оставляет на выбор команде.

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

Таких решений (платных и бесплатных) можно придумать множество, мы же расскажем о нашем — наверняка не самом худшем, проверенным многолетним опытом и основанном на бесплатных и свободно доступных системах с открытым исходным кодом.  Мы познакомимся с несколькими системами групповой работы, покрывающими весь спектр современной разработки, а именно, системами:
;Issue-трекинга: (в нашем случае [[Bugzilla]] + [[Testopia]]) — учет задач, заданий,  ошибок, проблем и отвественности любого рода, в частности, тест-планов, тест-прогонов и т.п.

;Вики-системой: (у нас — <tt>MediaWiki</tt>) — «универсальный швейцарский нож», подходящий для ведения документации, требований, тест-кейсов, знаний, регламентов, процессов, моделей и т.п.

;Системой управления версиями: у нас <tt>Subversion</tt> — известнейшая централизованная система управления исходным кодом, а также смежными с ней системами [[SVNSearcher]] и [[ViewVC]].

А также узнаем, как должны интегрироваться и взаимодействовать эти (ну или аналогичные системы).          
----

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

Предложения по формату весьма желательны, ибо с одной стороны, доклады на эту тему, в общих чертах уже были и доступны для самостоятельного просмотра ([http://lib.custis.ru/OpenSourceSystemsRIT2010], [http://lib.custis.ru/Knowledge-management-from-store-to-flow], [http://lib.custis.ru/testopia-missing-link], [http://lib.custis.ru/dressing-subversion-viewvc-svnsearcher]), с другой стороны, личный опыт свидетельствует о пока еще слабом покрытии аудитории докладами и статьями, и то, что кажется ужасным баяном от К.О., часто оказывается кладезем свежих решений.
По времени надо ориентироваться от 50 минут до полутора часов.

Так что предложения по формату и прочие идеи  — что и как рассмотреть, с благодарностью будут рассмотрены [http://belonesox.moikrug.ru Стасом Фоминым], по адресу [mailto:stas-fomin@yandex.ru stas-fomin@yandex.ru].

Впрочем, можно голосовать и здесь (распределите два ваших голоса по предложенным вариантам):
<poll>
POINTS 2
Какой формат встречи «Системы, которых должен знать каждый QA» вас интересует:
Стандартное выступление со слайдами
Динамичное выступление под видео (плотность информации велика, интерактивность низка)
Мастер-класс-демонстрация по вопросам аудитории (интерактивная реакция на ваши вопросы, работа с живыми системами)
Тренинг-интерактив (вы сами участвуете и играетесь с демонстрируемыми системами). От вас — ноутбук.
</poll>