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

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

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

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

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

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

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

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

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

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

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

- Скажите, пожалуйста, куда мне отсюда идти? – спросила Алиса.
- Это во многом зависит от того, куда ты хочешь попасть, – ответил Кот.
- Да мне почти все равно, – начала Алиса.
- Тогда все равно, куда идти, – ответил Кот
© Алиса в стране чудес

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

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

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

Давным-давно в нашей галактике шла война между Тестировщиками и Разработчиками.

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

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

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

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

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

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

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

Вы – руководитель команды тестировщиков. Завтра приходит новый человек. О чем стоит подумать? Где могут возникнуть проблемы и как с ними бороться? Как вписать нового человека в процесс тестирования?

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

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

Тест-менеджер может использовать багтрекер не только для учета багов, но и для тестирования самого процесса тестирования.

Как?

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

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

Работающее программное обеспечение важнее, чем полная документация (с) Agile Manifesto

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

Будут рассмотрены следующие вопросы:
- workflow требований
- настройка Jira для управления требованиями
- workflow тестов
- настройка Jira для управления тестами и тест-кейсами
- кратко о метриках

Бытует противоречивое мнение, что на проекте обязательно должен быть тестировщик. Но тестировщик – это скорее роль, чем конкретный человек. И эта роль может быть распределена между всеми членами команды.

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

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

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

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

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