Перейти к содержимому

Аудит и оптимизация QA-процессов
онлайн, начало 4 декабря
Практикум по тест-дизайну 2.0
онлайн, начало 4 декабря
Логи как инструмент тестировщика
онлайн, начало 30 ноября
Тестирование REST API
онлайн, начало 30 ноября
Фотография

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


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 4

Опрос: Системы, которые должен знать каждый QA (18 пользователей проголосовало)

Какой формат хотелось-бы видеть?

  1. Мастер-класс-демонстрация по вопросам аудитории (интерактивная реакция на ваши вопросы, работа с живыми системами) (12 голосов [70.59%])

    Процент голосов: 70.59%

  2. Тренинг-интерактив (вы сами участвуете и играетесь с демонстрируемыми системами). От вас — ноутбук. (2 голосов [11.76%])

    Процент голосов: 11.76%

  3. Стандартное выступление со слайдами (0 голосов [0.00%])

    Процент голосов: 0.00%

  4. Динамичное выступление под видео (плотность информации велика, интерактивность низка) (3 голосов [17.65%])

    Процент голосов: 17.65%

Голосовать Гости не могут голосовать

#1 Bars Master

Bars Master

    Постоянный участник

  • Members
  • PipPipPip
  • 178 сообщений
  • ФИО:Фролов Борис
  • Город:Volgograd, Moscow

Отправлено 01 декабря 2010 - 18:46

Коллеги, на предстоящей встрече Стас Фомин выступит с темой: Системы, которые должен знать каждый QA. Выступление на данную тему возможно в нескольких форматах:
* Мастер-класс-демонстрация по вопросам аудитории (интерактивная реакция на ваши вопросы, работа с живыми системами)
* Тренинг-интерактив (вы сами участвуете и играетесь с демонстрируемыми системами). От вас — ноутбук.
* Стандартное выступление со слайдами
* Динамичное выступление под видео (плотность информации велика, интерактивность низка)


Голосуйте! Формат, который наберет большинство голосов будет использован на встрече.

Описание темы (Оригинал на custis.ru):

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

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

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

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

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

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

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

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

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

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

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

Issue-трекинга
(в нашем случае Bugzilla + Testopia) — учет задач, заданий, ошибок, проблем и отвественности любого рода, в частности, тест-планов, тест-прогонов и т.п.

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

Системой управления версиями
у нас Subversion — известнейшая централизованная система управления исходным кодом, а также смежными с ней системами SVNSearcher и ViewVC.

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


  • 0

#2 Natalya Rukol

Natalya Rukol

    Гуру

  • Admin
  • PipPipPipPipPipPip
  • 2 001 сообщений
  • Город:Moscow


Отправлено 05 декабря 2010 - 09:18

Не все смогут прийти с ноутами. Предлагаю в. #1 с возможностью задачек для владельцев ноутов.
  • 0

#3 belonesox

belonesox

    Новый участник

  • Members
  • Pip
  • 11 сообщений
  • ФИО:Фомин Станислав Александрович
  • Город:Москва

Отправлено 08 декабря 2010 - 21:20

Голосуйте! Формат, который наберет большинство голосов будет использован на встрече.


А оно вообще может не интересно? Проголосовало всего десяток народу.
Может надо было пункт this theme sucks добавить?
  • 0

#4 Bars Master

Bars Master

    Постоянный участник

  • Members
  • PipPipPip
  • 178 сообщений
  • ФИО:Фролов Борис
  • Город:Volgograd, Moscow

Отправлено 09 декабря 2010 - 07:27

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

#5 ch_ip

ch_ip

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 097 сообщений
  • ФИО:Павел Абдюшев
  • Город:Москва


Отправлено 09 декабря 2010 - 07:30

А оно вообще может не интересно? Проголосовало всего десяток народу.
Может надо было пункт this theme sucks добавить?

15 человек - это достаточно много. Особенно, учитывая факт, что голосуют только те, кто собирается придти или раздумывает об этом...
  • 0


Инструменты тестировщика: Командная строка
онлайн
Практикум по тест-дизайну 2.0
онлайн
Программирование на Phyton для тестировщиков
онлайн
Тестирование производительности (JMeter)
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале