Во многом, для того чтобы работать с системой, о которой я рассказал в первых двух частях, достаточно возможностей самой 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, при этом, для представления результатов лучше использовать стандартные средства и не изобретать велосипед.

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

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

Условий минимум, всё строится на жизненном цикле тест кейса в системе и связи его с тестами и автоматизацией.

Жизненный цикл

Он такой

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

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

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

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

Связь с Jira

Тест кейсы и тесты по ним в Jira представлены в виде задачи TestCase и под-задачи Test. В TestCase находится всё описание, включая начальные (Pre) и конечные (Post) условия, там же выставляется приоритет и статус, которые отражают текущее положение тест кейса в жизненном цикле:

«Живой» тест кейс (Status – Open):
Assignee = Reporter – тест кейс на стадии разработки и еще не готов для использования
Assignee = лидер группы (или другой человек отвечающий за ревью) — тест кейс проверяется
Assignee = Unassigned – тест кейс проверен и может быть использован для тестирования.
Assignee = разработчик – тест кейс отправлен на автоматизацию
Assignee = Unassigned, Test Сase State = Automated – тест кейс отправлен на автоматизацию

Устаревший тест кейс:
Status = Closed, Assignee = Unassigned или человек, которые закрыл тест кейс (но это не важно, всё есть в истории изменений).

Для разбиения тест кейсов на группы используются совместно метки (Labels) и приоритет (Priority).

В приоритете используется только три уровня — Critical, Major, Normal, которые определяют частоту использования тест кейса — для каждой версии (билда), для каждого значимого изменения (например — связанных компонент) и если есть время, соответственно. Метки используются для группировки по любому интересующему признаку — бизнес значимость, функциональность, прощупываемая с разных сторон. Причем такие группы кросс-компонентные (компонент может означать – целый проект, часть бизнес логики, группу проектов, что угодно, лишь бы было полезно в работе).

Комбинацией фильтров и плагинов (для Jira или Confluence) набор задач приводится в приемлемый вид и может быть выведен на персональных дашбордах или на общих страницах в Confluence (например через плагин jiraissues).

Хочу отметить, что технические возможности пристально разглядывали мои сотрудники (Лиля и Ира), а я лишь ковылял вслед за ними, всего лишь их подбадривая и горячо надеясь в полезность кубика.

Но при близком рассмотрении CubicTest разочаровал (хотя концепция неплоха, но подвела текущая реализация). Он плохо подходит для создания сложных тестов. Есть проблемы с рекордером — запись возможна только в Firefox и Opera, не все элементы определяются корректно. Проблемы с использованием переменных в тестах, например зациклить тест для прохода сценария по одному тест кейсу, но с разными параметрами в текущей версии (1.9.6) не получится. Такую поддержку обещают в будущем. Единственная возможность перевести тесты в Selenium — это экспорт тестов в скрипты, совместимые с Selenium, но даже после этого для запуска теста в Selenium RC его нужно шлифовать руками. Существует теоретическая возможность интеграции CubicTest в Selenium Grid, но у нас этого не получилось.

Но есть и плюсы, которые делают CubicTest отличным инструментом для обучения неопытных тестировщиков и составления простых функциональных тестов. А также для общения с заказчиком, для получения User Story.

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

Плюс 2. Возможность расширять тестовые наборы с помощью Java (но не залезать внутрь существующего теста).

Плюс 3. Создание прототипа HTML по тесту (на лицо попытка адаптации к TDD или User Story). Сама идея мне очень даже понравилась, остаётся только проверить её на профпригодность.

Код генерируется чистенький (судя по всему из одного темплейта, просто подставляются новые элементы), с использованием li, div, css и js. Есть несогласованность языковых настроек, по умолчанию HTML создаётся с кодировкой ISO-8859-1, хотя из Eclipse, в моей инсталляции, приходит Cp1251 (эта же кодировка используется при записи тестов).

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

Плюс 4. Обилие поддерживаемых браузеров и режимов их работы (всего семь) и возможность указывать профайлы для Firefox и Opera.

*firefox -> Firefox (chrome mode)
*opera -> Opera
*googlechrome -> Google Chrome
*iexplore -> Internet Explorer (HTA mode)
*safari -> Safari
*pifirefox -> Firefox - Proxy injection mode
*piiexplore -> Internet Explorer - Proxy injection mode

Proxy Injection Mode достался от Selenium. HTA (HTML Application?) у меня просто отказался работать, IE8 упорно валился с ошибками в JS.

Плюс 5. При записи теста в Recorder Plugin прямо на странице указывать какие элементы нужно проверять, условия автоматически добавятся в тест.

Плюс 6. Интеграция с Maven.

Об использовании CubicTest, еще можно поспорить, но познакомить с ним тестировщиков web приложений точно стоит, вполне возможно, что найдутся такие рутинные операции, которые CubicTest позволит очень быстро автоматизировать и вынести за пределы ручной переборки.

Общее

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

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

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

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

Термины

В зависимости от продукта они разные, но это и понятно. Точное название зачастую могут дать разработчики, и если вы стопроцентно не уверены как правильно называется элемент – спросите девелопера, ткните девелопера, кусите девелопера, порвите его как грелку, но точное название должно быть.
Будьте внимательны и используйте правильно следующие термины «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
Это только начало…