Difference between revisions of "Системы, которых должен знать каждый QA"

From Wiki4Intranet
Jump to: navigation, search
 
(3 intermediate revisions by the same user not shown)
Line 6: Line 6:
  
 
На самом деле, ситуация совершенно иная — в сильной, профессиональной команде разработчиков, когда неизбежно наблюдается профессиональная деформация психотипов, тестировщики являются онтологическим балансом для разработчиков.
 
На самом деле, ситуация совершенно иная — в сильной, профессиональной команде разработчиков, когда неизбежно наблюдается профессиональная деформация психотипов, тестировщики являются онтологическим балансом для разработчиков.
{{note}} Можно примерять различные модели командной работы и типологии личности (модели Адизеса, Белбина, Юнга), и во всех случаях, тестировщики («Администраторы» по Адизесу, и «Контроллеры» по Юнгу), равнозначно комплиментарны программистам («Производителям»  и «Предпринимателям» по Адизесу, «Анализаторам» и «Моторам» по Юнгу). Если программисты ориентированы на прорыв, риски и глобальные выигрыши (иначе это слабые, негодные программисты), на поиск наиболее экономичных стратегий реализации, то именно QA должны ограничивать эти процессы, страхуясь от рисков потери временных ресурсов  (''waste'' времени, кода) и потери потребителя (срыв сроков, нарушение требований, неудовлетворенность пользователя).
+
----
 +
Можно примерять различные модели командной работы и типологии личности (модели Адизеса, Белбина, Юнга), и во всех случаях, тестировщики («Администраторы» по Адизесу, и «Контроллеры» по Юнгу), равнозначно комплиментарны программистам («Производителям»  и «Предпринимателям» по Адизесу, «Анализаторам» и «Моторам» по Юнгу). Если программисты ориентированы на прорыв, риски и глобальные выигрыши (иначе это слабые, негодные программисты), на поиск наиболее экономичных стратегий реализации, то именно QA должны ограничивать эти процессы, страхуясь от рисков потери временных ресурсов  (''waste'' времени, кода) и потери потребителя (срыв сроков, нарушение требований, неудовлетворенность пользователя).
 +
---
  
 
И в ситуации, когда тестировщики не имеют иерархических преимуществ («менеджер проекта=QA»), самый эффективный из конструктивных и неконфликтных путей системного контроля качества разработки, это создание и управление инфраструктурой разработки, такой, что не сильно затруднит, и даже поможет работе программиста, и при этом даст возможность QA-специалистам держать контроль над процессом — страхуясь от различных программистких рисков («потеря кода», «сброс кодовых бомб»,  «неизлечимо завшивевший багами код» …).
 
И в ситуации, когда тестировщики не имеют иерархических преимуществ («менеджер проекта=QA»), самый эффективный из конструктивных и неконфликтных путей системного контроля качества разработки, это создание и управление инфраструктурой разработки, такой, что не сильно затруднит, и даже поможет работе программиста, и при этом даст возможность QA-специалистам держать контроль над процессом — страхуясь от различных программистких рисков («потеря кода», «сброс кодовых бомб»,  «неизлечимо завшивевший багами код» …).
Line 21: Line 23:
  
 
Таких решений (платных и бесплатных) можно придумать множество, мы же расскажем о нашем — наверняка не самом худшем, проверенным многолетним опытом и основанном на бесплатных и свободно доступных системах с открытым исходным кодом.  Мы познакомимся с несколькими системами групповой работы, покрывающими весь спектр современной разработки, а именно, системами:
 
Таких решений (платных и бесплатных) можно придумать множество, мы же расскажем о нашем — наверняка не самом худшем, проверенным многолетним опытом и основанном на бесплатных и свободно доступных системах с открытым исходным кодом.  Мы познакомимся с несколькими системами групповой работы, покрывающими весь спектр современной разработки, а именно, системами:
;Issue-трекинга: (в нашем случае <tt>Bugzilla</tt>+<tt>Testopia</tt>) — учет задач, заданий,  ошибок, проблем и отвественности любого рода, в частности, тест-планов, тест-прогонов и т.п.
+
;Issue-трекинга: (в нашем случае [[Bugzilla]] + [[Testopia]]) — учет задач, заданий,  ошибок, проблем и отвественности любого рода, в частности, тест-планов, тест-прогонов и т.п.
  
 
;Вики-системой: (у нас — <tt>MediaWiki</tt>) — «универсальный швейцарский нож», подходящий для ведения документации, требований, тест-кейсов, знаний, регламентов, процессов, моделей и т.п.
 
;Вики-системой: (у нас — <tt>MediaWiki</tt>) — «универсальный швейцарский нож», подходящий для ведения документации, требований, тест-кейсов, знаний, регламентов, процессов, моделей и т.п.
  
;Системой управления версиями: у нас <tt>Subversion</tt> — известнейшая централизованная система управления исходным кодом, а также смежными с ней системами <tt>SVNSearch</tt> и <tt>ViewVC</tt>.
+
;Системой управления версиями: у нас <tt>Subversion</tt> — известнейшая централизованная система управления исходным кодом, а также смежными с ней системами [[SVNSearcher]] и [[ViewVC]].
  
 
А также узнаем, как должны интегрироваться и взаимодействовать эти (ну или аналогичные системы).           
 
А также узнаем, как должны интегрироваться и взаимодействовать эти (ну или аналогичные системы).           
 
 
----
 
----
  
 
Форма доклада пока не ясна, возможно это будет  просто доклад-демонстрация, возможно — ведомый вопросами зрителей мастер-класс, с разбором поставленных аудиторией вопросов, а возможно и небольшой тренинг-интерактив, когда можно попробовать все эти системы «живьем» — для этого нужно как минимум ноутбук и желание активного участия — тогда можно живьем, через интернет попробовать все эти системы решая игровые задачи.
 
Форма доклада пока не ясна, возможно это будет  просто доклад-демонстрация, возможно — ведомый вопросами зрителей мастер-класс, с разбором поставленных аудиторией вопросов, а возможно и небольшой тренинг-интерактив, когда можно попробовать все эти системы «живьем» — для этого нужно как минимум ноутбук и желание активного участия — тогда можно живьем, через интернет попробовать все эти системы решая игровые задачи.
  
Предложения по формату весьма желательны, ибо с одной стороны, доклады на эту тему, в общих чертах уже были весной, и доступны для самостоятельного просмотра ([http://lib.custis.ru/%D0%A1%D0%B2%D0%BE%D0%B1%D0%BE%D0%B4%D0%BD%D1%8B%D0%B5_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B,_%D1%81%D0%BF%D0%B0%D1%81%D0%B0%D1%8E%D1%89%D0%B8%D0%B5_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%87%D0%B8%D0%BA%D0%BE%D0%B2_%28%D0%A0%D0%98%D0%A2-2010%29], [http://lib.custis.ru/Knowledge-management-from-store-to-flow]), с другой стороны, личный опыт свидетельствует о пока еще слабом покрытии аудитории докладами и статьями, и то, что кажется ужасным баяном от К.О., часто оказывается кладезем свежих решений.
+
Предложения по формату весьма желательны, ибо с одной стороны, доклады на эту тему, в общих чертах уже были и доступны для самостоятельного просмотра ([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 минут до полутора часов.
 
По времени надо ориентироваться от 50 минут до полутора часов.
  
Так что предложения по формату и прочие идеи  — что и как рассмотреть, с благодарностью будут рассмотрены [http://belonesox.moikrug.ru|Стасом Фоминым], по адресу [mailto:stas-fomin@yandex.ru|stas-fomin@yandex.ru].
+
Так что предложения по формату и прочие идеи  — что и как рассмотреть, с благодарностью будут рассмотрены [http://belonesox.moikrug.ru Стасом Фоминым], по адресу [mailto:stas-fomin@yandex.ru stas-fomin@yandex.ru].
 +
 
 +
Впрочем, можно голосовать и здесь (распределите два ваших голоса по предложенным вариантам):
 +
<poll>
 +
POINTS 2
 +
Какой формат встречи «Системы, которых должен знать каждый QA» вас интересует:
 +
Стандартное выступление со слайдами
 +
Динамичное выступление под видео (плотность информации велика, интерактивность низка)
 +
Мастер-класс-демонстрация по вопросам аудитории (интерактивная реакция на ваши вопросы, работа с живыми системами)
 +
Тренинг-интерактив (вы сами участвуете и играетесь с демонстрируемыми системами). От вас — ноутбук.
 +
</poll>

Latest revision as of 21:19, 1 December 2010

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

Впрочем, можно голосовать и здесь (распределите два ваших голоса по предложенным вариантам):

Какой формат встречи «Системы, которых должен знать каждый QA» вас интересует:

You have 2 points to vote.
  •  Стандартное выступление со слайдами
  •  Динамичное выступление под видео (плотность информации велика, интерактивность низка)
  •  Мастер-класс-демонстрация по вопросам аудитории (интерактивная реакция на ваши вопросы, работа с живыми системами)
  •  Тренинг-интерактив (вы сами участвуете и играетесь с демонстрируемыми системами). От вас — ноутбук.
  1. Continuous Integration, — концепция непрерывного тестирования по малейшему изменению в хранилище кода.