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

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

В очередной раз мы, в ALSEDI, столкнулись с вопросами интеллектуального права. В очередной раз убедились, что разумные люди решают такие вопросы достаточно спокойно и без фанатизма.

Прошлые заметки: 1

В первый номер вошли не только статьи, которые были написаны специально для этого номера, но и наиболее заметные статьи из блогосферы, твиттера. Основной темы номера нет, но так же и нет чисто технических статей и мануалов а-ля “делай как я”. В основном этюды на тему места тестера в жизни и работе. Иллюстрации для журнала придумала Рози Шери (Rosie Sherry), о которой я уже упоминал.

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

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

Когда: 17 февраля, среда, 20:00-…
Где: конференц-зал пивного ресторана «Остров» (пр. Каменноостровский, 24, 5 мин от ст. м. «Петроградская»).
Участники: все активные тестировщики Санкт-Петербурга.

Из текущих планов:

• Предполагается приход Александра Орлова, основатель проекта Happy PM и один из учередителей гильдии менеджеров программных продуктов (по которой я не совсем правильно и довольно резко проехался в прошлом году);
• Алексей Лянгузов готовит небольшой неформальный доклад на тему «Неудобство использования ПО. В чем вина тестировщиков?».

Если есть желание придти, то лучше всего об этом написать тут: http://community.software-testing.ru/blog/events/182.html .

Швабера вообще стоит читать, если есть интерес к применению Scrum, потому что, во-первых, он один из основателей Agile Alliance, а во-вторых один из двух авторов теоретики по процессу Scrum. То есть, он знает о чём говорит и то, что он говорит это не секонд хенд, а сведения из первоисточника.

Возвращаясь к книге. Она оказалась и интересной и полезной, но первичных ожиданий не оправдала. По названию я ожидал, что основное содержание будет составлено из описания практик того, как нужно управлять проектами по Scrum. Оказалось же, что Кен Швабер написал не о теоретических подходах, а чисто о случаях практического применения(упрощая – дал кейсы на разные ситуации). Но важнее оказалось то, что описывал он эти случаи с подходом людей на разных ролях, иногда в одной и той же ситуации, а иногда на протяжении длительного времени. Вот так и получилось, что ожидания не оправдались, но при этом материал оказался крайне полезным. Хотя больше она понравится менеджерам, чем рядовым программистам, тестировщикам и прочим участникам разработки.

Книга разбита на девять слабо связанных частей, а каждой рассматривается по несколько случаев, которые, по идее, должны дать общее представление об основных проблемах, методах их решения и о том, как вообще не допускать описанных ситуаций. Сами случаи показаны так, как видел их сам Кен и обычно разбиты на три части: исходная ситуация до введения Scrum, либо в самом начале его применения; описание появившейся проблемы; описание вынесенных уроков из ситуации и необходимые решения для устранения проблем (Lessons Learned). Очень хорошо и подробно описана работа в условиях одной команды, причем как в случае, когда начинался новый проект, так и при переводе существующего проекта на Scrum. Применение Scrum в случае, когда задействовано много команда (Scaling Scrum) описано явно недостаточно. При этом Кем в явном виде указывает на то, что расширение Scrum на несколько групп вполне осуществимо, но при это придётся сделать финт ушами.

В конце книги Кен поместил список правил, которым стоит следовать при работе в условиях Scrum. Если же не следовать этому компактному списку правил, то на правильно работающий процесс рассчитывать не стоит.

Здравствуйте, %username%,

Средства на твоем счете будут деактивированы через 30 дня (дней)

Согласно нашим данным, ты уже довольно давно не использовал средства на своем счете в Skype.

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

Реквизиты вашего счета:

Логин Skype: ***

Баланс: ***

Дата окончания срока действия средств на счете: (+30 дней с момента отправки письма)

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

Любопытная тенденция.

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

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

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

Что я понял за прошедшее десятилетие:

• Нанимают специалистов, а не учеников.
  • Поэтому учится придётся самому и, часто отдельно от работы, потому что не каждый начальник готов к тому, чтобы время на самообразование было включено в зарплату;
  • Специализироваться во многих вещах хорошо в работе, но не в резюме;
• Деньги лучше использовать, чем складывать (спасибо Максу Крайнову);
  • Хотя, резервный фонд может стать правильной идеей;
  • Нужно выделять деньги на образование, медицину и отдых.
  • Траты надо планировать, а не учитывать;
  • Нельзя сделать деньги из ничего. Как вариант, чтобы получить прибыль с бизнеса, сначала нужно потратиться и много работать;
• «Simpsons Already Did It» © South Park. Большинство идей уже была высказана и реализована ранее, но даже для очень старой и растиражированной идеи можно найти такую реализацию, которая окажется востребованной.

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

Майл Келли в блоге Quick Testing Tips привёл правильные идеи для стресс тестирования. Как всегда, вроде бы всё на поверхности, но стоит собрать вместе разрозненные части и открывается что-то новое.

А предыдущие выпуски можно почитать тут: 4, 3, 2, 1.

Во многом, для того чтобы работать с системой, о которой я рассказал в первых двух частях, достаточно возможностей самой Jira. Чтобы отслеживать текущее состояние по проектам, вполне подходит совмещение фильтров (по проекту и статусу Open) и дашбордов.  Но на мой взгляд это не слишком интересно отслеживать работу конкретно по тест кейсам. Интереснее оперативно получать информацию о тех кейсах, которые показали ошибки (Resolution: Failed). Для того, чтобы работа была приятнее, нужно настроить какие поля будут отображаться для этого фильтра. Делается это прямо из навигатора по задачам, пункт справа вверху Set Column Order for filter.

Я использую следующие поля: Priority,Key, Summary, Status, Assignee, Fix Version,Links, Created, Updated. А когда смотрю на табличку анализирую записи вот так. Смотрю, есть ли внешние ссылки (Links). Если есть, то просматриваю сначала описание тест кейса для теста (там так же могут быть внешние ссылки) и после смотрю внешние ссылки для этого теста. Если ссылок нет и  приоритет выше, чем Major смотрю дату создания и последнего обновления и комментарии по тест кейсу и тесту. Если ничего нет запрашиваю объяснения у человека, который выполнил тестирование (Assignee) и его лида (тут уже достаточно памяти). Такой подход не позволяет решить проблему обмена информацией и своевременной актуализации тест кейсов. Например существовавшая функциональность сильно изменилась в новой версии, но информация об этом будет в несена  в тест кейсы только после того, как изменения будут проанализированы тестерами. К этому времени тест кейсы могут быть уже пройдены. Вместе с тем это достаточно надежный способ для того, чтобы поддерживать актуальную информацию о регрессионных проблемах при тестировании.

Итак, что легко можно автоматизировать при работе с TCMS средствами Jira, например:

• Получение актуального статуса по объему оставшейся и выполненной работы (фильтр, либо отчет. Project Pivot Report, например);
• Получение статуса по загрузке участников группы в тестирование по тест кейсам (фильтр + портлет Pie Chart);
• Составление календаря с указанием предполагаемых сроков завершения тестирования по каждому тесту [правда, обычно по всем разом] (фильтр + портлет Issue Calendar);
• Получение актуального статуса по упавшим тестам (фильтр);
• Получение отчётов по проделанной работе  (отчеты по проекту);
• Получение списка изменений в тест кейсах (фильтр по Update After/Before);
• Получение списка автоматических тестов (фильтр);
• Получение отчета по загрузке работой по людям и по версиям (снова отчеты по проекту);

В общем то, всё что касается отчётов и вытягивания информации по задачам можно сделать стандартными средствами. Но вот управлять задачами на тестирование уже так легко не получится. Стандартными средствами нельзя создать множество подзадач или задач и поставить правильные линки. Даже через массовые операции (Bulk Operations) этого сделать нельзя.  Я когда, при проектировании столкнулся с этой проблемой сильно задумался. Три дня, пока создавал сабтаски руками, думал о том, что вся предыдущая работа вот-вот пойдёт насмарку, потому что работа с системой требовала неадекватного количества операций, длительных по времени, что делало систему нерабочей в тех объемах в которых хотелось. А хотелось не только управлять тест кейсами, но контролировать тестирование по ним.

Решений, в итоге, было несколько (в порядке появления):

1. Забыть про создание отдельных задач (тестов) к тест кейсам и обойтись одной общей (Test by Test Cases, а в описании давать список ссылок). Проблему этот подход не решал.

2. Доработать Jira, чтобы можно было создавать сабтаски массово. После реализации оказалось, что это не эффективно и отнимало слишком много ресурсов на серверной стороне.

3. Разработать плагин для Jira. Идея сразу умерла, уже не помню почему.

4. Использовать XML-RPC. Вот это уже прижилось, хотя всё-равно потребовались небольшие доработки в Jira. Оказалось, что в RPC так же нет возможности создавать подзадачи, хотя просто задачи создавать можно. А в Jira отличие задачи от подзадачи только в её типе (Issue Types) и том, что у подзадачи ссылка на родительскую задачу не пустое значение. Не смотря на просьбы участников, эта возможность еще не добавлена в официальный плагин XML-RPC. Большой привет Atlassian. Но никто не мешает внести изменения самостоятельно. К сожалению плагин, который опубликован в таске JRA-6896 не работает с версиями старше 3.10, придётся править исходники, которые поставляются вместе с используемой версией Jira (не самая сложная работа).

В результате я написал несколько простых программ, которые позволили сделать рутинную работу намного проще и быстрее.

Самой первой появилась программа для создания подзадач. Напомню, что в описанной структуре тест кейс представлен как задача верхнего уровня, а тест (как действие) представлен подзадачей и создается для каждой версии попавшей в тестирование (в идеале).

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

В итоге подзадача состоит из:

- Summary -  Тема (Summary) тест кейса с префиксом Test ( например, TEST – Check login form)

- Reporter – имя залогинившегося пользователя

- Assignee – Никого (Unassigned).

- Fix For, Affected Version, Component, Original Estimate, тип теста (автоматический/ручной) и Labels. Копируются из тест кейса.

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

Ответственный (Assignee) за тестирование проставляется позже через Bulk Operations, либо точечно.

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

Тут уже использовалось соединение через XML-RPC с Confluence и с Jira. Вообще, я только когда разобрался в этих возможностях понял, что оба продукта разрабатывают разные группы, со своим взглядом (и похоже они иногда вынашивают планы взаимного тотального уничтожения).

В плагине для Confluence не пришлось что-либо менять. Эта программа вытаскивает версии из нескольких проектов в Jira, подставляет нужные темплейты (с тест планом, тест кейсами, найденными багами)  и каким то волшебным способом создаёт страницу в Confluence.

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