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

Въведение

В много проекти, с които съм работил, хората не настройваха TestRail по свои нужди и се задоволяваха със стандартните настройки. Затова в тази статия ще опиша пример за индивидуални настройки, които могат да помогнат да повишите ефективността на своята работа. За пример ще вземем проект за разработка на мобилно приложение.

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

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

1. Общи изисквания

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

   2. Кейсът трябва да поддържа актуалност колкото се може по-дълго

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

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

3. Бързо генериране на TestRun от различни типове

   1. Smoke

   2. Regress

   3. Impact тестиране и т.н.

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

   1. Отказ от „мъртви“ захардкодени скрийншотове и преминаване на „подвижни данни“

Изисквания

За редактиране на полета ще ви е необходимо администраторско достъп

Избор на тип проект

Можете да изберете три типа проект:

Ние ще изберем типа по подразбиране. В него ще бъдат достъпни всички кейсове едновременно. Ще използваме умна филтрация и динамично ще управляваме всички кейсове наведнъж.

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

Ще добавим поле за показване на приоритета на тестовите кейсове:

Можете също да добавите и други полета.

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

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

Ще ни трябват следните полета:

Поле „Summary“ (заглавие на тестовия кейс)

Това поле вече съществува, просто ще систематизираме неговото използване. Ще разделим кейсовете на TestCase и TestScenario. За по-добра четимост на дългия списък с кейсове е добре предварително да се договорим по регламента за написване на summary.

TestScenario:

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

TestCase:

Пример: MainScreen — Раздел за удостоверяване — Въведете логин

В крайна сметка виждаме в summary на кейса класическото разбиране: “какво, къде, кога”. Също така визуално разделяме по-високото ниво тестови сценарии и ниско ниво тестови кейсове в най-подходящата форма за автоматизация.

Таг «StartScreen» (екранът, от който започва TestScenario, също така много тестови случаи могат да засягат съседните екрани)

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

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

Попълваме компонентите на новото поле:

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

Обърнете внимание, че идентификаторите на стойностите не започват от единица и не вървят последователно. Защо е направено така? Дело е в това, че ако имаме записани тестови случаи с въведен идентификатор,

и след това ни е необходимо да създадем трети екран между два съществуващи,

то ще трябва да пренапишем идентификаторите, и тъй като вече са свързани с таговете на съществуващите тестови случаи, те просто ще се изтриват. Това ще бъде много неприятно.

Таг «Screen» (името на екрана, който засяга TestCase)

За какво може да е нужен: един от якорите за импат тестиране. Например, разработчиците създадоха нова готина функция. Трябва да я тестваме, но за това е необходимо да разберем какво точно е могла да засегне тази функция. По подразбиране може да се отталкваме от парадигмата, че различните екрани (Activity) на приложението имат различни класове и следователно съставят различни компоненти на приложението. Разбира се, в този случай е нужен индивидуален подход.

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

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

След това ще се опитаме да решим проблема с поддръжката на актуалността на данните в тестовите случаи:

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, Поръчки, Потребители, Карта, Авторизация и т.н.

Таг «TAG» (Други тагове за филтриране)

Тагиране на тест кейс с етикети за произволно филтриране. 

Много полезно за: 

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

2. дали тестовете ще бъдат автоматизирани или вече са автоматизирани

3. всеки друг етикет

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

Настройване на реда на показване на полетата в тест кейса

Създадохме много нови полета, време е да ги подредим в удобен ред:

Създаване на TestRun

Сега ще създадем нов тест рън с актуални кейсове за провеждане на smoke тестване с три клика:

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

1. Ако в TestRail има няколко проекта, не забравяйте да създавате нови полета само за Вашия проект, в противен случай колегите от съседните екипи ще бъдат много изненадани от появата на нови необичайни полета. Възможни са локални припадъци.

2. Кейс с голям брой полета е по-лесно да се копира от аналогична група, отколкото да се създават нови:

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

Заключение

По-гореописаните примери бяха внедрени в няколко проекта и показаха своята ефективност. Надявам се да помогнат за подобряване на разбирането Ви за този инструмент и да подпомогнат създаването на ефективни и удобни "тестохранилки". Ще бъда много благодарен, ако в коментарите опишете Вашия опит с използването на TestRail и полезни съвети.

Връзки:

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

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

Благодаря ви много за вниманието!

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