Chief ConfeT&QA: 14-15-16 октября
Fun ConfeT&QA: 28-29-30 октября
Selen ConfeT&QA: 25-26-27 ноября
Mobile ConfeT&QA: 9-10-11 декабря

28.04.2012

Chief ConfeT&QA, весна 2012


Конференция для тест-менеджеров Chief ConfeT&QA проходила 12-13-14 марта 2012 года. Записи выступлений и обсуждение докладов доступны участникам в закрытом форуме.

12 марта 2012 года
17:00 Definition of done или ставим задачи по S.M.A.R.T, Анна Скумина
17:40 Читаем багтрекер между строк или тестирование процесса разработки, Сергей Вербенко
18:20 Google Docs как инструмент ежедневного тест менеджмента, Ксения Лещенко
18:40 JIRA: dashboards и SOAP API, Никита Налютин
13 марта 2012 года
17:00 Волшебный пендель для развития (система корпоративного обучения), Виктория Птицына
17:40 Внедрение новичка в команду тестировщиков, Жанна Битюкова
18:20 Тестерская конфликтология или как вытаскивать “вбитые в голову гвозди”, Сергей Атрощенков
18:40 Тестировщик и заказчик – заклятые друзья?, Татьяна Зинченко
14 марта 2012 года
17:00 Жизнь без тестировщиков: миф или реальность?, Николай Алименков
17:40 Планирование тестирования как ежедневная активность тест-менеджера, Наталья Руколь
18:20 Требования в Jira: Just do it!, Даша Гармаш
18:40 Шаринг одного человека на нескольких проектах: как не запороть всё, Андрей Мясников

1 Волшебный пендель для развития (система корпоративного обучения)
Виктория Птицына (Россия)
Развитие сотрудников… Каждый тест-менеджер задумывался об этом хоть однажды (и не важно сколько человек в команде тестировщиков: 2 или 50). А зачем это вообще? Как это можно делать? И самое главное: А нужно ли это сотрудникам???

Ответы на эти вопросы помогут сделать из хаоса более понятную и стройную систему. Я в своей практике сталкивалась с организацией обучения и готова делиться всеми имеющимися наработками и примерами. Самое главное: не бойтесь задавать вопросы. Ведь вместе мы – сила! И обязательно найдем подходящий именно вам вариант решения задачи.

 

2 Планирование тестирования как ежедневная активность тест-менеджера
Наталья Руколь (Россия)
Планирование – это не написание бумажек и не согласование сроков. Планирование – это непрерывный процесс, помогающий в достижении поставленных вами целей. Даже если разработчики не предоставляют сборку вовремя, даже если вы не получили требуемое оборудование, даже если у вас заболел ключевой сотрудник… Вы всё равно можете достигнуть поставленных целей, если планирование будет вашим ежедневным действием.

На этом докладе я рассмотрю следующие вопросы:

  • Что такое планирование тестирования?
  • Зачем нужны тест-планы и стратегия тестирования?
  • Как нивелировать риски, если они не зависят от вас?
  • Какие способы мониторинга проекта всегда доступны?
  • Кто должен участвовать в планировании?
  • Как сделать “всё хорошо, и желательно вчера”?
 

3 Один человек на нескольких проектах: как не запороть всё
Андрей Мясников, Undev (Россия)
“РМ: Андрей, мне нужно чтоб ты это сделал через час.
Т: Вова, на мне ещё 4 проекта, я не могу уделять всё время только тебе!
РМ: А зачем ты их брал?
Т: Так они же маленькие и по времени получается нормально.
РМ: Да вот что-то не получается у тебя!”

Знакомо? Считаешь загрузку, планируешь, и по всем расчётам выходит, что справишься. А на деле – запарываешь всё.

Но что делать, если на каждый маленький проект невозможно выделить отдельного сотрудника, и необходимо совмещать различные задачи? Как распределять время, как планировать загрузку, как избегать простоев и переработок? И главное – как ловить кайф, работая над несколькими проектами сразу?

Мне постоянно приходится “жонглировать” проектами, и я расскажу, как мне удается с этим справляться.

 

4 Google Docs как инструмент ежедневного тест менеджмента
Ксения Лещенко, SysIQ Inc. (Украина)
В нашей компании мы уже не представляем себе наши рабочие процессы без всех благ Google сервиса – и почта, и календарь, и таски, и конечно же гуглодоки.

Используя гуглодоки можно обмениваться информацией откуда угодно, где есть интернет, с кем угодно, в режиме реального времени, разграничивать права на доступ к документам и т.д. Сначала мы использовали гуглодоки хаотично – для каких-то внутренних дел небольшой группы людей. Теперь же мы перешли на уровень, когда такие документы являются полноценными артефактами проекта. Удобно же!

Я расскажу и покажу, какой информацией, в каком виде и с кем мы делимся, а также радости и опасности использования гуглодоков.

 

5 Definition of done или ставим задачи по S.M.A.R.T.
Анна Скумина, Apriorit (Украина)
– Скажите, пожалуйста, куда мне отсюда идти? – спросила Алиса.
– Это во многом зависит от того, куда ты хочешь попасть, – ответил Кот.
– Да мне почти все равно, – начала Алиса.
– Тогда все равно, куда идти, – ответил Кот
© Алиса в стране чудес

У каждого из нас вызовет ухмылку требование к продукту “программа должна работать быстро” – слишком неформальное требование. Но при этом мы часто просим “быстренько протестировать последний билд”.

И не удивляйтесь потом, что “быстренько” для вас означало совсем не то же самое количество времени, что и для другого человека.

Подход S.M.A.R.T. даст вам возможность раз и навсегда натренировать “мышцу постановки задач”: ставим задачи правильно – и команда гарантировано производит правильный результат.

 

6 Тестерская конфликтология или как вытаскивать “вбитые в голову гвозди”
Сергей Атрощенков, VIAcode (Россия)
Давным-давно в нашей галактике шла война между Тестировщиками и Разработчиками.

Императорские офицеры то просили придержать коммит, то задавали провокационные вопросы вроде “А почему критический баг только сейчас завели?!”

Силы повстанцев были слишком малы, чтобы
+ конструктивно объяснить любимым разработчикам их неправоту,
+ выработать совместное отличное решение
+ и радостно разбежаться по своим Татуинам, делать самый лучший софт во всей Вселенной.

Эмоции и неконструктивность мешали проводить дружеские беседы. Вместо того, чтобы решать проблему, стороны начинали решать человеков. Дипломаты затыкались, начинало говорить оружие: пиу, тыдыдыщь, ба-ах, вжжынннн!

Но однажды на далекой (и близкой) планете с одной луной родился человек, который знал, как можно уже вытащить посаженные “занозы” в общении между противоборствующими сторонами, и как постараться не засадить новые. Силу большую чуял он!

Давайте нарушим правило “сам козёл” в многолетней войне за производство качественного ПО.

 

7 JIRA: dashboards и SOAP API
Никита Налютин, Undev (Россия)
Отчетность, отчетность, отчетность – разным руководителям, коллегам по цеху, субподрядчикам, заказчикам, себе, в конце концов. Как начинающему и не очень начинающему тест-менеджеру не утонуть в цифрах и отчетах и не сидеть до ночи на работе, подготавливая их каждый день? Вы сможете значительно облегчить себе жизнь, если будете грамотно использовать багтрекер. Например, в JIRA есть средства генерации dashboards и внешнее SOAP API для выполнения рутинных операций.

В данном докладе будут затронуты следующие вопросы:
– Какие типичные отчеты готовит тест-менеджер
– Как JIRA фильтрует тикеты
– Как объединять фильтры в dashboards и получать из этого полезную информацию
– Что такое JIRA SOAP API
– Как писать скрипты для сбора статистики по тикетам

 

8 Внедрение новичка в команду тестировщиков
Жанна Битюкова, EPAM (Украина)
Вы – руководитель команды тестировщиков. Завтра приходит новый человек. О чем стоит подумать? Где могут возникнуть проблемы и как с ними бороться? Как вписать нового человека в процесс тестирования?

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

А также поговорим о вещах сугубо тестерских:
– новый тестировщик vs программисты;
– новый тестировщик vs другие тестировщики;
– новый тестировщик vs bug traсker;
– новый тестировщик vs тесты (проектирование, документирование, управление) в команде;
– новый тестировщик vs тестирование (прогон тестов, поиск багов) и отчетность.

 

9 Читаем багтрекер между строк или тестирование процесса разработки
Сергей Вербенко, S-Terra CSP (Россия)
Тест-менеджер может использовать багтрекер не только для учета багов, но и для тестирования самого процесса тестирования.

Как?

Багтрекер аггрегирует разную информацию: об ошибках, о сборках, о затратах. Комбинируя её различным способами можно получить те или иные выводы о том, как протекает разработка.

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

 

10 Требования в Jira: Just do it!
Даша Гармаш (Россия)
Работающее программное обеспечение важнее, чем полная документация (с) Agile Manifesto

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

Будут рассмотрены следующие вопросы:
– как жить без аналитика?
– требования: их нет, но они нужны
– проектируем workflow требований для команды разработчики/тестировщики
– общение с заказчиком через постановку требований
– рука на пульсе: кратко об отчетах

Do it в Jira!

 

11 Жизнь без тестировщиков: миф или реальность?
Николай Алименков (Украина)
Бытует противоречивое мнение, что на проекте обязательно должен быть тестировщик. Но тестировщик – это скорее роль, чем конкретный человек. И эта роль может быть распределена между всеми членами команды.

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

 

12 Тестировщик и заказчик – заклятые друзья?
Татьяна Зинченко (Украина)
Представим на минуту, что на проекте нет аналитика. Представили? Или даже так: у нас во всей компании нет ни одного аналитика. И никогда не было. И не будет. Представили?
А ведь в большинстве случаев жизнь без аналитика – это реалии наших проектов.

Что делать тогда? Полагаться на мнение разработчиков о том, как должна работать система? Догадываться самому, исходя из расплывчатых требований? В условиях отсутствия требований перебирать все имеющиеся в отрасли стандарты и активно взывать к ним?

Или все же попытаться сделать проект таким, каким его хочет видеть заказчик (а не программист или отраслевые стандарты)?

Пытаться подружиться с заказчиком или и дальше делать вид, что его не существует? Я расскажу о своем выборе за 15 конфетко-минут. А что делать вам – решайте после доклада :)