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

    Введение

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

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

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

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

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

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

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

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

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

      1. Smoke

      2. Regress

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

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

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

    Requirements

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

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

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

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

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

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

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

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

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

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

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

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

    TestScenario:

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

    TestCase:

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

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

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

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

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

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

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

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

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

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

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

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

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

    Поле "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 предложенные Романом Савиным методики. Для этого создадим поле со ссылкой на созданный файлик:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Создание TestRun

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

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

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

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

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

    Заключение

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

    Ссылки:

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

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

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

    Средняя зарплата в IT

    111 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 7 247 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 7

      0

      А это какой-то фреймворк для тестов или просто хранилище тестов и их результатов приходящие из других источников?

        –1
        Да, фреймворк. Тут их пишешь, запускаешь раны. Репорты по результатам ранов можно тут писать, но лучше в Jira. TestRail корреспондируется с Жирой и пробрасывает в обе стороны репорты.
          0
          Боюсь что правильный ответ на вопрос выше: TestRail — это хранилище текстового описания тестов и хранилище репортов. Да, результаты могут быть запушены автоматически через API, но сам по себе TestRail не умеет выполнять тесты, и не является тестовым фреймворком.
            0
            Спасибо большое, что оставили интересный комментарий. Возможно у нас с Вами разные требования с слову фреймворк в целом. Для меня слово framework это некий функционал позволяющий выполнять некую work и всё это в UI оболочке. (frame)
            Что же применительно к данным штукам, на мой взгляд, позволяет тестрейл из базового:
            1. Создавать и хранить тесткейсы
            2. Запускать по ним тестраны и асайнить их
            3. Проходить тестраны.
            4. Получать результат тестирования (та часть тестирования, которая про получение текущего статуса качества ПО)
            5. Создавать отчеты по пройденным тестранам.

            Простите меня пожалуйста, но я не смог понять, что Вы вложили во фразу: «TestRail не умеет выполнять тесты»? Можно Вас попросить описать более подробнее? Это может помочь развить тему в целом.
              0

              Jest, JUnit, PHPUnit — вот примеры тестовых фреймворков.


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

        +1

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

          0
          да, идеален только эксель, которого можно крутить вертеть на VBA абсолютно всё:)))
          Кстати, замый заметный недостаток для меня — это отсутствие показа изображений в тестах по внешним ссылкам. (что вдвойне странно, т.к. тестрейл работает из браузера) Чаще всего народ или хардкодит скриншоты внутри теста или вообще без изображений обходится. Оба варианта очень плохие:))

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое