В современной IT индустрии многие до сих пор удивляются: «зачем вообще нужен отдельный тестовый отдел?».
Что такое петербургская осень? Дожди, Розенбаум, меланхолия… Разве всё?! Нет, ещё это новый учебный год, который во многих регионах нашей страны начался именно с Дневник.ру. За лето мы успели достичь определенных успехов: число пользователей проекта перевалило отметку в 7 000 000, мы стали единственной российской компанией, вошедшей в список «World Economic Forum Technology Pioneers 2014», а Республика Северная Осетия-Алания полностью перешла на электронные журналы с Дневник.ру. На этом лирическое вступление окончим и перейдем к сути данного поста.
В современной IT индустрии многие до сих пор удивляются: «зачем вообще нужен отдельный тестовый отдел?». Как один из участников тестовой команды нашего проекта, ответственно заявляю: это ошибочное мнение. Организовать отдел QA – дело нелегкое, но оно того стоит.
В этом случае для себя надо четко понимать:
— что считать критерием качества?
— какие метрики использовать?
— с помощью какого инструментария проводить тестирование?
— как строить взаимодействие с разработчиками/аналитиками и т.д.
По большому счету изобретать велосипед не стоит – данные практики описаны на миллионах интернет-страниц, успешно применяются во многих корпорациях, чей опыт можно перенять. Однако не нужно забывать простую истину – везде есть своя специфика. Например, в Дневник.ру это сильно-связанные между собой компоненты и CI (Continuous Integration), а попросту – высокий уровень интеграции связанных областей. Как лучше тестировать в этом случае?
Начнем с простого: любая информация никогда не сможет на 100% автоматически «всплывать» в вашей (бесспорно, очень умной) голове. QA-шникам в первую очередь необходимо запоминать и в дальнейшем прогонять тестовые сценарии, которые проверяются от релиза к релизу – «а не сломалось ли что?». Как мы все знаем – регрессионное тестирование. Но сейчас не об этом, про виды – welcome to protesting.ru (хороший, кстати говоря, ресурс).
Так вот, для написания и хранения тест-кейсов («Тест-кейс — артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части») можно использовать массу инструментов: Excel, блокнот, google-docs, листы бумаги, в конце концов. Но разве это эффективно и удобно? Для одного человека – может быть. Для команды, где статус проекта «надо было знать уже вчера» – определенно нет.
Давно уж существует множество тяжеловесных Test Management программ, позволяющих полноценно менеджерить тестовый процесс: работа с тест-планами, тест-циклами, реквайментсами, тест-кейсами и т.д. Работал я с разными тулами – платными, бесплатными, саморучно-написанными… За многие годы уверился, что в данном вопросе лучше не скупиться на деньги: либо приобрести качественный инструмент, либо нанять команду и написать «идеальный для компании тул, с теми требованиями, которые вам нужны».
Итак, во-первых: стало ясно, что существующие чек-листы не справляются с успешностью тестирования. Их недостаточно, в них мало информации, они не прозрачны, по ним сложно представить результаты, их трудно поддерживать, не хватает времени для написания новых. Во-вторых: в сложившейся ситуации нам нужен был достаточно лёгкий для понимания инструмент, который позволит эффективно управлять тест-менеджментским сценарием: «требования -> тест-кейсы -> ревью -> тестовый сьют -> тестовый цикл -> результаты».
— удобный пользовательский интерфейс
— удобство установки, внедрения и поддержки
— удобное написание и хранение тестовых сценариев
— связь с JIRA
— эффективное управление следующим сценарием: «требования -> тест-кейсы -> ревью -> тестовый сьют -> тестовый цикл -> результаты»
— удобный выбор тест-кейсов из разных областей для запуска в одном test run’е
— легкость получения прозрачных отчетов по запуску тестовых-сьютов
— возможность в будущем связать тул с авто-тестированием и запуском написанных авто-тестов
— Microsoft Test Lab (how to на русском)
— Zephyr
— Test Link
— Testia Tarantula
— Test Rail
PS: предупреждая вопросы – HP Quality Center мы не рассматривали, потому что 1) неоправданно дорого 2) не очень он и «приветливый», особенно к тем, кто никогда не работал с тест-тулами, а писать свой – ресурсные затраты и нехватка времени…
Постараюсь уложиться в пару-тройку основных тезисов:
«Ну-очень-крутая-штука-во-всём», не правда ли? Однако, если Вы ни разу не сталкивались с её установкой и внедрением – не надо оптимистичных прогнозов. Мягко говоря, если у Вас есть в распоряжении пару свободных месяцев – welcome. Устанавливайте, настраивайте, есть и приятный бонус – полное how to на русском языке. Для нас основными плюсами были лицензия и легкая настройка связи с авто-тестами.
Итого: не было времени внедрять и учить ею пользоваться.
Неплохой, современный, красочный инструмент, интегрированный с JIRA. И все же – Вы видели, как там заводить тест-циклы и писать тест-кейсы? Для редактирования – отдельное окно, добавления шагов и результатов – только построчно и пронумерованно. Много ненужных действий, чтобы «создать-сохранить» сценарий.
Итого: Если перед нами один проект на полгода – аккуратно и неторопливо вбивайте тест-кейсы, в итоге всё будет достаточно красиво и прозрачно. Вариант также для нас не подошел.
Очень простой тул, который позволяет делать самое основное в работе тестировщика – тест-кейсы + тест-циклы. И всё. Дизайн – на троечку, удобство – тоже. Мне кажется, Test Link можно поставить дома для того, чтобы просто поизучать, как вносить тест-кейсы и проходить test run’ы с выставлением Passed/Blocked/Failed. Вариант, конечно, неплохой, тем более бесплатный. Минусы: неочевидность с авто-тестами, неидеальное написание тест-кейсов.
Итого: Окей, оставим для рассмотрения.
Бесплатный финский инструментарий, который несложно внедрить в QA команду. Плюсы – достаточно неплохо позволяет управлять тестовым процессом: тест-кейсы, тест-раны, отчеты. Верная структура: тест-кейс -> тест-сьют. Есть достаточно забавные моменты, такие как «теги» в тест-кейсах, по которым можно будет найти нужный тебе набор (допустим, нужны негатив тест-кейсы только по определенному функционалу, который затрагивает это-и-это -> изначально ставим во всех сценариях правильный набор тегов, отсюда легко делается выборка в отдельный тест-ран). Удобство – неплохое, для авто-тестов настроить можно… Минусы: отчетность хромает, кастомизация проблематичная, с JIRA не связан.
Итого: Оставим как один из вариантов на рассмотрение, почему нет?
На мой взгляд – один из самых легких, но в то же время очень масштабных существующих тулов. Главный плюс – кастомизация возможна практически во всём. Начиная от дизайна, заканчивая логикой. Прямая интеграция с JIRA. Эффективное занесение тест-кейсов и разбиение их по нужным сьютам. Как один из минусов – до недавнего времени у Test Rail была слабо реализована система отчетности: скудные результаты по тест-ранам, отсутствие кастомизации репортов и т.д. Однако Gurock & Co взялись за это дело и к 3-ей версии инструмента ребята сделали работу над ошибками. Отчетность заиграла новыми красками: хочешь – отчет по майлстоуну, хочешь – только по дефектам, хочешь – настроим регулярный е-мейл с посылкой отчета по тестированию строго определенного функционала и т.д. Молодцы! Итог – данный тул удовлетворял всем (!) моим требованиям, перечисленным немного выше.
• Это эффективное управление тест-кейсами, планами и тестовыми циклами (создание/хранение/редактирование тестовых сценариев, управление тестовыми планами, запуск тестовых циклов, занесение результатов тестирования)
• Это значительное повышение качества тестирования (четкое описание тестовых сценариев, их ревью, соотношение с требованиями, разделение на области — всё это позволяет оценить как полноту покрытия тестами функционала, так и является необходимым материалом для всей проектной команды)
• Это получение тестовых результатов в реальном времени (создание отчетов по совершенно разным критериям: Defect Summary, Comparison for Cases, тестовые результаты по проектам/компонентам/майлстоунам и т.д.)
• Это легкая организация и удобное отслеживание загрузки отдела тестирования (возможности для полной кастомизации «рабочего dashboard», а также удобное получение статуса работы QA отдела)
1. Поставили ТестРейл на виртуалку Windows Server 2008 R2 с базой MSSQL
2. Настроили AD аутентификацию
3. Настроили полноценную связь с JIRA
Для начала у каждого залогиненного пользователя TestRail необходимо настроить прямой выход в JIRA. Для этого нам понадобится пара кастомных переменных jira_user + jira_password (welcome to: docs.gurock.com/testrail-integration/defects-plugins-variables). После их создания в плагине JIRA_Rest (Administration -> Integration -> JIRA_Rest) выставляем следующее:
[connection]
address=http://jira/***
user=%jira_user%
password=%jira_password%
Ура. Теперь у каждого пользователя есть возможность в My Settings выставить логин/пароль от JIRA.
Далее в JIRA_Rest прописываем как связь непосредственно с установленной JIRA, так и впоследствии связи всех существующих у Вас JIRA fields: будь то основные поля, или кастомные (welcome to: docs.gurock.com/testrail-integration/tools-jira-rest).
Прямая связь с JIRA (пример):
Reference View Url: your-server/jira/browse/%id%
Reference Add Url: your-server/jira/secure/CreateIssue!default.jspa
Связи с основными полями (пример):
[push.fields]
summary=on
project=on
issuetype=on
component=on
assignee=on
priority=on
affects_version=on
fix_version=off
estimate=off
labels=off
environment=off
description=on
Связи с кастомными полями (пример):
[push.fields]
customfield_XXXXX=on
[push.field.customfield_XXXXX]
label=Customer
size=compact
type=dropdown
required=true
Как итог – при заведении бага можно смело воспользоваться инструментарием Test Rail, и при этом не тратить время на переход в соседнее окно с JIRA. Плюс ли? Вы знаете, при прогоне больших тестовых циклов и выставлении результатов тестирования – это несомненный плюс, так как те самые десятки секунд финально складываются в драгоценные минуты и просто-напросто удобство работы, что немаловажно.
И ещё: При генерации тестового репорта обычно мы выводим после результатов список известных дефектов, которые блокируют прохождение тест-кейса. Так вот, представьте себе такой список, и при наведении курсора на дефект в этом отчете всплывает попап с JIRA информацией о тикете – Summary, Description и т.д. Просто гениально! Всё сделано за вас.
4. После основных тех. настроек можно смело создавать проекты, привязанные к майлстоунам и тестовые сьюты, содержащие всевозможные секции с тест-кейсами, а также настраивать dashboard исключительно по вашим желаниям и критериям
Все мы знаем, что при создании тест-кейсов на какой-либо функционал для начала желательно составить тест-план, где четко будут описаны классы эквивалентности, секции и разбиение как минимум на позитивные-негативные сценарии. TestRail позволяет максимально эффективно составить такой план и впоследствии расширить его до полноценных сценариев.
Немного поподробнее: создаем тестовый сьют. Затем внутри него имеем возможность добавлять как секции, так и тест-кейсы внутри этих секций. Мы имеем возможность, не переходя к внутренней сущности кейса, составить шаблоны (= чек-лист/тест-план), вводя только Summary и нажимая Enter после ввода. Выглядит это так:
Набираете название (теста/группы/класса эквивалентности), нажимаете Enter -> и Вы уже на следующем кейсе с курсором в поле ввода. Таким образом, максимально быстро можно составить необходимый план, который зачастую до этого писался в Word, Excel или же вообще даже не создавался. Данные наработки должны пройти через команды аналитиков/девелоперов -> и по результатам ревью будет абсолютно понятно надо ли что-либо добавлять или же нет. Не забудем про то, что это всего лишь план, и чтобы не спутаться с тест-кейсами, которые уже заполнены полностью, мы ввели доп. поле Only Title, принимающее по умолчанию значение Yes.
Это поле можно исправить на No, только написав сам тест-кейс в форме редактирования (необходимо просто поставить галочку «Only Title» = No).
Любые кастомные поля, которые Вы вводите, можно также вынести на дашборд как и все остальные, выбрав их в отображаемых колонках (нажатие «таблички» на основной странице написания тест-кейсов в строке с перечислением названий полей: ID, Title an so on).
5. Все внутренние поля тест-кейса также кастомизируемы
В изначальной конфигурации Test Rail представлен классический и безусловно необходимый набор внутренних полей тестового сценария: ID, Приоритет, Начальные Условия, Вид, Шаги, Ожидаемый Результат, Ссылка на требования или задачу Implementation в JIRA и т.д. Вы имеете право добавить любое поле и настроить его как вы хотите: будь то string, checkbox, dropdown – не важно. Всё в Ваших руках и головах! Что сделали мы:
— Добавили поле Data for test-case, в котором для теста из одного класса эквивалентности просто-напросто перечисляем какие-либо данные, с которыми тест должен быть выполнен. Это может быть все что угодно: начиная от ролей выполняющего, заканчивая перечислением строк ввода.
— Добавили поля ID Auto и Auto. ID Auto – уникальный ID для авто-теста. Auto – чекбокс Yes/No, который показывает автоматизирован ли тест-кейс или нет.
Сделано это для того, чтобы в дальнейшем при настраивании Test Rail для автоматизации можно было сразу использовать эти параметры для запуска необходимых авто-тестов и генерации по ним нужного отчета (http://www.gurock.com/testrail/tour/5/ — Automated tests and API).
6. Для любого test run можно выбрать абсолютно любой набор тест-кейсов
Test Rail позволяет создавать тестовые циклы по любым критериям. Это очень важная особенность инструмента, так как зачастую необходимо прогнать строго определенные сценарии (выбранные по приоритетам, по майлстоунам, по названию, по части названия, да как угодно на самом деле – все зависит от поставленных целей). Так вот, при назначении Test Run мы имеем возможность выбрать «свой» сьют по фильтру. Общий вид таков:
А вот, допустим, выбираем по названию, которое «равно или содержит что-то»:
При всем этом тестовый сьют может быть выбран для прогона полностью.
7. Настраиваемая репортинговая система
Любой тестовый прогон может быть представлен в виде четкого отчета: «что-где-когда-почему». Возможно выбрать любые критерии, точно так же, как и при создании тестового цикла. Кроме прочего, рассылку всевозможных отчетов имеет смысл настроить на необходимое время и заинтересованных адресатов.
Чек-листы, ad-hoc тестинг – это хорошо, однако, без четких процедур зачастую у продукта выявляются слабые места, которые со временем усиливаются и тянут компанию вниз. Имея как набор тест-кейсов, так и матрицу покрытия (хотя бы покомпонентно) – этого можно избежать.
Я перечислил далеко не все возможности TestRail и привел в пример лишь несколько вариантов его использования. Тем не менее, очевидно, что такая гибкая кастомизируемость позволит многим настроить данный инструмент под свой процесс разработки. Кроме прочего, тул позволяет совершенно прозрачно наблюдать за QA отделом, что, во-первых, избавляет всех от недосказанности «а что же они тестируют», а, во-вторых, налаживает четкое взаимодействие между командами и даёт понимание «зачем и как тестировать».
Выбирайте свой тул, тестируйте, контролируйте процесс! Удачи во всех начинаниях!
Автор статьи: Василий Петухов, руководитель отдела анализа и управления качеством Дневник.ру
Лирическое вступление
Что такое петербургская осень? Дожди, Розенбаум, меланхолия… Разве всё?! Нет, ещё это новый учебный год, который во многих регионах нашей страны начался именно с Дневник.ру. За лето мы успели достичь определенных успехов: число пользователей проекта перевалило отметку в 7 000 000, мы стали единственной российской компанией, вошедшей в список «World Economic Forum Technology Pioneers 2014», а Республика Северная Осетия-Алания полностью перешла на электронные журналы с Дневник.ру. На этом лирическое вступление окончим и перейдем к сути данного поста.
Вступление по теме
В современной IT индустрии многие до сих пор удивляются: «зачем вообще нужен отдельный тестовый отдел?». Как один из участников тестовой команды нашего проекта, ответственно заявляю: это ошибочное мнение. Организовать отдел QA – дело нелегкое, но оно того стоит.
В этом случае для себя надо четко понимать:
— что считать критерием качества?
— какие метрики использовать?
— с помощью какого инструментария проводить тестирование?
— как строить взаимодействие с разработчиками/аналитиками и т.д.
По большому счету изобретать велосипед не стоит – данные практики описаны на миллионах интернет-страниц, успешно применяются во многих корпорациях, чей опыт можно перенять. Однако не нужно забывать простую истину – везде есть своя специфика. Например, в Дневник.ру это сильно-связанные между собой компоненты и CI (Continuous Integration), а попросту – высокий уровень интеграции связанных областей. Как лучше тестировать в этом случае?
Начнем с простого: любая информация никогда не сможет на 100% автоматически «всплывать» в вашей (бесспорно, очень умной) голове. QA-шникам в первую очередь необходимо запоминать и в дальнейшем прогонять тестовые сценарии, которые проверяются от релиза к релизу – «а не сломалось ли что?». Как мы все знаем – регрессионное тестирование. Но сейчас не об этом, про виды – welcome to protesting.ru (хороший, кстати говоря, ресурс).
Так вот, для написания и хранения тест-кейсов («Тест-кейс — артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части») можно использовать массу инструментов: Excel, блокнот, google-docs, листы бумаги, в конце концов. Но разве это эффективно и удобно? Для одного человека – может быть. Для команды, где статус проекта «надо было знать уже вчера» – определенно нет.
Подготовительные работы
Давно уж существует множество тяжеловесных Test Management программ, позволяющих полноценно менеджерить тестовый процесс: работа с тест-планами, тест-циклами, реквайментсами, тест-кейсами и т.д. Работал я с разными тулами – платными, бесплатными, саморучно-написанными… За многие годы уверился, что в данном вопросе лучше не скупиться на деньги: либо приобрести качественный инструмент, либо нанять команду и написать «идеальный для компании тул, с теми требованиями, которые вам нужны».
Итак, во-первых: стало ясно, что существующие чек-листы не справляются с успешностью тестирования. Их недостаточно, в них мало информации, они не прозрачны, по ним сложно представить результаты, их трудно поддерживать, не хватает времени для написания новых. Во-вторых: в сложившейся ситуации нам нужен был достаточно лёгкий для понимания инструмент, который позволит эффективно управлять тест-менеджментским сценарием: «требования -> тест-кейсы -> ревью -> тестовый сьют -> тестовый цикл -> результаты».
Суммируя всё вышесказанное, требования к тулу были такими:
— удобный пользовательский интерфейс
— удобство установки, внедрения и поддержки
— удобное написание и хранение тестовых сценариев
— связь с JIRA
— эффективное управление следующим сценарием: «требования -> тест-кейсы -> ревью -> тестовый сьют -> тестовый цикл -> результаты»
— удобный выбор тест-кейсов из разных областей для запуска в одном test run’е
— легкость получения прозрачных отчетов по запуску тестовых-сьютов
— возможность в будущем связать тул с авто-тестированием и запуском написанных авто-тестов
Итак, что рассматривали:
— Microsoft Test Lab (how to на русском)
— Zephyr
— Test Link
— Testia Tarantula
— Test Rail
PS: предупреждая вопросы – HP Quality Center мы не рассматривали, потому что 1) неоправданно дорого 2) не очень он и «приветливый», особенно к тем, кто никогда не работал с тест-тулами, а писать свой – ресурсные затраты и нехватка времени…
Постараюсь уложиться в пару-тройку основных тезисов:
Microsoft Test Lab
«Ну-очень-крутая-штука-во-всём», не правда ли? Однако, если Вы ни разу не сталкивались с её установкой и внедрением – не надо оптимистичных прогнозов. Мягко говоря, если у Вас есть в распоряжении пару свободных месяцев – welcome. Устанавливайте, настраивайте, есть и приятный бонус – полное how to на русском языке. Для нас основными плюсами были лицензия и легкая настройка связи с авто-тестами.
Итого: не было времени внедрять и учить ею пользоваться.
Zephyr
Неплохой, современный, красочный инструмент, интегрированный с JIRA. И все же – Вы видели, как там заводить тест-циклы и писать тест-кейсы? Для редактирования – отдельное окно, добавления шагов и результатов – только построчно и пронумерованно. Много ненужных действий, чтобы «создать-сохранить» сценарий.
Итого: Если перед нами один проект на полгода – аккуратно и неторопливо вбивайте тест-кейсы, в итоге всё будет достаточно красиво и прозрачно. Вариант также для нас не подошел.
Test Link
Очень простой тул, который позволяет делать самое основное в работе тестировщика – тест-кейсы + тест-циклы. И всё. Дизайн – на троечку, удобство – тоже. Мне кажется, Test Link можно поставить дома для того, чтобы просто поизучать, как вносить тест-кейсы и проходить test run’ы с выставлением Passed/Blocked/Failed. Вариант, конечно, неплохой, тем более бесплатный. Минусы: неочевидность с авто-тестами, неидеальное написание тест-кейсов.
Итого: Окей, оставим для рассмотрения.
Testia Tarantula
Бесплатный финский инструментарий, который несложно внедрить в QA команду. Плюсы – достаточно неплохо позволяет управлять тестовым процессом: тест-кейсы, тест-раны, отчеты. Верная структура: тест-кейс -> тест-сьют. Есть достаточно забавные моменты, такие как «теги» в тест-кейсах, по которым можно будет найти нужный тебе набор (допустим, нужны негатив тест-кейсы только по определенному функционалу, который затрагивает это-и-это -> изначально ставим во всех сценариях правильный набор тегов, отсюда легко делается выборка в отдельный тест-ран). Удобство – неплохое, для авто-тестов настроить можно… Минусы: отчетность хромает, кастомизация проблематичная, с JIRA не связан.
Итого: Оставим как один из вариантов на рассмотрение, почему нет?
Test Rail
На мой взгляд – один из самых легких, но в то же время очень масштабных существующих тулов. Главный плюс – кастомизация возможна практически во всём. Начиная от дизайна, заканчивая логикой. Прямая интеграция с JIRA. Эффективное занесение тест-кейсов и разбиение их по нужным сьютам. Как один из минусов – до недавнего времени у Test Rail была слабо реализована система отчетности: скудные результаты по тест-ранам, отсутствие кастомизации репортов и т.д. Однако Gurock & Co взялись за это дело и к 3-ей версии инструмента ребята сделали работу над ошибками. Отчетность заиграла новыми красками: хочешь – отчет по майлстоуну, хочешь – только по дефектам, хочешь – настроим регулярный е-мейл с посылкой отчета по тестированию строго определенного функционала и т.д. Молодцы! Итог – данный тул удовлетворял всем (!) моим требованиям, перечисленным немного выше.
Итого: наш выбор – внедрение Test Rail. Собственно говоря, что такое Test Rail?
• Это эффективное управление тест-кейсами, планами и тестовыми циклами (создание/хранение/редактирование тестовых сценариев, управление тестовыми планами, запуск тестовых циклов, занесение результатов тестирования)
• Это значительное повышение качества тестирования (четкое описание тестовых сценариев, их ревью, соотношение с требованиями, разделение на области — всё это позволяет оценить как полноту покрытия тестами функционала, так и является необходимым материалом для всей проектной команды)
• Это получение тестовых результатов в реальном времени (создание отчетов по совершенно разным критериям: Defect Summary, Comparison for Cases, тестовые результаты по проектам/компонентам/майлстоунам и т.д.)
• Это легкая организация и удобное отслеживание загрузки отдела тестирования (возможности для полной кастомизации «рабочего dashboard», а также удобное получение статуса работы QA отдела)
Внедрение
1. Поставили ТестРейл на виртуалку Windows Server 2008 R2 с базой MSSQL
2. Настроили AD аутентификацию
3. Настроили полноценную связь с JIRA
Для начала у каждого залогиненного пользователя TestRail необходимо настроить прямой выход в JIRA. Для этого нам понадобится пара кастомных переменных jira_user + jira_password (welcome to: docs.gurock.com/testrail-integration/defects-plugins-variables). После их создания в плагине JIRA_Rest (Administration -> Integration -> JIRA_Rest) выставляем следующее:
[connection]
address=http://jira/***
user=%jira_user%
password=%jira_password%
Ура. Теперь у каждого пользователя есть возможность в My Settings выставить логин/пароль от JIRA.
Далее в JIRA_Rest прописываем как связь непосредственно с установленной JIRA, так и впоследствии связи всех существующих у Вас JIRA fields: будь то основные поля, или кастомные (welcome to: docs.gurock.com/testrail-integration/tools-jira-rest).
Прямая связь с JIRA (пример):
Reference View Url: your-server/jira/browse/%id%
Reference Add Url: your-server/jira/secure/CreateIssue!default.jspa
Связи с основными полями (пример):
[push.fields]
summary=on
project=on
issuetype=on
component=on
assignee=on
priority=on
affects_version=on
fix_version=off
estimate=off
labels=off
environment=off
description=on
Связи с кастомными полями (пример):
[push.fields]
customfield_XXXXX=on
[push.field.customfield_XXXXX]
label=Customer
size=compact
type=dropdown
required=true
Как итог – при заведении бага можно смело воспользоваться инструментарием Test Rail, и при этом не тратить время на переход в соседнее окно с JIRA. Плюс ли? Вы знаете, при прогоне больших тестовых циклов и выставлении результатов тестирования – это несомненный плюс, так как те самые десятки секунд финально складываются в драгоценные минуты и просто-напросто удобство работы, что немаловажно.
И ещё: При генерации тестового репорта обычно мы выводим после результатов список известных дефектов, которые блокируют прохождение тест-кейса. Так вот, представьте себе такой список, и при наведении курсора на дефект в этом отчете всплывает попап с JIRA информацией о тикете – Summary, Description и т.д. Просто гениально! Всё сделано за вас.
4. После основных тех. настроек можно смело создавать проекты, привязанные к майлстоунам и тестовые сьюты, содержащие всевозможные секции с тест-кейсами, а также настраивать dashboard исключительно по вашим желаниям и критериям
Все мы знаем, что при создании тест-кейсов на какой-либо функционал для начала желательно составить тест-план, где четко будут описаны классы эквивалентности, секции и разбиение как минимум на позитивные-негативные сценарии. TestRail позволяет максимально эффективно составить такой план и впоследствии расширить его до полноценных сценариев.
Немного поподробнее: создаем тестовый сьют. Затем внутри него имеем возможность добавлять как секции, так и тест-кейсы внутри этих секций. Мы имеем возможность, не переходя к внутренней сущности кейса, составить шаблоны (= чек-лист/тест-план), вводя только Summary и нажимая Enter после ввода. Выглядит это так:
Набираете название (теста/группы/класса эквивалентности), нажимаете Enter -> и Вы уже на следующем кейсе с курсором в поле ввода. Таким образом, максимально быстро можно составить необходимый план, который зачастую до этого писался в Word, Excel или же вообще даже не создавался. Данные наработки должны пройти через команды аналитиков/девелоперов -> и по результатам ревью будет абсолютно понятно надо ли что-либо добавлять или же нет. Не забудем про то, что это всего лишь план, и чтобы не спутаться с тест-кейсами, которые уже заполнены полностью, мы ввели доп. поле Only Title, принимающее по умолчанию значение Yes.
Это поле можно исправить на No, только написав сам тест-кейс в форме редактирования (необходимо просто поставить галочку «Only Title» = No).
Любые кастомные поля, которые Вы вводите, можно также вынести на дашборд как и все остальные, выбрав их в отображаемых колонках (нажатие «таблички» на основной странице написания тест-кейсов в строке с перечислением названий полей: ID, Title an so on).
5. Все внутренние поля тест-кейса также кастомизируемы
В изначальной конфигурации Test Rail представлен классический и безусловно необходимый набор внутренних полей тестового сценария: ID, Приоритет, Начальные Условия, Вид, Шаги, Ожидаемый Результат, Ссылка на требования или задачу Implementation в JIRA и т.д. Вы имеете право добавить любое поле и настроить его как вы хотите: будь то string, checkbox, dropdown – не важно. Всё в Ваших руках и головах! Что сделали мы:
— Добавили поле Data for test-case, в котором для теста из одного класса эквивалентности просто-напросто перечисляем какие-либо данные, с которыми тест должен быть выполнен. Это может быть все что угодно: начиная от ролей выполняющего, заканчивая перечислением строк ввода.
— Добавили поля ID Auto и Auto. ID Auto – уникальный ID для авто-теста. Auto – чекбокс Yes/No, который показывает автоматизирован ли тест-кейс или нет.
Сделано это для того, чтобы в дальнейшем при настраивании Test Rail для автоматизации можно было сразу использовать эти параметры для запуска необходимых авто-тестов и генерации по ним нужного отчета (http://www.gurock.com/testrail/tour/5/ — Automated tests and API).
6. Для любого test run можно выбрать абсолютно любой набор тест-кейсов
Test Rail позволяет создавать тестовые циклы по любым критериям. Это очень важная особенность инструмента, так как зачастую необходимо прогнать строго определенные сценарии (выбранные по приоритетам, по майлстоунам, по названию, по части названия, да как угодно на самом деле – все зависит от поставленных целей). Так вот, при назначении Test Run мы имеем возможность выбрать «свой» сьют по фильтру. Общий вид таков:
А вот, допустим, выбираем по названию, которое «равно или содержит что-то»:
При всем этом тестовый сьют может быть выбран для прогона полностью.
7. Настраиваемая репортинговая система
Любой тестовый прогон может быть представлен в виде четкого отчета: «что-где-когда-почему». Возможно выбрать любые критерии, точно так же, как и при создании тестового цикла. Кроме прочего, рассылку всевозможных отчетов имеет смысл настроить на необходимое время и заинтересованных адресатов.
Заключение
Чек-листы, ad-hoc тестинг – это хорошо, однако, без четких процедур зачастую у продукта выявляются слабые места, которые со временем усиливаются и тянут компанию вниз. Имея как набор тест-кейсов, так и матрицу покрытия (хотя бы покомпонентно) – этого можно избежать.
Я перечислил далеко не все возможности TestRail и привел в пример лишь несколько вариантов его использования. Тем не менее, очевидно, что такая гибкая кастомизируемость позволит многим настроить данный инструмент под свой процесс разработки. Кроме прочего, тул позволяет совершенно прозрачно наблюдать за QA отделом, что, во-первых, избавляет всех от недосказанности «а что же они тестируют», а, во-вторых, налаживает четкое взаимодействие между командами и даёт понимание «зачем и как тестировать».
Выбирайте свой тул, тестируйте, контролируйте процесс! Удачи во всех начинаниях!
Автор статьи: Василий Петухов, руководитель отдела анализа и управления качеством Дневник.ру
