29.12.2012

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

1 О неразделении труда или как я из тестеров стала директором

Ольга Пономарёва (Россия)

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

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

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

2 Стратегия тестирования

Наталья Руколь (Россия)

Вам на тестирование поступает продукт. Что вы можете сделать дальше? Как вариант – провести поверхностную декомпозицию работ, распределить её в команде и приняться за тестирование. Но уверены ли вы, что в этом случае всё будет хорошо протестировано? Можете ли гарантировать максимальную отдачу?

Скорее всего, нет. Прежде, чем приступать к тестированию продукта, итерации или даже отдельно взятой сборки, необходимо продумать: а КАК это нужно делать?
* Какие виды и типы тестов необходимы?
* Как понять, что «пора остановиться»?
* С чего начать, какие приоритеты?
* Как распределить ресурсы?
* Что и каким образом нужно документировать?

Только заранее продумав, что и как вы будете тестировать, вы сможете получить максимальные результаты. Но как это сделать? Сколько времени выделить? Каким образом определить? Как зафиксировать результаты? Как потратить минимум времени на начальном этапе, и при этом достичь максимальных результатов в самом тестировании?

Ответы на все эти вопросы – на докладе для стратегов и тактиков тест-менеджмента.

3 Семь принципов Кванза в работе тест-менеджера

Сергей Атрощенков (Россия)

Когда-то давным-давно, в середине 60-х, в США появился праздник Кванза. Это один из афроамериканских фестивалей, представляющий собой неделю предновогодних торжеств. Считается, что праздник «первого плода» отмечался в древней Нубии в эпоху фараонов, кроме того, его праздновали в средневековых африканских государствах Йоруба и Ашанти. В основу праздника положены африканские традиции и глубинная мысль, провозглашающая Семь Принципов жизни и ценностей сообщества: Единство, Самоопределение, Коллективизм, Совместная экономика, Цель, Творческий потенциал и Вера.

Казалось бы, при чем здесь тестирование?

Да при том, что принципы данного веселого мероприятия очень хорошо ложатся в основу работы любых IT команд, а в нашем случае – тестировщиков.

А когда таких принципов целых семь… Есть где развернуться и организаторским навыкам, и фантазии, и аналитическим способностям всё-улучшающего ума.
Чем принцип Единства не прекрасная возможность объединять различные роли: аналитиков, разработчиков, программистов, системных администраторов в едином порыве, нацеленном на работу над качественным продуктом?
А принцип Творчества? Чем не возможность проявить себя в тест-аналитике?

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

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

4 Как тест-менеджеру развивать свою команду?

Анна Скумина (Украина)

В мире нет постоянства. Что не движется вперед, стремительно катится назад. Не обходит этот закон и наши профессиональные знания и навыки.С одной стороны, нам, QA, с этим повезло: непрерывное развитие технологий приводит к тому, что волей-неволей сталкиваясь с новыми задачами, мы узнаем что-то новое и практически ежедневно совершенствуем свои навыки.

Стоит ли дополнительно стимулировать команду к развитию? Возможно, нужна сертификация? А может, как предлагают евангелисты context-driven school в противовес сертификации, развивать знания в узких областях, таких как когнитивная психология, usability и основы проектирования интрефейсов и взаимодействия?

И еще один важный вопрос: как организовать обучение? Приглашать тренеров, или наладить внутренний процесс обмена знаниями? В докладе я поделюсь с вами своим мнением на эту тему.

5 «Нам некуда расти!», или сила привычки

Ольга Киселева (Россия)

Хорошая команда, приятный коллектив, любимая работа… Что еще для счастья надо? И надо ли вообще?

Даже зная, что процессы неидеальны, мы продолжаем им следовать. И привыкаем. И считаем нормальными. Хорошо это или плохо?

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

Я предлагаю посмотреть на работу в двух параллельных командах и на личном примере убедиться в том, что теория «у нас все и так хорошо» не так уж правдива.

Место для роста есть всегда! Но чтобы его обнаружить, надо посмотреть на свою работу, на свою команду немного под другим углом. С другой точки зрения. Я расскажу вам о том, почему это важно и как это сделать.

6 Экспресс-собеседование: когда работа не ждет

Александр Федоров (Россия)

По роду своей деятельности еще недавно я проводил множество собеседований, при этом я не мог себе позволить тратить по часу на каждое – ведь работа не ждет. В то же время, подбор кадров для компании – ответственная задача, и спускать рукава тут никак нельзя. В результате я стал анализировать процесс собеседования с целью его оптимизации: как за минимальное время узнать максимум полезной информации о кандидате на роль тестировщика? С результатом моих изысканий вы сможете ознакомиться на моём докладе. Он будет полезен тем менеджерам, кто ценит свое время и так же помешан на рациональности, как и я.

Вы узнаете:

* какие вопросы на собеседовании полезны, а какие только тянут время?
* какие задачки использовать, чтобы быстро оценить тестировщика?
* что делать, если вы сомневаетесь – брать сотрудника или нет?
* что делать с персональными симпатиями при подборе персонала?
* как поступить, если с самого начала вы понимаете, что этот сотрудник вам не подойдет?

7 Стратегия тестирования при работе с несколькими ветками

Александра Лебедева (Россия)

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

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

Эти ситуации приводят к появлению ряда острых вопросов, которые могут сильно повлиять на ход тестирования. Например, была ли исправлена ошибка в той ветке, которая поставляется заказчику; есть ли необходимость связывать тест-кейсы и находимые проблемы? Что следует учитывать при разделении процесса разработки на несколько версий?

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

8 Дехаотизация автоматизации

Татьяна Зинченко (Украина)

Все мы – опытные QA-менеджеры. Или QA-лиды. Или просто знаем как именно организовывать процессы тестирования. С нуля. Мы знаем что делать если нас позвали на новый проект: с чего начать, как продолжить, как набрать команду «под себя» и под каким соусом подать идею автоматизации высшему руководству.

А что делать, если вас позвали в уже готовый проект, где все уже давно внедрено и есть автоматизация? Только какая она – эта автоматизация?

Несколько лет назад началось это движение автоматизации по тестированию. Оно шло, шло и вот теперь уже видны явные перекосы, о которых нас никто не предупреждал вначале. Или предупреждал?

Так что же именно должна делать автоматизация? Как повернуть ее мощь в нужное русло? Какие метрики собирать? Об этом и еще немногом я расскажу за 20 конфетко-минут.

9 Как избежать ссор в команде тестировщиков и разрешить имеющиеся

Андрей Мясников (Россия)

Зачем работать в команде?
Ведь команда – это другие люди.
Другие точки зрения, другое восприятие.
Кто-то не сделает задачу, кто-то сделает не так, как надо.
Словом, трения неизбежны.
Но мы живем во времена корпораций, поэтому работая в компании почти невозможно работать не в команде.

В идеале, команда тестировщиков – это слаженный механизм, который работает как часы, выполняя поставленные перед ней задачи и принося прибыль компании.
Но что делать, если одна из шестеренок этого механизма не хочет крутить другую?

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

Ответы на эти и многие другие вопросы вы найдёте в моём докладе.

10 Метрики в тестировании. Практические советы

Николай Юденко (Украина)

«Ты не можешь контролировать то,
что ты не можешь измерить».
Том ДеМарко

Надеюсь, что слушатели знакомы с понятием метрик в разработке ПО. Я хочу рассказать об их использовании конкретно в тестировании, делая упор на практическое применение.

Как оценить выполненный объем? Или как оценить планируемый объем?
Что сказать прожект менеджеру о состоянии проекта, его качестве?
Как формализовать такие понятия в тестировании как «хорошо», «плохо», «нормально», «еще немного», «никогда»?
Как и главное на основании чего прогнозировать и планировать работу отдела тестирования?
Когда мы закончим тестирование?
Зачем нам столько тестировщиков?
Как нам поможет автоматизация?
Как мы можем влиять на разработку проудкта?

С подобными вопросы периодически сталкивается практически каждый тест менеджер (Test Manager) или ведущий тестировщик (Test Lead).
Я хочу рассказать и показать как мы можем «измерять тестирование» на разных этапах жизненного цикла ПО: от изучения требований до написания автотестов, от тест дизайна до регрессии, от функционального тестирования до внедрения.

Как при помощи «линейки и калькулятора» улучшать процесс тестирования и как следствие весь процесс разработки.

11 Тайм менеджмент для тест-менеджеров

Артём Поль (Россия)

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

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

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

* Как относиться к рабочему времени?
* Как определить, разумно ли используется рабочее время?
* Как не дать вороху дел накрыть себя с головой?
* Как поддерживать в тонусе длительные активности?
* Как поступать с теми, кто съедает ваше время?

12 Почему тестирование занимает так много времени

Николай Алименков (Украина)

Многие сейчас работают по итеративным подходам и регрессионное тестирование происходит на каждой итерации (я надеюсь). И часто происходит следующее: в одной итерации оно успело закончиться в срок, а в следующей не завершилось даже на 50%. Как же так? Ведь количество функциональности изменилось очень незначительно! И тут менеджеры начинают подозревать тестировщиков в недостаточной эффективности и берутся за анализ. В ход идут метрики и статистика… Возможно, кого-то увольняют… Но ситуация повторяется снова и снова. В докладе я подробно рассмотрю, что в действительности тормозит тестирование и как можно с этим бороться.