Обратно на училище: как да обучим ръчни тестери да се справят с автоматизирани тестове

Четирима от петима кандидати за QA искат да се научат как да работят с автоматизирани тестове. Не всички компании могат да изпълнят такива желания на ръчни тестери в работно време. Wrike проведе училище по автоматизация за служители и реализира това желание на много хора. Участвах в това училище именно като QA студент.

Научих как да работя със Selenium и сега независимо поддържам определен брой автотестове без практически никаква външна помощ. И въз основа на резултатите от нашия съвместен опит и моите лични заключения ще се опитам да изведа самата формула за най-идеалното училище за автоматизация.

Опитът на Wrike в организирането на училище

Когато необходимостта от училище по автоматизация стана ясна, организацията му падна на Стас Давидов, техническият ръководител на автоматизацията. Кой друг освен него може да обясни защо са се захванали с тази инициатива, постигнали ли са резултати и съжаляват ли за отделеното време? Нека му дадем думата:

— През 2016 г. написахме нова рамка за автотестове и направихме така, че да стане лесно да се пишат тестове: появиха се нормални стъпки, структурата стана много по-разбираема. Хрумна ни идея: трябва да включим всички, които искат да пишат нови тестове, и за по-лесно разбиране създадохме поредица от лекции. Колективно измислихме план от теми, всеки от бъдещите лектори си взе една за себе си и подготви доклад по нея.

— Какви трудности имаха учениците?

— Основно, разбира се, архитектура. Имаше много въпроси относно структурата на нашите тестове. В обратната връзка беше писано много по тази тема и се наложи да проведем допълнителни лекции, за да обясним по-подробно.

— Училището изплати ли се?

- Да, определено. Благодарение на нея много хора бяха включени в писането на тестове и средно в болницата всички започнаха да разбират по-добре какво представляват автотестовете, как се пишат и как се стартират. Натоварването върху инженерите по автоматизация също намаля: сега получаваме многократно по-малко искания за помощ при анализиране на тестове, тъй като тестерите и разработчиците започнаха да се справят сами с това в почти всички ситуации. Е, има няколко вътрешни предимства за отдела: натрупахме опит в презентации и лекции, благодарение на които някои инженери по автоматизация вече успяха да направят презентации на конференции, а също така получихме мощен набор от видеоклипове и презентации за новодошлите.

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

Като цяло влиянието върху работата на екипите определено е положително. Може би колегите, които четат тази статия, също мислят да направят нещо подобно? Тогава съветът ще бъде прост: струва си, ако автоматизираните тестове са приоритет за вас. След това ще говорим за по-сложен въпрос: как да организираме всичко това възможно най-правилно, така че разходите на всички страни да са минимални и продукцията да е максимална.

Съвети за организиране

Училището беше полезно, но, както призна Стас, имаше някои трудности, поради които беше необходимо да се организират допълнителни лекции. И като скорошен студент, който сравняваше себе си-в-невежество и себе си-сега, аз формулирах следните стъпки, за да създам, по мое мнение, идеалния начин да научим тестерите да разбират автоматизираните тестове.

Стъпка 0. Създайте речник

Разбира се, тази стъпка е необходима не само за QA. Искам обаче да го направя изрично: кодовата база за автоматизация трябва да се поддържа в четима форма. Програмни езици - не на последно място езици, и от това можете да започнете гмуркането си.

Ето екранна снимка на изглед на задача с имената на елементите. Нека си представим, че тествате taskview като черна кутия и никога не сте виждали Selenium през живота си. Какво прави този код?

(Спойлер - задачата се изтрива чрез почивка от името на администратора и след това виждаме, че има запис за това в потока.)

Само тази стъпка сближава езиците QAA и QA. За екипите по автоматизация е по-лесно да обяснят резултатите от изпълнение; ръчните тестери трябва да изразходват по-малко усилия за създаване на случаи: те могат да бъдат направени по-малко подробни. Все пак всички се разбират. Получихме печалбите още преди да започне същинското обучение.

Стъпка 1. Повторете фрази

Да продължим паралела с езика. Когато се учим да говорим като деца, ние не изхождаме от етимологията и семантиката. Повтаряме „мама“, „купи играчка“, но не навлизаме веднага в протоиндоевропейските корени на тези думи. Така е и тук: няма смисъл да се гмуркате в самите дълбини на техническите характеристики на автотестовете, без да се опитате да напишете нещо, което работи.
Звучи малко неинтуитивно, но работи.

В първия урок си струва да дадете основа за това как да пишете автотестове директно. Ние помагаме при настройването на средата за разработка (в моя случай Intellij IDEA), обясняваме минималните езикови правила, които са необходими за написването на друг метод в съществуващ клас, използвайки съществуващите стъпки. Пишем една-две контролни с тях и им даваме домашна работа, която аз бих оформил така: клонче, разклонено от майстора, но няколко теста са премахнати от него. Остават само техните описания. Молим тестерите да възстановят тези тестове (разбира се, не чрез show diff).

В резултат на това този, който слушаше и направи всичко, ще може:

1. научете се да работите с интерфейса на средата за разработка: създаване на разклонения, бързи клавиши, ангажименти и натискания;
2. овладейте основите на структурата на езика и класовете: къде да вмъкнете инжекции и къде да импортирате, защо са необходими анотации и какви символи се намират там, освен стъпките;
3. разберете разликата между действие, изчакване и проверка, къде какво да използвате;
4. забележете разликата между автоматичните тестове и ръчните проверки: при автоматичните тестове можете да изтеглите един или друг манипулатор, вместо да извършвате действия през интерфейса. Например, изпратете коментар директно до бекенда, вместо да отваряте изглед на задача, да избирате входа, да въвеждате текст и да щракнете върху бутона Изпрати;
5. формулирайте въпроси, на които ще получите отговор в следващата стъпка.

Последната точка е много важна. Тези отговори могат лесно да бъдат дадени предварително, но е важен принцип на преподаване, че отговорите без формулирани въпроси не се запомнят и не се използват, когато най-накрая са необходими.

Би било идеално, ако по това време инженер по автоматизация от QA екипа му възложи задача да напише няколко теста в битка и да му позволи да се ангажира с подразделението си.

Какво не трябва да давате:

1. по-задълбочени познания за функционалността на средата за разработка и самия език за програмиране, които ще са необходими само при самостоятелна работа с клонове. Няма да бъде запомнено, ще трябва да го обяснявате два или три пъти, но ние ценим времето на инженерите по автоматизация, нали? Примери: разрешаване на конфликти, добавяне на файлове към git, създаване на класове от нулата, работа със зависимости;
2. всичко свързано с xpath. Сериозно. Трябва да говорите за това отделно, веднъж и много концентрирано.

Стъпка 2. Погледнете по-отблизо граматиката

Нека си спомним екранната снимка на taskview от стъпка #0. Имаме стъпка, наречена checkCommentWithTextExists. Нашият тестер вече разбира какво прави тази стъпка и можем да погледнем вътре в стъпката и да я разложим малко.

А вътре имаме следното:

onCommentBlock(userName).comment(expectedText).should(displayed());

Където е onCommentBlock

onCommonStreamPanel().commentBlock(userName);

Сега се научаваме да казваме не „купете играчка“, а „купете играчка от магазина „Детски мир“, разположен в синия шкаф на третия рафт отгоре“. Необходимо е да се обясни, че посочваме елемент последователно, от по-големи елементи (поток -> блок с коментари от определено лице -> тази част от този блок, където се намира посоченият текст).

Не, все още не е време да говорим за xpath. Просто споменете накратко, че всички тези инструкции са описани от тях и наследяването минава през тях. Но трябва да говорим за всички тези мачове и сервитьори; те се отнасят конкретно за тази стъпка и са необходими, за да разберем какво се случва. Но не претоварвайте: вашият ученик може да изучава по-сложни твърдения сам по-късно. Най-вероятно трябва, waitUntil, displayed();, exist();, not(); трябва да е достатъчно.

Домашното е очевидно: клон, в който е премахнато съдържанието на няколко стъпки, необходими за определен брой тестове. Оставете тестерите да ги възстановят и да направят цикъла отново зелен.

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

Стъпка 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