TestRail: Comprehensive Test Case Management
for QA and Development Teams
A complete web-based test case management solution to efficiently manage, track, and organize your software testing efforts.
Centralized Test Management
Collaborate with stakeholders on test cases, plans, and runs.
Easily Track Results
Execute your tests and track results that matter.
Powerful Reports and Metrics
Actionable reports, metrics, and real-time insights.
Seamless Integration
Integrate with bug trackers, automated tests, and more.
Increased Productivity
Fast and easy to use for a productive, happy team.
Scalable and Customizable
Cloud or download, highly customizable, and much more.
Top Jira Add-ons, Live Defect Reports, Fast Context Tabs, and more
TestRail includes a seamless integration with Atlassian Jira that will significantly boost your productivity.
assignment_turned_inComprehensive test case management
Manage test cases, plans, and runs in a collaborative platform
done_allEasily track your test results
Execute tests and track results that matter.
donut_smallPowerful testing reports and metrics
Create powerful reports and review actionable metrics.
extensionSeamless integration with your existing tools
Integrate with bug/issue trackers, automated tests & more.
supervised_user_circleIncreased productivity for your team
Increase productivity with a powerful and easy-to-use interface.
TestRail is used by thousands of teams, both small and large.
TestRail helps you manage and track your software testing efforts and organize your QA department. Its intuitive web-based user interface makes it easy to create test cases, manage test runs and coordinate your entire testing process.
Easily track and follow the status of individual tests, milestones and projects with dashboards and activity reports. Get real-time insights into your testing progress and boost productivity with personalized to-do lists, filters and email notifications. For more efficient test management, get started today!
Обзор TestRail – лучшего инструмента управления тест-кейсами
В этой статье мы познакомимся с практической возможностью управления процессом тестирования на основе инструмента TestRail: разберем его практическое применение и основные особенности.
Итак, с помощью TestRail можно достичь полного управления тестовыми случаями на проекте в сочетании различных практик и методологий тестирования, а также функции, специально оптимизированные под процесс тестирования ПО.
Данный инструмент может запросто быть использован в случае применения как Agile разработки, так и методологии тестирования. Однако, гибкость TestRail в процессе тестирования ПО позволяет использовать его при любой методологии ведения проекта в сфере QA.
Функциональность TestRail
Основные возможности данного продукта:
Данная программа поддерживает различные типы тестирования. Ее можно использовать для задач мануального и скриптового тестирования, организации исследовательского тестирования, а также для потенциальной интеграции с выбранными инструментами автоматизации проверок.
Функционал TestRail включает в себя открытый API, а значит, пользователи могут самостоятельно создавать открытые интеграции. Подобная гибкость делает инструмент TestRail максимально востребованным в своей нише.
Отдельно стоит отметить простой в понимании пользовательский интерфейс, который позволяет максимально быстро усвоить основные команды, без существенной затраты времени на обучение. Более того, среди доступного клиенту функционала TestRail есть специальные расширенные возможности, например, настраиваемые отчеты.
Далее разберем методику использования TestRail на основе тестового примера, где будет отображаться ежедневный ход тестирования, сумма пройденных этапов и неудавшиеся тесты.
Вверху экрана расположены вкладки Test Runs и Milestones. Test run применяется для группировки всех тестовых случаев перед процессом их выполнения. В свою очередь Milestones показывает сумму тестов под конкретные задачи (к примеру, для финального релиза ПО).
Разбор программы TestRail
Чтобы ознакомится с другим перечнем предлагаемой функциональности или загрузить себе пробную версию данного продукта перейдите по ссылке.
Итак, пользователь может выбрать размещенную в облаке версию для быстрой настройки, или специальную версию Server для установки на локальный компьютер.
Для начала нужно корректно заполнить все обязательные поля, как продемонстрированно на скриншоте ниже.
Установка пробной версии TestRail
После регистрации новому пользователю на почту отправится специальная ссылка, подтверждающая присвоение пробной версии продукта. При переходе по ссылке, пользователь попадет на тестовую версию TestRail.
Важная информация! В зависимости от вашего местонахождения вам может понадобиться заключить договор на обработку данных для подтверждения соответствия Общим правилам защиты данных (GDPR).
После этого настройка учетной записи в TestRail может считаться официально завершенной.
Приступая к работе
Экран, который пользователь видит при открытии программы – это специальная приборная панель TestRail.
Приборная панель TestRail
Вначале нужно перейти на вкладку Administration. Это необходимо, чтобы добавить пользователей и роли, продлить пробную подписку, настроить пользовательские поля, настроить интеграцию и прочее.
При переходе на вкладку Users and Roles можно увидеть, что вам присвоена роль администратора проекта.
Открыв вкладку Roles, будет виден перечень ролей на проекте – Read-only, Tester, Designer, и Lead.
Перечень ролей на проекте
Если вы нажмете на иконку карандаша, откроется панель, где будут отображены права для каждой роли. Администратор здесь может поменять описания, создать дополнительные тестовые задания, добавить или удалить с проекта одного или нескольких пользователей, организовать группы и прочее.
Вкладка Dashboard позволяет открыть перечень инструментов по полному управлению проектом, отслеживанию выполнения тестов и их менеджмента.
Создание нового проекта
Создание нового проекта
Чтобы добавить новый проект, нужно кликнуть на кнопку Add Project. Итак, задаем проекту новое имя, выбираем опцию его сохранения (рекомендуется использовать пункт — multiple test suites to manage cases).
Данный параметр позволяет начать проект с одного набора тестов, а затем по мере выполнения добавлять новые наборы проверок при необходимости.
Нажимаем на Add Project.
Пользователь сразу увидит панель с новым проектом. Можно изменить название проекта или удалить его позже, если захотите.
На скриншоте ниже показана приборная панель, например, проект с несколькими тестовыми наборами и другой проект с одним репозиторием.
Приборная панель проекста с несколькими тест-кейсами
Перейдите по вкладке Test Suites. Так как это новый проект, должен отобразиться набор тестов под названием Master. Просто нажмите на название пакета для редактирования его разделов и тестовых случаев.
Либо же нажмите на кнопку Add Test Suite и попробуйте добавить новый набор тестов к вашему проекту, как это отображено на скриншоте ниже.
Добавление набора тестов
Создание тестового случая
Теперь можно приступить к добавлению нового тестового случая. Как только вы увидите на экране это сообщение (смотри ниже), просто нажмите на кнопку Add Test Case.
Создание тестового случая
Появляется детальное представление тестового случая, как показано ниже. Для примера, добавим простой тест под названием «Login».
Заполнение полей при создании тест-кейса
Следующие четыре поля обязательны для заполнения, и могут быть использованы для сортировки и фильтрации тестовых случаев: Section, Template, Type и Priority.
Теперь можно выполнить тест с внесенными ранее предварительными условиями, шагами и ожидаемыми результатами. После завершения теста, нажимаем на кнопку Add Case.
Будет отображаться краткое описание тестового случая, как на рисунке:
Краткое описание тестового случая
Можно добавить еще несколько тестовых случаев.
Для этого нажимаем на ссылку Test Cases для открытия меню тестовых случаев. Остается только внести оригинальные наименования тестов.
Важная информация!
После создания тестовых случаев, следующим шагом будет построение тестового запуска. Это набор тестов, которые можно использовать для конкретной цели, такой как регрессионное тестирование, дымовые тесты, тестирование новых функций, тестирование на базе рисков и др.
Если появится запрос на выбор набора тестов, выберите «Master», а затем нажмите OK.
После успешного сохранения тестов, можно просмотреть легко настраиваемые отчеты внутри программы TestRail.
Скриншот ниже показывает отчеты, которые будут доступны в процессе тестирования конкретного проекта. К слову, весь перечень дополнительных отчетов доступен на специальной вкладке Reports.
Особенности настройки контрольных точек
Несмотря на то, что нет крайней необходимости устанавливать контрольные точки для прохождения тестовых примеров, это считается хорошей практикой.
С их помощью можно быстро отслеживать прогресс сразу по нескольким тестовым циклам.
Итак, для добавления контрольных точек стоит использовать вкладку с таким же названием.
Как только все проверки будут завершены в тестовом режиме, можно заблокировать цикл, что предотвратит внесение изменений в будущем. А значит, даже если тестовый случай меняется для будущего цикла, его определение сохраняется для текущего цикла, если потребуется провести аудит итогов тестирования немного позже.
Однозначно, использование на проектах TestRail существенным образом повышает общую производительность команды тестировщиков при выполнении независимого тестирования.
TestRail – это хорошая и удобная альтернатива архаичным таблицам и текстовым документам, где можно быстро и качественно отслеживать все шаги тестирования веб-продуктов.
TestRail — Индивидуальные настройки под проект
Введение
Во многих проектах, с которыми я работал, люди не настраивали под себя TestRail и обходились стандартными настройками. Поэтому в данной статье я постараюсь описать пример индивидуальных настроек, которые могут помочь Вам повысить эффективность своей работы. Для примера возьмем проект разработки мобильного приложения.
Небольшой дисклеймер. В данной статье нет описания базового функционала TestRail (на это есть много гайдов) и продающих выражений красочно описывающих почему нужно выбрать именно этого вендора для создания репозитория с тестами.
План-обоснование (что будет реализовано)
Кейс должен смочь пройти абсолютно любой человек
Кейсы должны сохранять актуальность как можно дольше
Кейсы должны максимально тщательно покрывать функционал мобильного приложения в той мере, в которой это не противоречит первым двум пунктам
Разделение на TestCase и TestScenario
Быстрое формирование TestRun различных типов
Impact тестирование и т.д.
Оптимизация поддержки кейсов
Отказ от «мертвых» захардкоженных скриншотов и переход на «movable data»
Requirements
Для редактирования полей Вам потребуется администраторский доступ
Выбор типа проекта
Можно выбрать три типа проекта:
Мы выберем тип по умолчанию. В нем будут доступны одновременно все кейсы. Мы будем пользоваться умной фильтрацией и динамически управлять всеми кейсами сразу.
Добавление полей для просмотра списка тест кейсов
Добавим поле для отображения priority тест кейсов:
Также можно добавить и другие поля.
Настройка полей и тегов тест кейса
Открываем меню настройки:
Нам потребуются такие поля:
Поле «Summary» (шапка тест кейса)
Данное поле уже существует, мы только систематизируем его использование. Будем разделять кейсы на TestCase и TestScenario. Для лучшей читаемости большого списка кейсов лучше заранее договорится по регламенту написания summary.
TestScenario:
TestCase:
Итого мы видим в summary кейса классическое понимание: “что, где, когда”. Также визуально мы разделяем верхнеуровневые тестовые сценарии и низкоуровневые тест кейсы в наиболее подходящем для автоматизации виде.
Тег «StartScreen» (экран с которого начинается TestScenario, также многие тест кейсы могут задевать соседние экраны)
Для чего может понадобится: мы будем удалять из текста текст кейсов типовые шаги приводящие пользователя на экран текущего тест кейса. (типовые шаги для создания определенной тестовой ситуации) Все типовые шаги для всех тест кейсов будут прописаны в одном файлике. О нём более подробно напишу отдельно.
Создаем новое поле:
Заполняем компоненты нового поля:
В данном случае мы создаем поле выбора из списка значений. Вводим значения этого поля:
Обратите внимание, что id значений начинаются не с единицы и идут не подряд. Почему так сделано? Дело в том, что если у нас будут записаны тесткейсы с введенным id,
и после этого нам потребуется создать третий экран между двумя существующими,
то нам придется переписать id, и так как к нему уже привязаны теги существующих текст кейсов, то они просто удаляться. Это будет очень неприятно.
Тег «Screen» (наименование экрана который затрагивает TestCase)
Для чего может понадобится: один из якорей для импакт тестирования. Например, разработчики сделали новую крутую фичу. Нам нужно её протестировать, но для это нужно понять, что именно эта фича могла затронуть. По умолчанию мы может отталкиваться от парадигмы, что разные экраны (Activity) приложения имеют разные классы и следовательно составляют различные компоненты приложения. Конечно же в данном случае нужен индивидуальный подход.
Пример: home_screen, MapScreen, PayScreen и т.д.
Поле «MovableData» (cсылка на прокси БД c изменяемыми тестовыми данными)
Далее мы постараемся решить проблему поддержки актуальности данных в тесткейсах:
Ссылки на актуальные макеты (это гораздо лучше чем делать мертвые скриншоты)
Типовые шаги до экрана с тестовой ситуацией
Ссылки на внешние данные и прочие данные
Вместо прописывания тестовых данных внутри каждого тест кейса мы создадим один внешний файл, и на всех тест кейсах сделаем ссылку на него. При обновлении этих данных нам не придется перебирать все тест кейсы и изменять их, а можно будет изменить эти данные только в одном месте. Если кто-то неподготовленный откроет тест кейс, он увидит в теле тест кейса ссылку на файлик и подсказку, что нужно в него идти за тестовыми данными.
Все эти данные мы упакуем в один внешний файлик, который будет доступен всем желающим на проекте. Например можно использовать Google Sheet или Excel и настроить внутри файла поиск. Почему именно эти вендоры? Дело в том, что мы отталкиваемся от парадигмы, что открыть и пройти тест кейс должен смочь любой человек в команде без необходимости предварительно всякие тулзы устанавливать.
Для Google Sheet можно использовать SQL запросы. Пример:
Для Excel можно настроить удобные макросы мгновенного поиска. (фильтрации) Пример по ссылке.
Собственно идея не нова и описана в первой книжке тестировщика “Тестирование dot com”. (автор Савин Роман) Мы лишь только интегрируем в TestRail предложенные Романом Савиным методики. Для этого создадим поле со ссылкой на созданный файлик:
заполняем дефолтное значение ссылки, чтобы в каждом новом тест кейсе уже ссылка была:
Если местоположение внешнего файла изменится (мы предусматриваем любой форс мажор) то можно удобно во всех тест кейсах сразу изменить одно или несколько полей:
Поле “Descriptions” (описание или идея тест кейса, типовые инструкции)
Для чего может понадобится: В данное текстовое поле мы поместим краткое описание тест кейса и типовые инструкции.
Пример: Все тестовые данные (актуальные макеты, использование тулов и прочие данные) из данного тест кейса обозначены ссылками <…>и находятся в файле MovableData. Ссылка на MovableData в соответствующем поле вверху.
Тег «Component» (компонент мобильного приложения)
Для чего может понадобится: для импакт тестирования. Если мобильное приложение можно разделить на компоненты (которые как можно меньше друг друга аффектят) то изменения в одном компоненте будет достаточно (с какими-то рисками) проверить в рамках этого же компонента, и будет меньше оснований для проведения всеобщих регрессов всего и вся. Если есть информация, что один компонент может аффектить другой, то составляется матрица импакт тестирования.
Пример компонентов: GooglePay, Order, Users, Map, Authorization и т.д.
Тег «TAG» (Прочие теги для фильтрации)
Тегирование тест кейса метками для произвольной фильтрации.
быстрого составления TestRun для различных типовых задач: smoke, регресс и т.д.
будут ли тесты автоматизированы или уже автоматизированы
Пример: Smoke, Automated, WhiteLabel, ForDelete и т.д.
Настраиваем порядок отображения полей в тест кейсе
Мы создали много новый полей, пришло время расположить их в удобном порядке:
Создание TestRun
Теперь мы создадим новый test run с актуальными кейсами для проведения smoke тестирования в три клика:
Другие полезные советы
Если в TestRail несколько проектов, то не забывайте создавать новые поля только под Ваш проект иначе коллеги из соседних комманд очень сильно удивятся появлению новых необычных полей. Возможны локальные обмороки.
2. Кейсы с большим количеством полей проще копировать из аналогичной группы\типа чем создавать новые:
3. Можно использовать учетные записи совместно. Например: одна администраторская, несколько пользовательских.
Заключение
Вышеописанные примеры были внедрены на несколько проектов и показали свою эффективность. Надеюсь они помогут улучшить Ваше понимание данной тулы и помогут создавать эффективные и удобные“тестохранилки”. Буду очень благодарен, если Вы в комментариях опишите Ваш опыт использования TestRail и полезные советы.
Как помочь мануальному тестировщику. Автоматизаторы спешат на помощь
В любой команде, которая уделяет должное время тестированию, приходит тот момент, когда задается вопрос об автоматизации этого процесса. Как это происходит? Есть несколько путей для развития: либо сами тестировщики начинают автоматизировать, либо нанимается специально обученный человек, который, как панацея, должен решить все проблемы. В независимости от того, как это происходит, в конечном итоге мы все сталкиваемся с тем, что нужно как-то показать, что происходит, какова реальность — что же было сделано. Как говорил один мой коллега, «автоматизация ради автоматизации — это подобие культа Карго», так как бывает, что отдел автоматизации существует, а вот результата нет.
Итак, основная задача инженера-автоматизатора в том, чтобы сделать жизнь проще. В этот раз упростить жизнь мы собираемся отделу ручного тестирования (если таковой имеется) или же самим себе, если весь процесс тестирования возложен на наши плечи.
Немножко структурных данных
В нашей компании существует отдел ручного тестирования и автоматизаторы. Как система для организации тестов используется довольно популярный инструмент — TestRail. С моей точки зрения удобный и довольно функциональный.
Автоматизация построена тоже на довольно стандартном наборе Ruby + Cucumber + Watir/Selenium (можно упомянуть паттерн Page Object) + TeamCity.
Что происходит, когда на тестирование дается новый билд, (в нашем случае каждый раз мы имеем дело с регрешшеном)? Тестировщик создает новый тест ран, в который включаются все тест-кейсы с определенного тест-сьюта и — пошло поехало веселье. Уверен, всем знакомо то чувство, когда ты в 4-й раз прогоняешь вручную регрешшн или смоук на автомате, кликая/тапая на все элементы и проставляя статус для очередного теста. В этот момент пред красными глазами наверняка все плывет и картинка в голове повторяет знаменитое:
Именно сейчас приходим на помощь мы. Так уж получилось, что возникла идея. Если у нас есть автоматизация, то почему мы все еще не используем результаты нашей работы, чтобы жить стало проще? Мысль заключается в том, чтобы использовать отчет с TestRail вместо громоздких и непонятных отчетов с Cucumber. Довольно интересная задач — сделать так, чтобы тесты в TestRail сами меняли свой статус, в зависимости от того, как прошел автотест.
С помощью поиска всемогущего гугла была найдена документация по TestRail API для реализации сией благой цели. Мы решили для начала сделать так, чтобы запуская наши автотесты вся информация о текущем состоянии тестов отображалась в TestRail. Собственно, цель была достигнута — по нажатии на кнопку запуска тестов в RubyMine мы автоматически создавали новый тестран и отсылали результаты на сервер. Довольно просто, учитывая существующую информацию на сайте TestRail.
Как оказалось, это было всего лишь начало.
В конечном итоге удалось сделать довольно неплохую функциональность, а именно — мы настроили интеграцию TestRail + TeamCity + Automation Framework.
Теперь же подробности, уважаемые дамы и господа.
TestRail
Первая остановка у нас будет TestRail.
TestRail является программным обеспечением для управления данными полученными в результате тестирования. Данный инструмент помогает отслеживать процессы, управлять программным обеспечением и организовывать команду.
С помощью TestRail можно создавать тест кейсы, управлять тестовыми наборами и координировать весь процесс тестирования программного обеспечения. TestRail предоставляет возможность повысить производительность и получить полный обзор хода процесса тестирования.
Начнем мы с того, что первое, что должен сделать наш юзер/мануал тестировщик — это создать собственно тестран, который в последствии мы и будем использовать для апдейтов.
Требования:
Фича: Запуск автотестов.
Для того, чтобы использовать автоматизации в реальной жизни.
Как пользователь я хочу, чтобы была волшебная кнопка «запустить ран с автотестами».
Сказано — сделано. Благо функционал TestRail позволяет нам интегрировать свой собственный код.
Как результат, мы имеем вот такую вот кнопочку:
Да, да — Start Tests.
Поскольку у нас для одного сьюта тесткейсы есть для веб и мобайл, то на первой стадии мы проверяем по имени тестрана, какой именно фреймворк используется. В зависимости от того, для чего предназначен тестран, мы запускаем билд на TeamCity.
Дабы юзер не кликал слишком часто на кнопочку, у нас организована защита от дурака — после клика на кнопку мы добавляем ключевое «in progress» к имени тестрана, это блокирует волшебную кнопку, пока наши автотесты не закончат свое дело.
Automation Framework
На конечной стадии был создан гем/библиотека, которая при разворачивании дает нам интеграцию с TestRail на любом нашем под-проекте.
Создание гема — совсем другая история, достойная отдельной статьи.
Если вкратце, то наша библиотека test_rail_integration имеет небольшой функционал, который мы используем у себя, но мне кажется, что кому-то тоже может быть полезной.
Для начала нужно его установить:
В after |scenario| hooks. И в env.rb файл:
Вот команды для запуска:
В нашем случае тесты запускались для 6 различных локализаций и все результаты отображались в 1 тестране. Иногда возникала ситуация, когда два апдейта приходили в одно время. Получалось так, что они не видели друг друга и после фейла приходил пасс статус. Такой вариант менял общую картину статуса теста. В общем, эта команда проходит все тесты и проверяет в ней соответствие, что в зеленых тестах нет красных результатов. Если же есть — то меняет статус теста на красный.
Тут все просто, данной командой мы создаем тестран с указанным именем в проекте-сьюте, который мы записали в конфиг файле. Команда возвращает номер созданного тесана:
Нужно написать при первом запуске, так как данная команда генерирует конфигурационный файл, к котором нужно указать необходимую информацию о TestRail:
Это и есть core фунционал c флагами:
Тут и так все понятно, нужно указать номер тест рана:
и
Специфические атрибуты, которые будут использованы при составлении команды для запуска (если, к примеру, вам нужно запускать ваши тесты через специфическую команду, то в конфиг файле нужно записать ее с использованием этих переменных, тогда при запуске мы должны их указать):
Этот флаг тоже специфический и, думаю, никому больше не пригодится:
Здесь можно указать новую команду для текущего запуска:
Так как у нас используется вся интеграция для 6 локализаций, то по номеру тестрана мы ищем имя и парсим его на параметры так, что тестран должен иметь имя, допустим, DT SG staging. Здесь мы и находим необходимую информацию для запуска.
Запуск без поиска и проверки на наличие каких-либо параметров, это наиболее полезная команда для Вас, уважаемый читатель.
Можно определить также номер типа тестов, которые буду запущены.
Полная команда для запуска тестов с существующим тестраном будет выглядеть так:
TeamCity
Тут, собственно говоря, все просто. Просто записываем команду так же, как мы бы ее запускали локально, разве только можно добавить несколько переменных для удобства и скомбинировать порядок запуска команд (в случае, если мы запускаем билд автоматически, сначала нужно указать команду на создание тестрана, потом на запуск тестов с номером, который пришел нам ранее).
Вот и все. Так как это мой первый опыт с написанием статьи, критика приветствуется. Надеюсь, что написал я все это вполне понятно и данное руководство будет кому-либо полезно.