Четири од пет кандидати за ОК сакаат да научат како да работат со автоматизирани тестови. Не сите компании можат да ги исполнат таквите желби на рачните тестери во текот на работното време. Wrike одржа училиште за автоматизација за вработените и ја реализираше оваа желба за многумина. Учествував во ова училиште токму како ученик за ОК.
Научив како да работам со Selenium и сега самостојно поддржувам одреден број автотестови практично без надворешна помош. И, врз основа на резултатите од нашето заедничко искуство и моите лични заклучоци, ќе се обидам да ја извлечам самата формула за најидеалното училиште за автоматизација.
Искуството на Wrike во организирање на училиште
Кога стана јасна потребата за училиште за автоматизација, нејзината организација падна на Стас Давидов, техничкиот лидер на автоматизацијата. Кој друг освен тој може да објасни зошто дошле до оваа иницијатива, дали постигнале резултати и дали жалат за потрошеното време? Ајде да му дадеме збор:
— Во 2016 година, напишавме нова рамка за автотестови и ја направивме така што стана лесно да се пишуваат тестови: се појавија нормални чекори, структурата стана многу поразбирлива. Дојдовме до идеја: треба да ги вклучиме сите што сакаат да пишуваат нови тестови, а за полесно да се разберат, создадовме серија предавања. Колективно смисливме план на теми, секој од идните предавачи си зеде по една и подготви извештај за тоа.
- Какви потешкотии имаа учениците?
— Главно, се разбира, архитектура. Имаше многу прашања за структурата на нашите тестови. Во фидбек, многу се пишуваше на оваа тема и моравме да одржиме дополнителни предавања за да објасниме подетално.
- Дали училиштето се исплатеше?
- Да дефинитивно. Благодарение на неа, многу луѓе беа вклучени во пишувањето тестови, а во просек, во болницата, сите почнаа подобро да разбираат што се автотестови, како се пишуваат и како се лансираат. Се намали и оптоварувањето на инженерите за автоматизација: сега добиваме многу пати помалку барања за помош при анализирање на тестовите, бидејќи тестерите и програмерите почнаа сами да се справуваат со ова во речиси сите ситуации. Па, има неколку внатрешни предности за одделот: стекнавме искуство во презентации и предавања, благодарение на што некои инженери за автоматизација веќе успеаја да направат презентации на конференции, а исто така добија моќен сет на видеа и презентации за влез на новодојденци.
Во мое лично име, ќе додадам дека комуникацијата помеѓу нашите одделенија е поедноставена на сосема смешно лесно ниво. На пример, сега практично не треба да размислувам за кои случаи и на кое ниво на атомност да се автоматизирам. Како резултат на тоа, сите заинтересирани страни целосно се грижат за покриеноста со тестовите, која постојано расте. Никој не го бара невозможното од другите.
Генерално, влијанието врз работата на тимовите е дефинитивно позитивно. Можеби колегите кои ја читаат оваа статија исто така размислуваат да направат нешто слично? Тогаш советот ќе биде едноставен: вреди ако автоматизираните тестови се приоритет за вас. Следно, ќе зборуваме за покомплексно прашање: како да се организира сето тоа што е можно поправилно, така што трошоците на сите страни се минимални, а резултатот е максимален.
Совети за организирање
Училиштето беше корисно, но, како што призна Стас, имаше некои тешкотии, поради што беше неопходно да се организираат дополнителни предавања. И, како неодамнешен студент кој се споредував себеси – во незнаење и себеси – сега ги формулирав следните чекори за да го создадам, според мое мислење, идеалниот начин да ги научам тестаторите да ги разбираат автоматските тестови.
Чекор 0. Направете речник
Се разбира, овој чекор е потребен не само за ОК. Сепак, сакам да кажам експлицитно: базата на кодови за автоматизација мора да се чува во читлива форма. Програмски јазици - не и најмалку важно јазици, и од ова можете да започнете со вашето нуркање.
Еве скриншот од приказ на задачи со имињата на елементите. Да замислиме дека го тестирате прегледот на задачи како црна кутија и никогаш не сте виделе селен во животот. Што прави овој код?
(Спојлер - задачата се брише преку одмор во име на администраторот, а потоа гледаме дека има запис за ова во стримот.)
Само овој чекор ги зближува јазиците QAA и QA заедно. На тимовите за автоматизација им е полесно да ги објаснат резултатите од трката; рачните тестери треба да трошат помалку напор за создавање куќишта: тие можат да бидат помалку детални. Сепак, сите се разбираат. Ги добивме добивките уште пред да започне вистинскиот тренинг.
Чекор 1. Повторете фрази
Да ја продолжиме паралелата со јазикот. Кога учиме да зборуваме како деца, не тргнуваме од етимологија и семантика. Повторуваме „мама“, „купи играчка“, но не влегувај веднаш во прото-индоевропските корени на овие зборови. Така е тука: нема смисла да се нурне во самите длабочини на техничките карактеристики на автотестовите без да се обиде да напише нешто што функционира.
Звучи малку контраинтуитивно, но функционира.
Во првата лекција, вреди да се даде основа за тоа како директно да се пишуваат автотестови. Ние помагаме да се постави развојната средина (во мојот случај, Intellij IDEA), да ги објасниме минималните јазични правила кои се неопходни за да се напише друг метод во постоечка класа користејќи ги постојните чекори. Со нив пишуваме еден или два теста и им даваме домашна задача, која би ја форматирал вака: гранка разгранета од мајсторот, но од неа се отстранети неколку тестови. Остануваат само нивните описи. Ги замолуваме тестерите да ги вратат овие тестови (се разбира, не преку приказ диф).
Како резултат на тоа, оној што слушаше и направи сè ќе може:
- научете да работите со интерфејсот на развојната средина: креирање гранки, копчиња, обврзници и турканици;
- совладајте ги основите на структурата на јазикот и часовите: каде да вметнете инјекции и каде да увезете, зошто се потребни прибелешки и какви симболи се наоѓаат таму, покрај чекорите;
- разберете ја разликата помеѓу дејството, почекајте и проверете, каде да користите што;
- забележете ја разликата помеѓу автоматските тестови и рачните проверки: во автоматските тестови можете да повлечете еден или друг управувач наместо да вршите дејства преку интерфејсот. На пример, испратете коментар директно до заднината наместо да отворите приказ на задачи, да го изберете внесувањето, да пишувате текст и да кликнете на копчето Испрати;
- формулирајте прашања кои ќе бидат одговорени во следниот чекор.
Последната точка е многу важна. Овие одговори може лесно да се дадат пред време, но важен наставен принцип е дека одговорите без формулирани прашања не се паметат и не се користат кога конечно е потребно.
Би било идеално ако во тоа време инженер за автоматизација од тимот за QA му додели задача да напише неколку тестови во битка и му дозволи да се потположи на неговата гранка.
Што да не се даде:
- подлабоко познавање на функционалноста на развојната средина и самиот програмски јазик, што ќе биде потребно само кога се работи самостојно со гранки. Нема да се памети, ќе мора да го објасните двапати или трипати, но ние го цениме времето на инженерите за автоматизација, нели? Примери: решавање конфликти, додавање датотеки во git, создавање класи од нула, работа со зависности;
- се што е поврзано со xpath. Сериозно. Треба да зборувате за тоа посебно, еднаш и многу концентрирано.
Чекор 2. Поблиски поглед на граматиката
Да се потсетиме на скриншот на приказот на задачи од чекор #0. Имаме чекор наречен checkCommentWithTextExists. Нашиот тестер веќе разбира што прави овој чекор и можеме да погледнеме внатре во чекорот и малку да го разложиме.
А внатре го имаме следново:
onCommentBlock(userName).comment(expectedText).should(displayed());Каде е onCommentBlock
onCommonStreamPanel().commentBlock(userName);Сега учиме да кажеме не „купи играчка“, туку „купи играчка од продавницата Детски Мир, сместена во синиот кабинет на третата полица одозгора“. Неопходно е да се објасни дека посочуваме на елемент последователно, од поголеми елементи (stream -> блок со коментари од одредено лице -> оној дел од овој блок каде што седи наведениот текст).
Не, сè уште не е време да зборуваме за xpath. Само накратко спомнете дека сите овие упатства се опишани од нив и наследството оди преку нив. Но, ние треба да зборуваме за сите овие натпреварувачи и келнери; тие се однесуваат конкретно на овој чекор и се неопходни за да се разбере што се случува. Но, не преоптоварувајте: вашиот студент подоцна може сам да проучува посложени тврдења. Најверојатно, треба, чекам, прикажано();, постои();, не(); треба да биде доволно.
Домашната задача е очигледна: гранка во која се отстранети содржините од неколку чекори кои се неопходни за одреден број тестови. Нека тестерите ги обноват и нека трчањето биде повторно зелено.
Дополнително, ако тимот за тестирање има не само нови функции во својата работа, туку и некои поправени грешки, можете да побарате од него веднаш да напише тестови за овие грешки и да ги ослободи. Најверојатно, сите елементи се веќе опишани; може да недостасуваат само неколку чекори. Ова ќе биде совршен тренинг.
Чекор 3. Целосно потопување
Што е можно поцелосно за тестер кој ќе продолжи да ги извршува своите директни должности. Конечно, треба да зборуваме за xpath.
Прво, да разјасниме дека сите овие onCommentBlock и коментари се опишани од нив.
Вкупно:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"Редоследот на приказната е многу важен. Прво, земаме која било постоечка xpath и покажуваме како јазичето елементи содржи еден и само еден елемент. Следно, ќе зборуваме за структурата: кога треба да користите WebElement и кога треба да креирате посебна датотека за нов елемент. Ова ќе ви овозможи подобро да го разберете наследството.
Мора експлицитно да се наведе дека еден елемент е целиот приказ на задачи, тој содржи дете елемент - целиот пренос, кој содржи дете елемент - посебен коментар итн. Детските елементи се во родителските елементи и на страницата и во структурата на рамката за автотест.
Во овој момент, публиката требаше цврсто да разбере како тие се наследени и што може да се внесе по точката на onCommentBlock. Во овој момент, ги објаснуваме сите оператори: /, //, ., [] и така натаму. Додаваме знаење за употреба во товарот @class и други неопходни работи.
Студентите треба да разберат како да го преведат xpath на овој начин. Да се консолидира - така е, домашна задача. Ги бришеме описите на елементите, нека ја вратат работата на тестовите.
Зошто токму овој пат?
Не треба да преоптоваруваме човек со сложени знаења, туку мора да објасниме сè одеднаш, а тоа е тешка дилема. Овој пат ќе ни овозможи прво да ги натераме слушателите да поставуваат прашања и да не разберат нешто и да одговориме на нив веќе следниот момент. Ако зборувате за целата архитектура, тогаш додека да се анализира темата чекори или xpath, најважните делови од неа веќе ќе бидат заборавени поради нивната неразбирливост.
Сепак, некои од вас веројатно ќе можат да го споделат своето искуство за тоа како процесот може уште повеќе да се оптимизира. Со задоволство ќе прочитам слични предлози во коментарите!
Извор: www.habr.com