BYTEX BLOG
Лучшие инструменты для организации тестирования. Часть первая
Идея реализации проекта всегда начинается с планирования. Руководителю производственного отделения необходимо подобрать подходящую команду, распределить обязанности и назначить задачи внутри нее, а также подобрать инструментарий, которым она будет пользоваться в течение всего цикла разработки продукта.
Выбор приспособлений всегда обусловлен сравнением характеристик, цен и отзывов о продукте. В своей статье на сайте geteasyqa.com Яна Густи рассматривает 10 самых известных служб, предназначенных для тестирования и разработки, в соответствии со следующими критериями:
В результате проведенного исследования, у портала получился следующий список инструментов:
TestRail
TestRail от Gurick Software GmbH Company — самая успешная программа для тестирования из всех, что разработала команда за время своего существования с 2004 года. 
Основное преимущество здесь не в качестве каждого упомянутого нами выше критерия, а в том, что почти весь этот функционал тут более или менее реализован. В работе с TestRail мы сфокусировались на создании тест-кейсов.
У инструмента дружелюбный интерфейс и интуитивно понятное расположение кнопок.
Помимо создания тест-кейсов здесь можно:
Попробовать TestRail можно, перейдя по ссылке.
TestLink
Единственный из подобных проект с открытым программным обеспечением, чем и заслужил место в нашем списке. У него простой интерфейс и «технический» дизайн без изысков.
Несмотря на сложности при установке, TestLink пользуются многие команды разработчиков и QA специалисты. Жизненный цикл начинается с создания проекта, добавления участников и назначения им ролей. Примерно так же, как и в других инструментах. 
Еще пара особенностей:
TestLink не имеет своего баг-трекера, но легко интегрируется в другие системы. По ссылке можно скачать инструментарий и инструкцию по установке.
Jira + Zephyr
Этих двоих можно рассматривать и в отдельности, конечно. Например, у JIRA есть пара решений для тест-кейсов, но в связке с Zephyr нам открывается лучший баг-трекер из возможных.
Многие IT-разработчики знают JIRA в основном как баг-трекер, нацеленный на контроль за разработкой с задачами, багами и подобными примечаниями. Zephyr — один из многих плагинов для JIRA, расширяющий его возможности.
Если использовать эту связку, можно получить сервис с полным набором функций, указанных в начале статьи:
Преимущество JIRA+Zephyr — низкая базовая цена и широкий спектр ценников, в соответствии с необходимым функционалом. Скачать можно по ссылке.
PractiTest
Следующий наш участник — облачная служба. Пользователь волен:
PractiTest может быть интегрирован в JIRA, Privotal tracker, Redmine и им подобные. Если проводятся автоматические тесты с помощью Selenium или Jenkins, с ними тоже можно работать через API.
Вот здесь ее можно попробовать бесплатно.
qTest
qTest разработан QASymphony Company. Его основная цель — помощь не только тестировщикам, но всей команде разработки. Многие пользователи qTest выделяют простой и дружелюбный интерфейс.
Среди основных функций наиболее заметны следующие:
В следующий раз мы расскажем о второй половине этого интересного списка программ для менеджмента процесса тестирования. И, возможно, сделаем определенные выводы.
Test & Test Case Management in Jira [реализация]
Части:
1. Условности
2. Реализация – вы тут
3. Автоматизации работы
4. Создание отчетов
5. Связь с другими проектами
Это вторая часть серии статей про создание системы управления тестами и тест кейсами в Jira, без использования дополнительных плагинов и доработок.
В статье много картинок и имеет смысл её сначала прочесть целиком (а так же предыдущую часть, про условности), а потом повторить шаг за шагом.
Создание проекта
Проект добавляется через Administration > Projects > Add Project
Ключ проекта (Key) выбирать нужно обдуманно, потому что потом только его нельзя будет изменить. После создания проекта появится вот такая страница.
Схема ниже показывает что и в какой последовательности будет изменено в настройках проекта, её полезно держать перед глазами.
Чтобы не запутаться потом в схемах нужно сначала определить правила именования схем и полей. Например можно делать так:
| Test Cases | Название проекта |
| Test Cases Field Configuration | Конфигурация полей |
| Test Cases Field Configuration Sheme | Схема конфигурации полей |
Во время написания статьи я использовал тот же принцип, только добавил название группы проектов перед его именем, получилось TC Demo.
Новые типы задач
Новые типы задач можно добавить через Administration > Issue Settings (слева колонка) > Issue Types > Add New Issue Type (в Jira 3 – внизу страницы). Нужно добавить два новых типа:
Ради развлечения стоит поменять иконки (например взять из блока Адама Гушера, там обалденные жучки).
По умолчанию созданные типы задач сразу попадают в основную схему (Default Issue Type Scheme). Оттуда их можно убрать, но это не обязательно.
Там же, но на вкладке Issue Types Scheme нужно создать новую схему и ассоциировать с ней созданные типы задач. Не помешает так же задать TestCase как основной тип задач для этой схемы. Просто для экономии времени при заполнении в будущем. 
После создания схема не будет привязана ни к одному из проектов. Установить эту схему для проекта можно прямо со страницы со списком схем, нажав Associate (если надо сразу несколько проектов добавить — самое то), либо через страницу администрирования проекта.
Дополнительные поля для тест кейсов
Дополнительные поля добавляются через Administration > Issue Fields (колонка слева) > Custom Fields > Add Custom Field
Полей потребуется всего четыре. Первые три, позволят хранить основные данные по тест кейсу.
| Pre-conditions | Free Text Field (unlimited text) | Состояние системы до теста. В том числе настройки и специальные значения параметров. |
| Steps | Free Text Field (unlimited text) | Шаги теста |
| Post-conditions | Free Text Field (unlimited text) | Состояние системы после теста (если необходимо сравнивать). |
По умолчанию значение всех полей такое (это разметка wiki):
|| Step || Action || Expected Result ||
| | | |
А отображаться будет вот так:
Последнее, четвёртое поле, предназначено только для выбора из существующих опций и используется для сортировки автоматических и ручных тестов.
| Test Case State | Multi Select |
Этот параметр может иметь сразу несколько значений. В сам список достаточно добавить Manual (выбрано по умолчанию) и Automated. В моём случае их комбинация позволяет определить состояние автоматизации тест кейса.
| Manual | Для ручного тестирования |
| Manual, Automated | Показывает, что тест кейс либо отправлен на автоматизацию, либо автоматизирован, но так же его можно перепроверить руками (например, если тест часто падает или его результатам не доверяют, но и изменить или отключить его нельзя). |
| Automated | Автоматический тест |
В зависимости от условий эти поля можно привязать либо к определённому типу задач, либо к проекту, либо к тому и другому — для порядка.
Создание конфигурации полей
Хозяйке на заметку: В Jira, кроме стандартных полей, можно создать собственные поля самого разного типа от простых текстовых до календаря. Для каждого своего поля можно специально указать контекст использования – в каких проектах или задачах это поле может быть использовано. Чем проще эти настройки, тем лучше и тем меньше недоумения возникает, когда при клонировании проекта оказывается, что части полей нет, хотя настройки схем абсолютно одинаковые.
Если поле не предназначено для повсеместного использования, то лучше всего его привязать к типу задач, для которых оно предназначено. Задаётся привязка там же, где создаются дополнительные поля (Custom Fields). Выглядеть это будет так:
Правила отображения и обязательности полей
Эти правила задаются через Administration > Issue Fields (колонка слева) > Field Configuration. В действительности очень полезная вещь, которая позволяет избежать бардака. Там же задаётся видимость некоторых полей. Полезность этой настройки становится явной только когда срочно нужно отключить доступ к полю сразу во многих проектах, с одной схемой полей. В общем то больше административная вещь и её лучше не трогать при настройке проекта, если вы не уверены нужно ли это.
Так же, тут настраивается и отображение текстовых полей. Их можно показывать как обычный текст (Default Text Renderer), а можно как текст с wiki разметкой (Wiki Style Renderer). Wiki Style Renderer потребуется как раз для полей Pre & Post – conditions и Steps. Переключается режим отображения через ссылку “Renderers” для каждого поля.
Напрямую эти правила не используются, а включаются в состав схем полей (Field Configuration Scheme). Сразу при создании они не ассоциируются ни с одной схемой, ассоциации выставляются уже в схеме в которую включена конфиграция. Настроить схему можно через Administration > Issue Fields (колонка слева) > Field Configuration Scheme.
Field Configuration Scheme
Позволяет установить разные наборы полей для разных типов задач. Для этой реализации TCMS нет необходимости настраивать разные схемы полей на уровне конфигураций, это можно сделать на уровне представлений (Screen):
Все типы задач в проекте не связанные явно с конфигурациями полей в схеме, подключенной к проекту, будут ассоциированы со схемой по умолчанию (Default Field Configuration). Это важно помнить, потому что, ошибки с отображением полей в этой части особенно трудно найти потом.
Создание разных видов отображения полей
Screen
Определяет какие поля, в какой последовательности и на какой вкладке (Tab) будут показаны на экране, при вызове этого отображения. Изменения подхватываются на лету. У меня сделано четыре разных представления, по два на каждый тип задачи, для изменения и просмотра записей.
Создание новой задачи типа TestCase разбито на два экрана (Tab), на первом основная информация по самой задаче, а на втором только то, что имеет отношение к тест кейсу.
Для подзадач набор полей меньше, потому что в этой задаче идёт лишь учёт работы по тестированию и нет необходимости дублировать всю информацию из тест кейса. 
Отображение полей при просмотре тест кейса и теста схожи:
TestCase (Demo TestCase Screen):  | Test (sub-task, Demo Test Screen):  |
Screen Scheme
Схема позволяет связать созданные отображения (Screens) с действиями — создания, редактирования и просмотра задач. При создании схемы нужно выбрать отображение, которое будет показываться для всех случаев не указанных явно. Сами схемы не зависят друг от друга и их можно создавать в любом порядке, порядок действий будет одинаковый.
При создании схемы в качество основного отображения лучше выбрать то, которое отвечает за создание задачи и после отдельно указать отображение для просмотра. Для тест кейса (Demo TC Screen Scheme, для теста Demo T Screen Scheme точно так же объедияет отображение для теста – Demo Test Screen [create/edit] и Demo Test Screen [view]) эта связка будет выглядеть так: 
Теперь эти схемы нужно связать с типами задач. Делается это с помощью Issue Type Screen Scheme. (Administration > Issue Fields (колонка слева) > Issue Type Screen Schemes).
И тут при создании новой схемы в качестве отображения по умолчанию выбрать просто Default Screen Scheme. Это обеспечит спокойное добавление новых типов задач и возможность быстро заметить направильные связи по схемам для них. 
Подключаем все схемы в проект
На странице администрирования проекта через ссылки Select можно выбирать нужные схемы, получится примерно так: 
Проверяем в работе
Если всё правильно то:
В качестве заключения
При создании нужно очень внимательно следить за тем, какие значения остаются дефолтными, потому что это может сильно отразиться на результате и найти потом причины ошибок будет очень не просто.
Test & Test Case Management in Jira [условности]
Части:
1. Условности – вы тут
2. Реализация
3. Автоматизации работы
4. Создание отчетов
5. Связь с другими проектами
Собираясь продолжить рассказ, начатый больше года назад, о тех проблемах, 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).
7 thoughts to “Test & Test Case Management in Jira [условности]”
Странно, что у вас тест-кейсы включают в себя тесты. Вообще налицо как раз обратная иерархия. Ну да ладно. Вопрос, как быть со статусами тестов, когда они заваливаются. Необходим статус failed или что-то типа того. Тогда этот статус не будет увязываться с задачами, требованиями, фичами и др. Как быть в таком случае? Сам по себе тест менеджмент – это не обратная сторона багтрекинга, и даже не аналогия управления требованиями, а как раз участок того самого проблемного места, из-за которого многие системы управления проектами и страдают. Этакий “любовный треугольник” – требование – тест – баг. Так вот я пока лишь путем ошибок, проб и опыта смог достичь оптимального применения жиры через выделение отдельного компонента “Тестирование”. В нем создаю отдельные задачи (тесты или тестпланы – называйте как хотите) и подзадачи (тест-кейсы). Специально даже пришлось создать новые виды issue. Тесты я связываю с требованиями и/или задачами и при заваливании теста создаю баги в рамках того требования которое тестировалось. НО. Не получилось пока ни свести, ни разграничить статусы тестов и задач.
Мне кажется вы не совсем поняли то, о чем я написал, плюс у нас не состыковка в определениях. Тест кейс для меня, вкратце, — это набор шагов с ожидаемым результатом. Тест — это ряд действий, совершаемых по сценарию. Поэтому тест в моём варианте является дочерним к тест кейсу.
Статусы в Jira контекстно зависимые и их можно настроить только для определённых проектов. Впрочем, для обозначение упавших тестов я использую поле Resolution, которое действительно видно во всех проектах. Хотя это не стало камнем преткновения для кого-либо.
По поводу вашего варианта хочется понять точнее, каким образом происходит работа. После этого можно будет продолжить обсуждение. Сейчас есть большой риск из-за различий в понятиях окончательно друг друга не понять. Так же могло ввести заблуждение отрывочный характер записей, я их сегодня подправлю.
По тому что вы написали я понял лишь поверхностно как у вас всё устроено. Не понятно как много задач создаётся, что включает в себя то, что вы называете тест-кейсом. Каким образом проводится регрессионное тестирование? Как обеспечивается управление тестовыми сценариями по времени. Как тестовые сценарии передаются на автоматизацию? Как по одному и тому же сценарию получить отчёт о его поведении по нескольким версиям? Как заранее, определить сколько времени потребуется на тестирование?
С вашим процессом разобрался, вполне нормальный вариант. Различий много, фактически это другой подход к организации тестирования.
У нас есть несколько принципиальных расхождений. Первое в сопоставлении тестов и тест кейсов. У меня «тест» — это действие по одному тест кейсу. Сделано это для того, чтобы было легче отслеживать «жизнь» найденной ошибки в процессе разработки:
– Упавший тест порождает задачу в багтрекинговом проекте;
– Баг в трекинговой системе порождает задачу в девелопменте;
В перспективе на основе этих связей можно отслеживать наиболее рискованные участки кода и бизнес функций и просчитывать риски еще до релиза.
Но использовать связь один к одному или один ко многим зависит только от того процесса, который нужно получить. Мне требовалось четкое соответствие тесткейсов, тестов, ошибок и задач в девелопменте. Если этого не требуется, то соотношение количества тест кейсов и тестов к ним значение имеет только в плане удобства.
Второе расхождение в организации тестирования по тест кейсам и организации коллекцией тест кейсов (в вашей терминологии — тест пакетов). Помимо функциональных тестов в TCMS хранятся сценарии для стресс тестирования и инсталляционного тестирования, так же ведутся тест кейсы для автоматизации (ничем особым не отличаются, кроме специфичного описания). Разделение тест кейсов на пакеты, повторю то, что написано выше, сделано на основе мета данных и приоритетов и компонент (для идентификации конечного продукта). Причем первичным признаком для выбора при тестировании является приоритет. Метки разделяют тест кейсы на коллекции по функциональности (как у вас), но могут включать в себя сценарии любого приоритета. В рутинной работе используется только разделение по приоритету, метки чаще используются для удобства тестера, проводящего тестирования. Но по задумке комбинацией значений этих трёх полей позволяет просто и гибко составлять тест планы по нужным признакам, оценить время на тестирование и какие команды будут вовлечены в тестирование. Тут, как я понимаю уже глобальное отличие процессов — у вас отдел тестирования не выделен.
Третье отличие в жизненном цикле тест кейса. Насколько я понял из описания, вы после тестировании закрываете тест кейсы. У меня пока тест кейс остаётся актуальным — он открыт. Закрытие тест кейса означает, что его использовать больше нельзя. Но это по большому счёту ерунда, просто разный принцип и небольшие преимущества при поиске.
Вот в общем то и всё по отличиям, надеюсь это поможет.
Теперь я так же могу ответить про вопрос про увязывание статусов. Я его не понял сначала. У меня нет такой проблемы со статусами, потому что используется несколько проектов – для ведения тест кейсов, для ведения ошибок, для ведения разработки. Во всех проектах, упрощая, свои статусы. Связи между проектами сделаны через ссылки (Link), они же позволяют оценивать статус задачи. Для расширенного видения есть отчеты Link Hierarchy Report For Versions и Link Hierarchy Report For Issues.
По поводу того, как избежать неправильного использования элементов тестирования в Jira, если я правильно понял про артефакты тестов. У меня как раз перенос в отдельный проект и помог предотвратить не правильное использование специальных фишек для тестирования в разработке. Более того у меня для тест кейсов несколько проектов.
Впрочем разработчики люди адекватные и если начинались какие-либо косяки, то личной беседой и объяснениями всё улаживалось. Поскольку модель не противоречила и не усложняла процесс для разработчика, то все охотно шли на встречу.
С технической точки зрения, разграничения внутри одного проекта можно сделать несколькими способами:
– изменением Workflow и настройкой шагов таким образом, чтобы у разработчика не было возможности в ручную управлять настройками, относящимися к тестам. Сложный, но самый надежный вариант, который при правильной реализации, к тому же, упростит работу с Jira для всех (делается через настройку Workflow Actions, Screens, Conditions и Validators в настройках шагов)
– настройкой в проекте ролей (Project Roles + Permission Scheme) и Security Schemes (но я бы предпочел их не касаться даже трёх метровой палкой).