Чатыры з пяці суіскальнікаў-QA хочуць навучыцца працаваць з аўтатэстамі. Не ўсе кампаніі могуць ажыццявіць такія жаданні ручных тэсціроўшчыкаў у працоўны час. Wrike правёў школу аўтаматызацыі для супрацоўнікаў і рэалізаваў гэтае жаданне для многіх. Я ў гэтай школе ўдзельнічаў менавіта як вучань-QA.
Я навучыўся працы з Selenium і цяпер самастойна падтрымліваю пэўную колькасць аўтатэстаў практычна без дапамогі звонку. І, па выніках нашага сумеснага досведу і маіх асабістых высноваў, я пастараюся вывесці тую самую формулу як мага больш ідэальнай школы аўтаматызацыі.
Вопыт Wrike у арганізацыі школы
Калі неабходнасць у школе аўтаматызацыі стала зразумелай, яе арганізацыя легла на Стаса Давыдава, тэхнічнага ліда аўтаматызацыі. Хто як не ён можа растлумачыць, навошта прыдумалі гэтую ініцыятыву, ці дасягнулі вынікаў і ці не шкадуюць аб патрачаным часе? Дамо яму слова:
- У 2016 годзе мы напісалі новы фрэймворк для аўтатэстаў і зрабілі яго такім, што тэсты стала пісаць лёгка: з'явіліся нармальныя стэпы, структура стала ў разы больш зразумелай. У нас з'явілася ідэя: трэба прыцягнуць да напісання новых тэстаў усіх, хто пажадае, а каб прасцей было ўглыбіцца, стварылі серыю лекцый. Мы калектыўна прыдумалі план тэм, кожны з будучых лектараў узяў сабе адну і падрыхтаваў па ёй даклад.
- Якія былі складанасці ў вучняў?
- У асноўным, вядома, архітэктура. Было шмат пытанняў па структуры нашых тэстаў. У фідбэку шмат пісалі на гэтую тэму і нам прыйшлося праводзіць дадатковыя лекцыі, каб растлумачыць падрабязней.
- Ці акупілася школа?
- Так, адназначна. Дзякуючы ёй да напісання тэстаў прыцягнулі кучу людзей, і, у сярэднім па лякарні, усё сталі лепш разумець, што такое аўтатэсты, як іх пішуць і як яны запускаюцца. Таксама знізілася нагрузка на аўтаматызатараў: нам зараз паступае ў разы менш запытаў на дапамогу з разборам тэстаў, бо тэсціроўшчыкі і распрацоўшчыкі сталі з гэтым спраўляцца самі практычна ва ўсіх сітуацыях. Ну і некалькі ўнутраных плюсаў для аддзела: набылі досвед у прэзентацыях і лекцыях, дзякуючы чаму некаторыя аўтаматызатары ўжо паспелі зрабіць даклады на канферэнцыях, а таксама атрымалі магутны набор відэа і прэзентацый для онбордынгу пачаткоўцаў.
Ад сябе ж дадам, што камунікацыя паміж нашымі аддзеламі спрасцілася да проста-такі смяхотна лёгкага ўзроўню. Да прыкладу, мне зараз практычна не патрабуецца разважаць над тым, якія кейсы і з якім узроўнем атамарнасці аддаць на аўтаматызацыю. Як вынік, клопат аб тэставым пакрыцці, нястомна расце, ідзе ў поўнай меры з усіх зацікаўленых бакоў. Ніхто не патрабуе ад іншых немагчымага.
Увогуле, уплыў на працу каманд - адназначна станоўчае. Быць можа, калегі якія чытаюць гэты артыкул таксама задумляюцца аб правядзенні чагосьці падобнага? Тады рада будзе простай: яно таго варта, калі аўтатэсты для вас у прыярытэце. Далей пагаворым пра больш складанае пытанне: як гэта ўсё арганізаваць максімальна правільна, каб выдаткі ўсіх бакоў былі мінімальныя, а выхлап - максімальны.
Саветы па арганізацыі
Школа была карыснай, але, як прызнаў Стас, былі некаторыя складанасці, з-за якіх прыйшлося ладзіць дадатковыя лекцыі. І менавіта як які навучыўся нядаўні студэнт, які параўноўвае сябе-у-няведанні і сябе-зараз, я сфармуляваў наступныя крокі па стварэнні ідэальнага, па маім меркаванні, спосабу навучыць тэстыравальнікаў разбірацца з аўтатэстамі.
Крок 0. Ствараем слоўнік
Вядома, гэты крок патрэбен не толькі для QA. Тым не менш, я жадаю яго прагаварыць у відавочным выглядзе: кодавая база аўтаматызацыі павінна захоўвацца ў чытэльным выглядзе. Мовы праграмавання - не ў апошнюю чаргу менавіта мовы, і з гэтага можна будзе пачынаць апусканне.
Перад вамі скрыншот тасквью з назовамі элементаў. Прадстаўляльны, што вы займаецеся тэставаннем тасквью як чорнай скрыні і ў жыцці не бачылі Selenium. Што робіць гэты код?
(Спойлер - праз рэст выдаляецца таск ад імя адміна, а потым мы глядзім, што ў стрыме застаўся аб гэтым запіс.)
Ужо адзін гэты крок дазваляе зблізіць мовы QAA і QA. Аўтаматызатарам прасцей тлумачыць вынік прагону, ручным тэсціроўшчыкам даводзіцца марнаваць менш сіл на складанне кейсаў: іх можна рабіць менш падрабязнымі. Усё ж адзін аднаго разумеюць. Мы атрымалі выйгрыш яшчэ да таго, як пачалося непасрэдна навучанне.
Крок 1. Паўтараем фразы
Працягнем паралель з мовай. Калі мы вучымся казаць у дзіцячым узросце, мы не ідзем ад этымалогіі і семантыкі. Мы паўтараем «мама», «купі цацку», але не лезем адразу ў праіндаеўрапейскія карані гэтых слоў. Так і тут: няма сэнсу ныраць у самую глыбіню тэхнічных асаблівасцяў працы аўтатэстаў, не паспрабаваўшы напісаць нешта працоўнае.
Гучыць некалькі канрынтуітыўна, але затое працуе.
На першым занятку варта даць базіс па тым, як пісаць непасрэдна аўтатэсты. Дапамагаем наладзіць асяроддзе распрацоўкі (у маім выпадку – Intellij IDEA), тлумачым той мінімум правіл мовы, які неабходзен для напісання яшчэ аднаго метаду ў існым класе з выкарыстаннем наяўных крокаў. Пішам з імі адзін-два цесты і даем хатняе заданне, якое я б аформіў так: галінка, адведзеная ад майстра, але ў ёй выдалена некалькі тэстаў. Засталіся толькі іх апісанні. Просім тэсціроўшчыкаў аднавіць гэтыя тэсты (не праз show diff, вядома ж).
Па выніках той, хто ўсё паслухаў і зрабіў, зможа:
- навучыцца працаваць з інтэрфейсам асяроддзя распрацоўкі: стварэнне галінак, хоткеі, коміты і пушы;
- асвоіць асновы структуры мовы і класаў: куды ўстаўляць інжекты, а куды імпарты, навошта патрэбныя анатацыі і што ўвогуле там сустракаюцца за сімвалы, акрамя крокаў;
- зразумець розніцу паміж дзеяннем, чаканнем і праверкай, дзе што выкарыстоўваць;
- заўважыць адрозненне аўтатэстаў і ручных праверак: у аўтатэстах можна тузануць той ці іншы хендлер замест выканання дзеянняў праз інтэрфейс. Напрыклад, адправіць каментар напроста на бэкенд замест адкрыцця тасквью, вылучэнні инпута, набору тэксту і націску кнопкі Send;
- сфармуляваць пытанні, на якія будуць дадзены адказы на наступным кроку.
Апошні пункт вельмі важны. Гэтыя адказы лёгка можна даць загадзя, але гэта важны прынцып выкладання: адказы без сфармуляваных пытанняў не запамінаюцца і не прымяняюцца, калі, нарэшце, спатрэбяцца.
Ідэальна будзе, калі ў гэты час аўтаматызатар з каманды QA павесіць на яго задачу з напісаннем парачкі тэстаў на баі і дазволіць падкаміліцца ў сваю галінку.
Чаго даваць не варта:
- больш паглыбленыя веды функцыяналу асяроддзя распрацоўкі і самой мовы праграмавання, якія будуць патрэбныя толькі пры самастойнай працы з галінамі. Не запомніцца, давядзецца тлумачыць двойчы-тройчы, а мы шануем часам аўтаматызатараў, так? Прыклады: вырашэнне канфліктаў, даданне файлаў у гіт, стварэнне класаў з нуля, праца з залежнасцямі;
- усё, што злучана з xpath. Сур'ёзна. Пра яго трэба расказваць асобна, адзін раз і вельмі канцэнтравана.
Крок 2. Прыглядаемся да граматыкі
Давайце ўспомнім скрыншот з тасквью з кроку №0. У нас ёсць стэп з назвай checkCommentWithTextExists. Наш тэсціроўшчык ужо разумее, што гэты стэп робіць і можна зазірнуць унутр кроку і крыху яго дэкампазіраваць.
А ўнутры ў нас наступнае:
onCommentBlock(userName).comment(expectedText).should(displayed());Дзе onCommentBlock - гэта
onCommonStreamPanel().commentBlock(userName);Цяпер вучым казаць не «купі цацку», а «купі цацку з крамы Дзіцячы свет, якая стаіць у сіняй шафе на трэцяй паліцы зверху». Трэба растлумачыць, што мы паказваем на элемент паслядоўна, ад буйнейшых элементаў (стрым -> блок з каментарамі ад вызначанага чалавека -> тая частка гэтага блока, дзе сядзіць зададзены тэкст).
Не, усё яшчэ не час расказваць пра xpath. Толькі згадаць сцісла, што ўсе гэтыя ўказанні імі апісваюцца і ўспадкоўванне ідзе праз іх. Затое трэба расказаць пра ўсе гэтыя метчары і вейтэры, яны адносяцца менавіта да гэтага кроку і неабходныя для разумення таго, што адбываецца. Але не перагружайце: больш складаныя асёрты ваш студэнт зможа вывучыць сам і пазней. Хутчэй за ўсё, павінна хапіць should, waitUntil, displayed();, exist();, not();.
Хатняе заданне відавочна: галінка, у якой выдаленае змесціва некалькіх стэпаў, якія неабходны для некаторай колькасці тэстаў. Няхай тэсціроўшчыкі іх адновяць і прымусяць прагон быць зноў зялёным.
Дадаткова, калі ў каманды тэсціроўшчыка ў працы ёсць не толькі новыя фічы, але і некаторыя багфіксы, можна папрасіць яго напісаць адразу ж тэсты на гэтыя багі і зарэлізаваць. Хутчэй за ўсё, усе элементы ўжо апісаны, можа не хапаць толькі пары-тройкі стэпаў. Гэта будзе ідэальнай трэніроўкай.
Крок 3. Поўнае апусканне
Настолькі поўнае, наколькі гэта магчыма для тэсціроўшчыка, які збіраецца працягваць выконваць свае прамыя абавязкі. Нарэшце трэба расказаць пра xpath.
Спачатку даем зразумець, што ўсе гэтыя onCommentBlock і comment апісваюцца менавіта імі.
Разам:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"Парадак апавядання вельмі важны. Спачатку бярэм любы існуючы xpath і паказваем, як ва ўкладцы elements знаходзіцца адзін і толькі адзін элемент. Далей, расказваем пра структуру: калі трэба выкарыстоўваць WebElement, а калі трэба стварыць асобны файл для новага элемента. Гэта дазволіць лепш зразумець атрыманне ў спадчыну.
Трэба відавочна прагаварыць, што асобны элемент - гэта ўсё тасквью, ён змяшчае даччыны элемент - увесь стрым, які змяшчае даччыны элемент - асобны каментар, і г.д. Даччыныя элементы - усярэдзіне бацькоўскіх як на старонцы, так і ў структуры фрэймворка аўтатэстаў.
На гэтым моманце аўдыторыя павінна была ўжо цвёрда зразумець, як яны ўспадкоўваюцца і што можна ўвесці пасля кропкі ў onCommentBlock. У гэты момант тлумачым усе аператары: /, //, ., [] і іншае. У нагрузку дакідаем веды пра выкарыстанне @class і іншых неабходных рэчаў.
Слухачы павінны зразумець як перакладаць xpath падобнай выявай. Каб замацаваць - правільна, хатка. Выдаляем апісанні элементаў, няхай адновяць працу тэстаў.
Чаму менавіта такі шлях?
Мы не павінны перагрузіць чалавека складанымі ведамі, але павінны растлумачыць усё і адразу, а гэта няпростая дылема. Гэты шлях дазволіць нам спачатку прымусіць слухачоў задавацца пытаннямі і не разумець нешта і адказваць на іх ужо ў наступны момант. Калі расказаць пра ўсю архітэктуру, то да моманту разбору тэмы стэпаў ці xpath найважнейшыя часткі гэтай ужо забудуцца з-за сваёй незразумеласці.
Тым не менш, хтосьці з вас напэўна зможа падзяліцца досведам, як можна аптымізаваць працэс яшчэ мацней. З задавальненнем прачытаю ў каментарах падобныя прапановы!
Крыніца: habr.com