TestRail — Индивидуальные настройки под проект

Введение

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

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

План-обоснование (что будет реализовано)

  1. Общие требования

    1. Кейс должен смочь пройти абсолютно любой человек

    2. Кейсы должны сохранять актуальность как можно дольше

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

  2. Разделение на TestCase и TestScenario

  3. Быстрое формирование TestRun различных типов

    1. Smoke

    2. Regress

    3. Impact тестирование и т.д.

  4. Оптимизация поддержки кейсов

    1. Отказ от «мертвых» захардкоженных скриншотов и переход на «movable data»

Requirements

Для редактирования полей Вам потребуется администраторский доступ

Выбор типа проекта

Можно выбрать три типа проекта:

TestRail — Индивидуальные настройки под проект

Мы выберем тип по умолчанию. В нем будут доступны одновременно все кейсы. Мы будем пользоваться умной фильтрацией и динамически управлять всеми кейсами сразу.

Добавление полей для просмотра списка тест кейсов

Добавим поле для отображения priority тест кейсов:

TestRail — Индивидуальные настройки под проект

Также можно добавить и другие поля.

Настройка полей и тегов тест кейса

Открываем меню настройки:

TestRail — Индивидуальные настройки под проект

Нам потребуются такие поля:

Поле «Summary» (шапка тест кейса)

TestRail — Индивидуальные настройки под проект

Данное поле уже существует, мы только систематизируем его использование. Будем разделять кейсы на TestCase и TestScenario. Для лучшей читаемости большого списка кейсов лучше заранее договорится по регламенту написания summary.

TestScenario:

Пример: TestScenario — Основной сценарий использования мобильного приложения

TestCase:

Пример: MainScreen — Раздел авторизации — Ввод логина

Итого мы видим в summary кейса классическое понимание: “что, где, когда”. Также визуально мы разделяем верхнеуровневые тестовые сценарии и низкоуровневые тест кейсы в наиболее подходящем для автоматизации виде.

Тег «StartScreen» (экран с которого начинается TestScenario, также многие тест кейсы могут задевать соседние экраны)

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

Создаем новое поле:

TestRail — Индивидуальные настройки под проект

Заполняем компоненты нового поля:

TestRail — Индивидуальные настройки под проект

В данном случае мы создаем поле выбора из списка значений. Вводим значения этого поля:

TestRail — Индивидуальные настройки под проект

Обратите внимание, что id значений начинаются не с единицы и идут не подряд. Почему так сделано? Дело в том, что если у нас будут записаны тесткейсы с введенным id,

TestRail — Индивидуальные настройки под проект

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

TestRail — Индивидуальные настройки под проект

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

Тег «Screen» (наименование экрана который затрагивает TestCase)

Для чего может понадобится: один из якорей для импакт тестирования. Например, разработчики сделали новую крутую фичу. Нам нужно её протестировать, но для это нужно понять, что именно эта фича могла затронуть. По умолчанию мы может отталкиваться от парадигмы, что разные экраны (Activity) приложения имеют разные классы и следовательно составляют различные компоненты приложения. Конечно же в данном случае нужен индивидуальный подход.

Пример: home_screen, MapScreen, PayScreen и т.д.

TestRail — Индивидуальные настройки под проект

Поле «MovableData» (cсылка на прокси БД c изменяемыми тестовыми данными)

Далее мы постараемся решить проблему поддержки актуальности данных в тесткейсах:

  1. Ссылки на актуальные макеты (это гораздо лучше чем делать мертвые скриншоты)

  2. Типовые шаги до экрана с тестовой ситуацией

  3. SQL запросы

  4. Ссылки на внешние данные и прочие данные

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

Все эти данные мы упакуем в один внешний файлик, который будет доступен всем желающим на проекте. Например можно использовать Google Sheet или Excel и настроить внутри файла поиск. Почему именно эти вендоры? Дело в том, что мы отталкиваемся от парадигмы, что открыть и пройти тест кейс должен смочь любой человек в команде без необходимости предварительно всякие тулзы устанавливать.

Для Google Sheet можно использовать SQL запросы. Пример:

=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")

Для Excel можно настроить удобные макросы мгновенного поиска. (фильтрации) Пример по ссылке.

Собственно идея не нова и описана в первой книжке тестировщика “Тестирование dot com”. (автор Савин Роман) Мы лишь только интегрируем в TestRail предложенные Романом Савиным методики. Для этого создадим поле со ссылкой на созданный файлик:

TestRail — Индивидуальные настройки под проект

заполняем дефолтное значение ссылки, чтобы в каждом новом тест кейсе уже ссылка была:

TestRail — Индивидуальные настройки под проект

Если местоположение внешнего файла изменится (мы предусматриваем любой форс мажор) то можно удобно во всех тест кейсах сразу изменить одно или несколько полей:

TestRail — Индивидуальные настройки под проектTestRail — Индивидуальные настройки под проект

Поле “Descriptions” (описание или идея тест кейса, типовые инструкции)

Для чего может понадобится: В данное текстовое поле мы поместим краткое описание тест кейса и типовые инструкции.

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

TestRail — Индивидуальные настройки под проект

Тег «Component» (компонент мобильного приложения)

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

Пример компонентов: GooglePay, Order, Users, Map, Authorization и т.д.

TestRail — Индивидуальные настройки под проект

Тег «TAG» (Прочие теги для фильтрации)

Тегирование тест кейса метками для произвольной фильтрации. 

Очень полезно для: 

  1. быстрого составления TestRun для различных типовых задач: smoke, регресс и т.д.

  2. будут ли тесты автоматизированы или уже автоматизированы

  3. любые другие теги

Пример: Smoke, Automated, WhiteLabel, ForDelete и т.д.

TestRail — Индивидуальные настройки под проектTestRail — Индивидуальные настройки под проект

Настраиваем порядок отображения полей в тест кейсе

Мы создали много новый полей, пришло время расположить их в удобном порядке:

TestRail — Индивидуальные настройки под проект

Создание TestRun

Теперь мы создадим новый test run с актуальными кейсами для проведения smoke тестирования в три клика:

TestRail — Индивидуальные настройки под проект

Другие полезные советы

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

TestRail — Индивидуальные настройки под проект

2. Кейсы с большим количеством полей проще копировать из аналогичной группытипа чем создавать новые:

TestRail — Индивидуальные настройки под проект

3. Можно использовать учетные записи совместно. Например: одна администраторская, несколько пользовательских.

Заключение

Вышеописанные примеры были внедрены на несколько проектов и показали свою эффективность. Надеюсь они помогут улучшить Ваше понимание данной тулы и помогут создавать эффективные и удобные“тестохранилки”. Буду очень благодарен, если Вы в комментариях опишите Ваш опыт использования TestRail и полезные советы.

Ссылки:

Сайт вендора TestRail

Книга: «Тестирование .COM» (автор Роман Савин)

Спасибо большое за внимание!

Источник: habr.com

Добавить комментарий