Введение
Во многих проектах, с которыми я работал, люди не настраивали под себя TestRail и обходились стандартными настройками. Поэтому в данной статье я постараюсь описать пример индивидуальных настроек, которые могут помочь Вам повысить эффективность своей работы. Для примера возьмем проект разработки мобильного приложения.
Небольшой дисклеймер. В данной статье нет описания базового функционала TestRail (на это есть много гайдов) и продающих выражений красочно описывающих почему нужно выбрать именно этого вендора для создания репозитория с тестами.
План-обоснование (что будет реализовано)
Общие требования
Кейс должен смочь пройти абсолютно любой человек
Кейсы должны сохранять актуальность как можно дольше
Кейсы должны максимально тщательно покрывать функционал мобильного приложения в той мере, в которой это не противоречит первым двум пунктам
Разделение на TestCase и TestScenario
Быстрое формирование TestRun различных типов
Smoke
Regress
Impact тестирование и т.д.
Оптимизация поддержки кейсов
Отказ от «мертвых» захардкоженных скриншотов и переход на «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 изменяемыми тестовыми данными)
Далее мы постараемся решить проблему поддержки актуальности данных в тесткейсах:
Ссылки на актуальные макеты (это гораздо лучше чем делать мертвые скриншоты)
Типовые шаги до экрана с тестовой ситуацией
SQL запросы
Ссылки на внешние данные и прочие данные
Вместо прописывания тестовых данных внутри каждого тест кейса мы создадим один внешний файл, и на всех тест кейсах сделаем ссылку на него. При обновлении этих данных нам не придется перебирать все тест кейсы и изменять их, а можно будет изменить эти данные только в одном месте. Если кто-то неподготовленный откроет тест кейс, он увидит в теле тест кейса ссылку на файлик и подсказку, что нужно в него идти за тестовыми данными.
Все эти данные мы упакуем в один внешний файлик, который будет доступен всем желающим на проекте. Например можно использовать 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" (Прочие теги для фильтрации)
Тегирование тест кейса метками для произвольной фильтрации.
Очень полезно для:
быстрого составления TestRun для различных типовых задач: smoke, регресс и т.д.
будут ли тесты автоматизированы или уже автоматизированы
любые другие теги
Пример: Smoke, Automated, WhiteLabel, ForDelete и т.д.
Настраиваем порядок отображения полей в тест кейсе
Мы создали много новый полей, пришло время расположить их в удобном порядке:
Создание TestRun
Теперь мы создадим новый test run с актуальными кейсами для проведения smoke тестирования в три клика:
Другие полезные советы
Если в TestRail несколько проектов, то не забывайте создавать новые поля только под Ваш проект иначе коллеги из соседних комманд очень сильно удивятся появлению новых необычных полей. Возможны локальные обмороки.
2. Кейсы с большим количеством полей проще копировать из аналогичной группы\типа чем создавать новые:
3. Можно использовать учетные записи совместно. Например: одна администраторская, несколько пользовательских.
Заключение
Вышеописанные примеры были внедрены на несколько проектов и показали свою эффективность. Надеюсь они помогут улучшить Ваше понимание данной тулы и помогут создавать эффективные и удобные“тестохранилки”. Буду очень благодарен, если Вы в комментариях опишите Ваш опыт использования TestRail и полезные советы.
Ссылки:
Сайт вендора TestRail
Книга: "Тестирование .COM" (автор Роман Савин)
Спасибо большое за внимание!
