Testrail - Индивидуальные Настройки Проекта

Введение Во многих проектах, с которыми я работал, люди не настраивали TestRail под себя и обходились стандартными настройками.

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

Например, возьмем проект разработки мобильного приложения.

Небольшая оговорка.

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

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

1. Общие требования
   1. Сдать кейс сможет абсолютно каждый.

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

2. Разделить на TestCase и TestScenario.
3. Быстрая генерация TestRun различных типов
   1. Дым
   2. Регресс
   3. Ударные испытания и т. д.
4. Оптимизация поддержки обращений
   1. Отказ от «мертвых» жестко закодированных скриншотов и переход на «подвижные данные»

Требования

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

В нем будут доступны все дела одновременно.

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

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

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

Поле «Сводка» (заголовок тестового примера)

Мы разделим кейсы на TestCase и TestScenario. Для лучшей читаемости большого списка дел лучше заранее договориться о правилах написания резюме.

Тестовый сценарий: Пример: Тестовый сценарий - Основной сценарий использования мобильного приложения Прецедент: Пример: Главный экран - Раздел авторизации - Вход в систему В целом мы видим в кратком изложении дела классическое понимание: «что, где, когда».

Также мы визуально разделяем высокоуровневые тестовые сценарии и низкоуровневые тест-кейсы в наиболее удобной для автоматизации форме.

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

(типовые шаги по созданию конкретной тестовой ситуации) Все типовые шаги для всех тест-кейсов будут записаны в один файл.

Об этом подробнее напишу отдельно.

Создайте новое поле:



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



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

Введите значения этого поля:



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



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



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

Это будет очень неприятно.

Тег «Экран» (имя экрана, влияющего на TestCase)

Например, разработчики сделали новую крутую функцию.

Нам нужно ее протестировать, но для этого нужно понять, на что именно может повлиять эта функция.

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

Конечно, в этом случае нужен индивидуальный подход. Пример: home_screen, MapScreen, PayScreen и т. д.

Поле «MovableData» (ссылка на прокси-базу с изменяемыми тестовыми данными)

1. Ссылки на текущие макеты (это намного лучше, чем делать мертвые скриншоты)
2. Типичные шаги для выхода на экран с тестовой ситуацией
3. SQL-запросы
4. Ссылки на внешние данные и другие данные

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

Если кто-то неподготовленный откроет тест-кейс, он увидит в теле тест-кейса ссылку на файл и подсказку, что ему нужно перейти к нему за тестовыми данными.

Все эти данные мы упакуем в один внешний файл, который будет доступен всем участникам проекта.

Например, вы можете использовать Google Sheet или Excel и настроить поиск по файлу.

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

Для Google Таблицы вы можете использовать SQL-запросы.

Пример:

   

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

   

(фильтрация) Пример связь .

Собственно, идея не нова и описана в книге первого тестировщика «Тестирование дот ком».

(автор Савин Роман) Мы просто интегрируем методы, предложенные Романом Савиным, в TestRail. Для этого создайте поле со ссылкой на созданный файл:



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



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

Поле «Описания» (описание или идея тест-кейса, стандартные инструкции)

Пример: Все тестовые данные (текущие макеты, использование инструментов и другие данные) из этого тестового примера обозначены ссылками {.

} и расположены в файле MovableData. Ссылка на MovableData в соответствующем поле вверху.

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

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

общий регресс всего.

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

Примеры компонентов: GooglePay, Заказ, Пользователи, Карта, Авторизация и т. д.

Тег «TAG» (Другие теги для фильтрации)

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

1. быстрая компиляция TestRun для различных типовых задач: дым, регрессия и т.д.
2. тесты будут автоматизированы или уже автоматизированы?
3. любые другие теги

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

Создание TestRun

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

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

   Возможен локальный обморок.

Например: один администратор, несколько пользователей.

Заключение

Надеюсь, они помогут улучшить ваше понимание этого инструмента и помогут создать эффективные и удобные «тестовые хранилища».

Буду очень признателен, если вы опишете в комментариях свой опыт использования TestRail и полезные советы.

Ссылки: Веб-сайт поставщика TestRail Книга: «Тестирование .

COM» (автор Роман Савин) Большое спасибо за ваше внимание! Теги: #DevOps #qa #тестирование ИТ-систем #тестирование #sql #testrail

• Как Выбрать Лучшую Компанию По Веб-Разработке И Дизайну

  19 Oct, 24

• Курсы Дистанционного Обучения: Хороший Источник Дохода

  19 Oct, 24

• Htc И Lg Впервые Отказались От Поставок Флагманов В Россию В Пользу Более Дешевых Моделей

  19 Oct, 24

• Uber В Петербурге Отменил Бесплатное Ожидание Для Пассажиров

  19 Oct, 24

• «Ростелеком» Модернизирует Сети И Дата-Центры На 60 Млрд Рублей

  19 Oct, 24

• Программа Конференции Лаборатории Нейродата И Ниу Итмо По Emotion Ai, Санкт-Петербург, 30 Марта

  19 Oct, 24

• Борьба С Ленью Или Проблема Задержки Вознаграждения.

  19 Oct, 24

• Пять Инноваций Crm, Которые Вы Увидите В 2018 Году

  19 Oct, 24

• Очень Странно

  19 Oct, 24

• Написание Простого Анализатора Кода В Roslyn

  19 Oct, 24