Персональные инструменты
 

Системы, которых должен знать каждый QA (Стас Фомин на встрече MSTC 2012-12-16) — различия между версиями

Материал из CustisWiki

Перейти к: навигация, поиск
(Новая страница: «;Докладчик: Стас Фомин. <blockquote> Весьма распространено мнение, что тестировщик ...»)
 
м
Строка 1: Строка 1:
 
;Докладчик: [[User:StasFomin|Стас Фомин]].
 
;Докладчик: [[User:StasFomin|Стас Фомин]].
 +
 +
;Краткая выжимка:
 +
[[File:Системы, которых должен знать каждый QA (дайджест).svg|center|800px]]
 +
  
 
<blockquote>
 
<blockquote>
Строка 32: Строка 36:
 
;Системой управления версиями: у нас <tt>Subversion</tt> — известнейшая централизованная система управления исходным кодом, а также смежными с ней системами [[SVNSearcher]] и [[ViewVC]].
 
;Системой управления версиями: у нас <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]), с другой стороны, личный опыт свидетельствует о пока еще слабом покрытии аудитории докладами и статьями, и то, что кажется ужасным баяном от К.О., часто оказывается кладезем свежих решений.
+
 
</blockquote>
 
</blockquote>
  
 
;Видео:
 
;Видео:
  
{{vimeoembed||720|405}}
+
{{vimeoembed|8758359|800|500}}
  
 
----
 
----
 +
 +
Доклады на эту тему, в общих чертах уже были и ранее, причем доступны для самостоятельного просмотра ([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]), однако, видео с конференций смотрят мало, а лично и тем более редко кто ходит, так что ни для кого в зале это не было баяном от К.О.
 +
 +
 
<references/>
 
<references/>
  

Версия 01:00, 1 сентября 2012

Докладчик
Стас Фомин.
Краткая выжимка
Системы, которых должен знать каждый QA (дайджест).svg


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

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

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

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


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

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

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

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

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

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

Таких решений (платных и бесплатных) можно придумать множество, мы же расскажем о нашем — наверняка не самом худшем, проверенным многолетним опытом и основанном на бесплатных и свободно доступных системах с открытым исходным кодом. Мы познакомимся с несколькими системами групповой работы, покрывающими весь спектр современной разработки, а именно, системами:

Issue-трекинга
(в нашем случае Bugzilla + Testopia) — учет задач, заданий, ошибок, проблем и отвественности любого рода, в частности, тест-планов, тест-прогонов и т.п.
Вики-системой
(у нас — MediaWiki) — «универсальный швейцарский нож», подходящий для ведения документации, требований, тест-кейсов, знаний, регламентов, процессов, моделей и т.п.
Системой управления версиями
у нас Subversion — известнейшая централизованная система управления исходным кодом, а также смежными с ней системами SVNSearcher и ViewVC.

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

Видео


Доклады на эту тему, в общих чертах уже были и ранее, причем доступны для самостоятельного просмотра ([1], [2], [3], [4]), однако, видео с конференций смотрят мало, а лично и тем более редко кто ходит, так что ни для кого в зале это не было баяном от К.О.


  1. Continuous Integration, — концепция непрерывного тестирования по малейшему изменению в хранилище кода.

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Системы, которых должен знать каждый QA (Стас Фомин на встрече MSTC 2012-12-16)»