🥇TestRail – Індывідуальныя наладкі пад праект

Увядзенне

У шматлікіх праектах, з якімі я працаваў, людзі не наладжвалі пад сябе TestRail і абыходзіліся стандартнымі наладамі. Таму ў дадзеным артыкуле я пастараюся апісаць прыклад індывідуальных налад, якія могуць дапамагчы Вам павысіць эфектыўнасць сваёй працы. Для прыкладу возьмем праект распрацоўкі мабільнага дадатку.

Невялікі дысклеймер. У дадзеным артыкуле няма апісання базавага функцыяналу TestRail (на гэта ёсць шмат гайдаў) і якія прадаюць выразаў маляўніча якія апісваюць чаму трэба абраць менавіта гэтага вендара для стварэння рэпазітара з тэстамі.

План-абгрунтаванне (што будзе рэалізавана)

агульныя патрабаванні
1. Кейс павінен прайсці абсалютна любы чалавек
2. Кейсы павінны захоўваць актуальнасць як мага даўжэй
3. Кейсы павінны максімальна старанна пакрываць функцыянал мабільнага прыкладання ў той меры, у якой гэта не супярэчыць першым двум пунктам.
Падзел на TestCase і TestScenario
Хуткае фарміраванне TestRun розных тыпаў
1. Дым
2. Рэгрэс
3. Impact тэсціраванне і г.д.
Аптымізацыя падтрымкі кейсаў
1. Адмова ад «мёртвых» захардскураных скрыншотаў і пераход на «movable data»

Патрабаванне

Для рэдагавання палёў Вам запатрабуецца адміністратарскі доступ

Выбар тыпу праекта

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

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

Даданне палёў для прагляду спісу тэст кейсаў

Дадамо поле для адлюстравання priority тэст кейсаў:

Таксама можна дадаць і іншыя палі.

Настройка палёў і тэгаў тэст кейса

Адкрываем меню наладкі:

Нам спатрэбяцца такія палі:

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

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

TestScenario:

Прыклад: TestScenario - Асноўны сцэнар выкарыстання мабільнага прыкладання

TestCase:

Прыклад: MainScreen - Раздзел аўтарызацыі - Увод лагіна

Разам мы бачым у summary кейса класічнае разуменне: "што, дзе, калі". Таксама візуальна мы падзяляем верхнеўзроўневыя тэставыя сцэнары і нізкаўзроўневыя тэст кейсы ў найбольш прыдатным для аўтаматызацыі выглядзе.

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

Для чаго можа спатрэбіцца: мы будзем выдаляць з тэксту тэкст кейсаў тыпавыя крокі якія прыводзяць карыстача на экран бягучага тэст кейса. (тыпавыя крокі для стварэння вызначанай тэставай сітуацыі) Усе тыпавыя крокі для ўсіх тэст кейсаў будуць прапісаны ў адным файліцы. Аб ім больш падрабязна напішу асобна.

Ствараем новае поле:

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

У дадзеным выпадку мы ствараем поле выбару са спісу значэнняў. Уводзім значэнні гэтага поля:

Звярніце ўвагу, што id значэнняў пачынаюцца не з адзінкі і ідуць не запар. Чаму так зроблена? Справа ў тым, што калі ў нас будуць запісаныя тесткейсы з уведзеным id,

і пасля гэтага нам спатрэбіцца стварыць трэці экран паміж двума існуючымі,

то нам давядзецца перапісаць id, і бо да яго ўжо прывязаныя тэгі існых тэкст кейсаў, то яны проста выдаляцца. Гэта будзе вельмі непрыемна.

Тэг "Screen" (назва экрана які закранае TestCase)

Для чаго можа спатрэбіцца: адзін з якароў для імпакт тэсціравання. Напрыклад, распрацоўшчыкі зрабілі новую крутую фічу. Нам трэба яе пратэставаць, але для гэтага трэба зразумець, што менавіта гэтая фіча магла закрануць. Па змаўчанні мы можа адштурхвацца ад парадыгмы, што розныя экраны (Activity) прыкладанні маюць розныя класы і такім чынам складаюць розныя кампаненты прыкладання. Вядома ж у дадзеным выпадку патрэбен індывідуальны падыход.

Прыклад: home_screen, MapScreen, PayScreen і г.д.

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

Далей мы пастараемся вырашыць праблему падтрымкі актуальнасці дадзеных у тэсткейсах:

Спасылкі на актуальныя макеты (гэта значна лепш, чым рабіць мёртвыя скрыншоты)
Тыпавыя крокі да экрана з тэставай сітуацыяй
SQL запыты
Спасылкі на вонкавыя дадзеныя і іншыя дадзеныя

Замест прапісвання тэставых дадзеных усярэдзіне кожнага тэст кейса мы створым адзін вонкавы файл, і на ўсіх тэст кейсах зробім спасылку на яго. Пры абнаўленні гэтых дадзеных нам не давядзецца перабіраць усе тэст кейсы і змяняць іх, а можна будзе змяніць гэтыя дадзеныя толькі ў адным месцы. Калі хтосьці непадрыхтаваны адкрые тэст кейс, ён убачыць у целе тэст кейса спасылку на файлік і падказку, што трэба ў яго ісці за тэставымі дадзенымі.

Усе гэтыя дадзеныя мы спакуем у адзін вонкавы файлік, які будзе даступны ўсім жадаючым на праекце. Напрыклад можна выкарыстоўваць Google Sheet або Excel і наладзіць усярэдзіне файла пошук. Чаму менавіта гэтыя вендары? Справа ў тым, што мы адштурхваемся ад парадыгмы, што адкрыць і прайсці тэст кейс павінен змагчы любы чалавек у камандзе без неабходнасці папярэдне ўсякія тулзы ўсталёўваць.

Для Google Sheet можна выкарыстоўваць SQL запыты. Прыклад:

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

Для Пераўзыходзіць можна наладзіць зручныя макрасы імгненнага пошуку. (фільтрацыі) Прыклад па спасылцы.

Уласна ідэя не новая і апісана ў першай кніжцы тэсціроўшчыка "Тэставанне 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» (аўтар Раман Савін)

Дзякуй вялікі за ўвагу!

Крыніца: habr.com

TestRail - Індывідуальныя наладкі пад праект