На нём используется всего три портлета:

• Time Sheet Summary на одну неделю. Позволяет оперативно видеть какими задачами и сколько времени (через Worklog) занимался сотрудник;
• Issue Calender с опцией показа крайнего срока (Due date). Позволяет определить сколько задач в ближайшее время должны быть завершены;
• Show Saved Filter With Columns с фильтром по открытым задачам на человека, показывает сколько всего задач, с каким сроком и приоритетом висят на сотруднике.

Остальные дашборды можно посмотреть тут и тут.

Тоже самое, по смыслу, время от времени говорил мне мой руководитель. Он не мог понять чем конкретно занимается мой депортамент, в какой последовательности и для чего. Оспаривать то, что работы делается много он не мог, но при этом и имел полное право не понимать, что же всё-таки делается.
На картинке выше четыре стиля отчета, использовавшиеся в разные промежутки времени (с 2006 года по начало 2009). Красная черта – это отметка страницы А4.

Первый отчет был предельно краток: “на проекте таком то сделали это и это, движемся в таком то направлении”. При этом текст основного отчета составлялся из того, что писали подчиненные (та еще каторга, сколько не напоминай, кто-нибудь да забудет. Да и литературным даром никто не обладал).

Название проекта

Что было сделано и какие проблемы встретились. Обычным человеческим языком.

Имена участников

Он не давал связи с реальными задачами в трекинговой системе и было не понятно, что делал каждый конкретный участник. Пораскинув мозгами и переборов лень подчиненных получилось сделать второй отчет на основе записей в Jira. Отчет содержал название задачи и ссылку на трекинг.

Имя

Задача 1 (под назавание ссылка)

Задача 2 (ссылка)

Он получился длиннее первого в несколько раз и хотя теперь можно было получить представление о том, что делал человек, понять, что происходит на проекте было сложнее, по самому отчету, нужно было идти в Jira и делать выборку. Так же он дополнялся страницами в Wiki (Confluence) по каждому проекту. Такие страницы описывали, как раз что происходит с проектом и конкретное участие сотрудников. Но на них надо было заходить специально. Лень руководства победила формат отчета, за год так и не получилось приучить сначала смотреть к Confluence, а потом спрашивать.

Путь от такого отчета к автоматической сборке занял больше года и все недовольства удавалось отбивать предложением указать формат отчета четко. Удачное решение пришло в голову после обнаружений RPC сервиса в трекинговой системе. За несколько дней была написана программа и придумана реструктуризация, которая позволила бы генерировать любые отчеты по существующим данным. В Jira было задействовано всё от компонент, до кастомных полей. Третий отчет был огромен. На картинке лишь пятая часть. Он вытаскивал из задачи название, описание и worklog, складывал всё вместе и сортировал по людям. Страницы в Confluence по прежнему были, но теперь состояние проектов и информацию о работе людей можно было получить прямо из отчета. Да и моё участие в написании отчета сократилось до финального ревью и выкидывания лишниго. И того, за место 2 часов отчет готовился за 10 – 15 минут.

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

На первый лист идёт информация по проектам, дальше по людям.

MindMap Ежедневных митингов (кликабельно)

]]> http://alsedi.com/blog/mindmap-dlya-ezhednevnyx-mitingov/feed/ 0 http://alsedi.com/blog/ezhednevnye-mitingi/ http://alsedi.com/blog/ezhednevnye-mitingi/#comments Wed, 04 Mar 2009 16:48:17 +0000 Alex http://alsedi.com/blog/?p=305 Еще в то время, когда нам пытались привить Scrum (по ряду причин безуспешно), тема ежедневных митингов поднималась несколько раз за декаду, но так до дела и не дошло. Мы делали митинги сначала три раза в неделю, потом раз в неделю, потом раз за итерацию, потом по необходимости, потом без отрыва задниц от места.

Я уверен, что не я один участвовал в подобном процессе, мы материли “Scrum мастера” за то, что он ничего не знает, а время митинга растягивается минимум на час. Большую часть которого две трети участников спят, ковыряют столы, стулья и носы, звонят по телефону, обсуждают вчерашний футбол, сидят с хмурыми мордами лицами. После митинга никто не помнил о чем договорились, да и вообще, договорились ли?! Но ведь что то обсуждали, но что же решили? Никто не помнил. “Scrum мастер” писал письмо руководству о прогрессе в разработке, выражая его в процентах

Мы готовы к завоеванию мира на 90%!

Эта версия лучше на 45%!

Ваши ресницы будут длиннее на 63.3% если вы попали в 34 и 5 десятых процента белокожих женщин с карими глазами и родинкой на животе!

Да брехня это всё, виртуально. А мы реальны. Мы понимали, что это чушь, что нам это чуждо и не нужно. Естественно всё умерло и с каждым релизом выяснялось, что забыли что-нибудь положить в CVS, сделали изменения в зависимых модулях и забыли известить зависимых. В тестировании тоже всё было не слишком гладко, даже налаженные горизонтально-вертикально-поперечные связи давали сбои и какие то очевидные ошибки оставались незамеченными.

Так что необходимость митингов как была так и осталась. Я решил следовать довольно простой схеме. В моей команде люди разбиты по своим проектам и…

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

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

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

Был у нас очень интересный разработчик. Он разрабатывал один компонент системы…  в течение двух лет! И когда проект был на этапе завершения оказалось, что он не совместим с платформой немного (ну это ладно). В добавок после его добавления в систему дороги назад уже не было – обратной совместимости продумано не было. С одной стороны очень плохо, разработчик чудовище. С другой мы избавились от многоярусной поддержки целого семейства старого кода.

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

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

Общее

Всегда, когда пишите тест кейс нужно помнить очень простую связку:

Объект – Действие – Результат

Объект – это всё что угодно: от расположения точек в картинке, до строк файлов, от кнопок до всей платформы целиком.
Действие – что мы делаем с объектом.
Результат – что получилось в результате действия с объектом.

В идеале результат действия один, в принципе, к этому надо стремиться. Но в реальности производимое действие может аукнуться в разных местах. И это не всегда проблемы архитектуры. Особенно часто несколько результатов появляется при тестировании пользовательских интерфейсов или многопоточных приложений.

Термины

В зависимости от продукта они разные, но это и понятно. Точное название зачастую могут дать разработчики, и если вы стопроцентно не уверены как правильно называется элемент – спросите девелопера, ткните девелопера, кусите девелопера, порвите его как грелку, но точное название должно быть.
Будьте внимательны и используйте правильно следующие термины «Panel» и «Form» (группировка и интерактивность), «Window» и «Dialog» (окно, контролируемое процессом и окно, желающее пользователя). Так же используйте правильно «left» и «right» (лево и право).
Не забывайте, так же что:

• «button» нажимают: «press» или «push»;
• «link» и большую часть элементов кликают: «click»;
• «menu», «menu+tree+list+grid item» выбирают: «select»;
• «check box» и «radio box» выделяют: «check» или «flag»;
• текст вводят: «type» или «enter»;
• информацию и объекты показывают: «show», «display», «pop-up» и иногда «appear» (когда хоба, его никто не ждал, а оно появилось);
• последовательность существительных в английском переводится задом наперёд;
• «number» – это и «integer» и «float» («real»);
• «string» – это и буквы и «number»;
• «number» может включать в себя буквы от «A» до «F» и «E», точки или запятые, как указатель дробной части;
• «text» – это набор «string», обычно со смыслом.

Подходы к написанию тест кейсов.

1. Прямое описание
2. Описание на основе определений
3. Группировка объектов по признаку
4. Зацикливание тест кейса
5. Ссылки на другие тест кейсы
6. Alias
7. Начальные и пост- условия

Частенько они переплетаются в одном тест кейсе.

Прямое описание

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

• Логотип (image)
• Поле ввода (input box, input field)
• Две кнопки (button)
• Группа из двух радио боксов (я не знаю, как правильно перевести radiobox на русский, никогда не задумывался).

Можно так же определить все ссылки, назвав их, но это будет неправильно, потому что они явно представлены в разных блоках и имеют косвенное отношение к главной функции – поиску, но об этом позже.
Имея эти элементы легко составить тест кейсы по проверке формы для поиска:
Step 1. Type “wiki test case” string into input box and press “Google Search” button
Result: New page will be opened in same window with list of sites
Step 2. Check that any word from search phrase present in any part of site representation (in title, description, URI or Sitelinks)
Result: Each site in search results list contains any or few words from search phase

Хозяйке на заметку: «Sitelinks» – это определение используется только в гугл (в контексте показа результатов поиска) и означает небольшой блок из 1 – 8 ссылок на внутренние ресурсы сайта. Причем будет или не будет показываться этот блок для сайта и какие ссылки он будет содержать решают только в Google. Впрочем, если у вас есть доступ в Webmaster Tolls, вы это уже знаете.

Нужно ли писать так много слов? Вовсе нет, можно вообще написать «Type “wiki test case” and press “Google Search” button» и «Verify that search result contains search phrase parts». Еще разок повторю, писать надо так, чтобы было понятно, что сделать, с чем сделать, и какой результат ожидать. А это значит, что использовать слова «corresponding, proper, respective» и прочие со смыслом «правильный» использовать нужно аккуратно. Например, фразы в «Expected Results»: «Respective blank appeared in the left frame» и «Check time» – ничего не значат, и писать надо, например, так «”Budviser Panel” loaded into left frame» и «Check that time format is “HH:MM:SS”, where HH – hours (24h или 12am/pm), MM – minutes, SS – seconds».
В общем и целом в прямом описании сценария нет ничего сложного или заумного, достаточно внимательно описать действия и объекты, при возможности строя новый шаг тест кейса на основе предыдущего, тогда простота описания «Expected result» получится сама собой.

Описание на основе определений

Определения позволяют сильно сэкономить, когда в тест кейсе какая-то информация повторяется несколько раз. Например, при проверке однотипных значений, которые легко описать в виде формата, например время, элементы списков, записи в логах и так далее.

У определения есть имя и значения, описывается оно в комментариях тест кейса, например:

“Long Time” format is HH:MM:SS, where HH is hours from 0 to 23, MM are minutes 0-59, SS are seconds 0-59.

После чего «Long Time» можно использовать в тексте тест кейса вместо полного описания.

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

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

Группировка объектов по признаку

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

Step 1: Check property ‘x’ of objects: a) ‘Object a’ b) Object ‘b’ c) Object ‘c’
Expected Result: property ‘x’ is in format of (has value of)

То есть в разных объектах значение, какого-то свойства одинаковое, но при этом объекты могут быть независимыми друг от друга.

Зацикливание тест кейса

Это миф. Тест кейс зацикливать нельзя. То есть писать «Repeat steps 1-3» не стоит. А собственно почему? Только потому, что это прерывает последовательность шагов? Вот фигня то. Тест кейс – это обычный сценарий действий, и если действительно нужно повторить шаг с первого по третий, то почему бы не повторить? Но вот если шаг 1-3 говорит о том, что действие надо сделать с объектом «А», а нужно повторить эти шаги для объекта «Б», тогда придется писать эти шаги снова, но уже для объекта «Б». Так же придется делать, если количество шагов больше семи (магическая цифра, найденная психологами или психиатрами).

Ссылки на другие тест кейсы

Допускаются только в комментариях. Нельзя написать пройдите тест кейс «TC-1» ни в шагах, ни в начальных или пост- условиях. Потому что тест кейс – самостоятельный сценарий и для его выполнения не требуются другие тест кейсы.

Alias

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

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

Поэтому в тест кейсах в начальных условиях можно просто написать «User must be logged in», «User must be authorized», «User logged into [] under [] role». Понятно ли что нужно сделать перед тем, как начать работу с тесткейсом? Единственное «но», алиас всё равно должен быть описан где-либо в доступном месте (FAQ к проекту вполне подойдет).

Начальные и пост- условия

Состояние тестируемой системы до и после теста. Что означает «До», в принципе, проблем не должно быть. Я надеюсь. Очень.
После – это то, как изменилась вся или часть системы, когда тест пройден успешно. Это эдакая последняя проверка на то, что даже правильно работающие кусочки, проверенные последовательно не отразились в сумме своей на системе негативно.

Хозяйке на заметку: http://blog.abakas.com/2009/02/look-even-when-you-know.html
Это только начало…

Заинтересованные в релизе группы людей

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

• Backlog – группа проектов в которой по версиям и продуктам разбиваются пожелания и требования бизнес стороны. Это не только спецификации (ТЗ), но и простые заметки, пришедшие от бизнес стороны в стиле «нужно сделать это, примерно вот так функционирует и выглядит». На основе таких «business story» можно построить спецификацию и согласовать с бизнесом.
• Development Project – Группа проектов по разработке конкретных продуктов. Основная часть задач появляется с привязкой к Backlog проекту. Это позволяет отслеживать соответствие требованиям бизнеса и начать работу QA еще до завершения разработки (что-то вроде Test Driving Development, но мягче).
• Feedback – Группа проектов для получения отзывов от клиентов и бизнес стороны по работе текущей версии и проблемам с ними связанным (но не для трекинга багов по разрабатываемой версии).
• QA – Группа проектов, привязанных к таким же проектам в Development Project. В них будет вестись трекинг задач, связанных с тестированием версии или общей работы, но не багов!
• Bugs – Группа проектов, привязанных к проектам в QA и Development Project. Здесь тестировщики создают все таски связанные с найденными ошибками и предлагают улучшения проектов.

Зачем нужно три проекта для QA? Для того, чтобы не создавать мусорной кучи. Feedback доступен не только тестировщикам (которые, по идее, знают о разрабатываемых продуктах больше остальных), но и бизнес стороне. Люди со стороны бизнеса имеют полное право не знать о том, что существует множество версий и множество компонент внутри продуктов, но должны иметь возможность сообщить о проблеме при работе. Для этого им нужно знать только что они делали и версию продукта, с которым они работали (а не всю систему), когда появилась проблема.

Причем, не важен тип решения (а пользователь может и не знать что там еще стоит за окном в которое он смотрит), разрабатываемого компанией:

• самостоятельное приложение;
• серверное приложение с доступом из стороннего (Web сервис, XML/HMTL сервер);
• клиентское приложение с доступом к стороннему (Debuggers, разнообразные сетевые клиенты);
• клиент-серверное приложение, с собственным сервером и клиентом (платформы с удаленным доступом);

Разобраться где конкретно ошибка и ошибка ли дело QA и разработчиков. Часто разработчики могут сделать это быстрее.

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

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

Принципиальная схема процесса при такой структуре проектов выглядит так:

Потоки информации между проектами

При использовании этой схемы Backlog объединяет в себе первичные требования бизнеса, общее обсуждение технической реализации или ТЗ (в зависимости от возможностей), проблемы из Feedback и Bugs, которые требуют много времени на исправление или переработки бизнес логики. Основные задачи в Backlog описывают большие куски работы, разбиение которых делается через сабтаски. Далее эта информация клонируется (или разбивается на части и клонируется) в проекты по разработке и добавляется в задачи по подготовки к тестированию в QA проектах (написание тесткейсов, переработка существующих тестов, автоматизация и так далее). После релиза в соответствующем проекте QA создаётся общая задача на тестирование, а конкретная работа выделяется в сабтаски. При нахождении ошибок при тестировании они описываются в соответствующем проекте Bugs и либо клонируются в Development Project, либо заносятся в Backlog для позднего исправления. Процесс запускается по новой… в идеале.

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

Когда я пришел в компанию, у меня был довольно большой опыт в ведении тестирования (как части QA) и разработки программ. Опыта управления процессом, в котором задействовано много людей и разные команды, практически не было. Фактически, на тот момент «картина мира» для меня выглядела так.

Мифическая организация разработки

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

В большой компании, выпускающей крупные продукты, с разделенными географически офисами (сюда можно включить оффшорные компании и местные (domestic) филиалы компании), эта схема разбивается вдребезги. Всё оказалось намного сложнее. Бизнес сторона не всегда может что-либо спланировать или четко сказать, что нужно сделать. Изолированность оффисов приводит к недостатку коммуникаций и не пониманию реальной ситуации и потребностей. А о технической документации вообще задумываются редко, особенно когда речь заходит о взаимодействии связанных, но разных частей системы (лучший пример клиент-серверная архитектура). А помимо пресловутого треугольника существует еще множество разнообразных служб и подразделений: Application Management, Системные администраторы, Backoffice, поддержка клиентов и пользователей и бог знает кто еще. И все, даже новенькая уборщица, имеют свой собственный взгляд на то, каким должен быть финальный продукт. Шутки шутками, но в реалиях действительно существует множество людей, прямо или косвенно использующих финальный продукт, имеющих разные взгляды на разработку и качество продукта. В результате всего этого, при отсутствии продуманного менеджмента, через некоторое время, возникает хаос. Часто, в этот момент владельцы или топ-менеджеры задумываются о тестировании и Quality Assurance.

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

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

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

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