Kvar el kvin QA-kandidatoj volas lerni kiel labori kun aŭtomatigitaj testoj. Ne ĉiuj kompanioj povas plenumi tiajn dezirojn de manaj testistoj dum laborhoroj. Wrike tenis aŭtomatigan lernejon por dungitoj kaj realigis ĉi tiun deziron por multaj. Mi partoprenis en ĉi tiu lernejo ĝuste kiel studento de QA.
Mi lernis kiel labori kun Selenium kaj nun sendepende subtenas certan nombron da aŭtotestoj kun preskaŭ neniu ekstera helpo. Kaj, surbaze de la rezultoj de nia komuna sperto kaj miaj personaj konkludoj, mi provos derivi la formulon mem por la plej ideala lernejo de aŭtomatigo.
La sperto de Wrike pri organizado de lernejo
Kiam la bezono de aŭtomatiglernejo iĝis klara, ĝia organizo falis al Stas Davydov, la teknika gvido de aŭtomatigo. Kiu alia krom li povas klarigi kial ili elpensis ĉi tiun iniciaton, ĉu ili atingis rezultojn kaj ĉu ili bedaŭras la tempon pasigitan? Ni donu al li la parolon:
— En 2016, ni verkis novan kadron por aŭtotestoj kaj faris ĝin tiel, ke fariĝu facile verki testojn: aperis normalaj paŝoj, la strukturo fariĝis multe pli komprenebla. Ni elpensis ideon: ni devas impliki ĉiujn, kiuj volas verki novajn testojn, kaj por plifaciligi la komprenon, ni kreis serion da prelegoj. Ni kolektive elpensis planon de temoj, ĉiu el la estontaj prelegantoj prenis unu por si kaj preparis raporton pri ĝi.
— Kiajn malfacilaĵojn havis la studentoj?
— Ĉefe, kompreneble, arkitekturo. Estis multaj demandoj pri la strukturo de niaj testoj. En sugestoj, multe estis skribita pri ĉi tiu temo kaj ni devis okazigi pliajn prelegojn por klarigi pli detale.
— Ĉu la lernejo pagis?
- Jes, nepre. Danke al ŝi, multaj homoj okupiĝis pri verkado de testoj, kaj, averaĝe, en la hospitalo, ĉiuj komencis pli bone kompreni, kio estas aŭtotestoj, kiel ili estas skribitaj kaj kiel ili estas lanĉitaj. La ŝarĝo de aŭtomatigaj inĝenieroj ankaŭ malpliiĝis: ni nun ricevas multoble malpli da helpo-petoj pri analizado de testoj, ĉar testistoj kaj programistoj mem komencis trakti tion en preskaŭ ĉiuj situacioj. Nu, estas pluraj internaj avantaĝoj por la fako: ni akiris sperton en prezentoj kaj prelegoj, dank' al kiuj kelkaj aŭtomatigaj inĝenieroj jam sukcesis fari prezentojn en konferencoj, kaj ankaŭ ricevis potencan aron da videoj kaj prezentoj por enŝipiĝado de novuloj.
En mia propra nomo mi aldonos, ke komunikado inter niaj fakoj simpliĝis ĝis tute ridinde facila nivelo. Ekzemple, nun mi praktike ne bezonas pensi pri kiuj kazoj kaj je kia nivelo de atomeco aŭtomatigi. Kiel rezulto, ĉiuj interesitoj plene zorgas pri la testa kovrado, kiu konstante kreskas. Neniu postulas la neeblan de aliaj.
Ĝenerale, la efiko al la laboro de teamoj estas sendube pozitiva. Eble ankaŭ kolegoj, legantoj de ĉi tiu artikolo, pensas fari ion similan? Tiam la konsilo estos simpla: valoras, se aŭtomataj provoj estas prioritato por vi. Poste, ni parolos pri pli kompleksa demando: kiel organizi ĉion ĉi kiel eble plej ĝuste, tiel ke la kostoj de ĉiuj partioj estu minimumaj kaj la eligo estas maksimuma.
Organizi Konsiletojn
La lernejo estis utila, sed, kiel Staĉjo konfesis, estis kelkaj malfacilaĵoj, pro kiuj estis necese aranĝi pliajn prelegojn. Kaj estis kiel lastatempa studento komparante min-en-nescio kaj min-nun ke mi formulis la sekvajn paŝojn por krei, laŭ mi, la idealan manieron instrui testistojn kompreni aŭtomatigitajn testojn.
Paŝo 0. Kreu vortaron
Kompreneble, ĉi tiu paŝo estas bezonata ne nur por QA. Tamen mi volas klarigi ĝin: la aŭtomatiga kodbazo devas esti konservita en legebla formo. Programlingvoj - ne laste lingvoj, kaj de ĉi tio vi povas komenci vian plonĝon.
Jen ekrankopio de taskovido kun la nomoj de la elementoj. Ni imagu, ke vi provas taskrigardon kiel nigran skatolon kaj neniam vidis Selenumon en via vivo. Kion faras ĉi tiu kodo?
(Spoiler - la tasko estas forigita per ripozo nome de la administranto, kaj tiam ni vidas, ke estas registro pri tio en la fluo.)
Ĉi tiu paŝo sole proksimigas la QAA kaj QA-lingvojn. Estas pli facile por aŭtomatigaj teamoj klarigi la rezultojn de kuro; manaj testistoj devas elspezi malpli da penado por krei kazojn: ili povas esti malpli detalaj. Tamen ĉiuj komprenas unu la alian. Ni ricevis la gajnojn eĉ antaŭ ol la efektiva trejnado komenciĝis.
Paŝo 1. Ripetu frazojn
Ni daŭrigu la paralelon kun lingvo. Kiam ni lernas paroli kiel infanoj, ni ne komencas de etimologio kaj semantiko. Ni ripetas "panjo", "aĉetu ludilon", sed ne tuj eniru la prahindeŭropajn radikojn de ĉi tiuj vortoj. Do ĝi estas ĉi tie: ne utilas plonĝi en la profundon de la teknikaj trajtoj de aŭtotestoj sen provi skribi ion kiu funkcias.
Ĝi sonas iom kontraŭintuicia, sed ĝi funkcias.
En la unua leciono, indas doni bazon pri kiel rekte verki aŭtotestojn. Ni helpas starigi la evolumedion (en mia kazo, Intellij IDEA), klarigi la minimumajn lingvajn regulojn, kiuj estas necesaj por skribi alian metodon en ekzistanta klaso uzante la ekzistantajn paŝojn. Ni skribas kun ili unu aŭ du provojn kaj donas al ili hejmtaskon, kiujn mi formatus tiel: branĉo disbranĉiĝis de la majstro, sed pluraj testoj estis forigitaj de ĝi. Nur iliaj priskriboj restas. Ni petas testistojn restarigi ĉi tiujn testojn (ne per show diff, kompreneble).
Kiel rezulto, tiu, kiu aŭskultis kaj faris ĉion, povos:
- lernu labori kun la evolua medio-interfaco: kreante branĉojn, klavojn, komitaĵojn kaj puŝojn;
- majstri la bazojn de la strukturo de la lingvo kaj klasoj: kie enmeti injektojn kaj kie importi, kial komentarioj necesas, kaj kiaj simboloj troviĝas tie, krom paŝoj;
- kompreni la diferencon inter ago, atendi kaj kontroli, kie uzi kion;
- rimarku la diferencon inter aŭtotestoj kaj manaj kontroloj: en aŭtotestoj vi povas tiri unu aŭ alian pritraktilon anstataŭ fari agojn per la interfaco. Ekzemple, sendu komenton rekte al la backend anstataŭ malfermi taskovidon, elektante la enigon, tajpante tekston kaj klaki la Sendi butonon;
- formulu demandojn, kiuj estos responditaj en la sekva paŝo.
La lasta punkto estas tre grava. Ĉi tiuj respondoj povas esti facile donitaj antaŭtempe, sed estas grava instruprincipo, ke respondoj sen formulitaj demandoj ne estas memoritaj kaj ne estas uzataj kiam finfine bezonataj.
Estus ideale se en ĉi tiu tempo aŭtomatiga inĝeniero de la QA-teamo asignus al li taskon verki kelkajn provojn en batalo kaj permesus al li subengaĝiĝi al sia branĉo.
Kion ne doni:
- pli profunda kono de la funkcieco de la evolumedio kaj la programlingvo mem, kiuj nur estos bezonataj kiam oni laboras kun branĉoj sendepende. Ĝi ne estos memorita, vi devos klarigi ĝin dufoje aŭ trifoje, sed ni taksas la tempon de aŭtomatigaj inĝenieroj, ĉu ne? Ekzemploj: solvi konfliktojn, aldoni dosierojn al git, krei klasojn de nulo, labori kun dependecoj;
- ĉio rilata al xpath. Serioze. Vi devas paroli pri ĝi aparte, unufoje kaj tre koncentrite.
Paŝo 2. Pli detale rigardante la gramatikon
Ni memoru la taskovidan ekrankopion de paŝo #0. Ni havas paŝon nomatan checkCommentWithTextExists. Nia testilo jam komprenas, kion faras ĉi tiu paŝo kaj ni povas rigardi enen la paŝon kaj iom malkomponi ĝin.
Kaj interne ni havas la jenon:
onCommentBlock(userName).comment(expectedText).should(displayed());Kie estas surCommentBlock
onCommonStreamPanel().commentBlock(userName);Nun ni lernas diri ne "aĉetu ludilon", sed "aĉetu ludilon de la vendejo Detsky Mir, situanta en la blua kabineto sur la tria breto de la supro." Necesas klarigi, ke ni indikas elementon sinsekve, el pli grandaj elementoj (fluo -> bloko kun komentoj de certa persono -> tiu parto de tiu ĉi bloko kie sidas la specifita teksto).
Ne, ankoraŭ ne estas tempo por paroli pri xpath. Nur menciu mallonge, ke ĉiuj ĉi tiuj instrukcioj estas priskribitaj de ili kaj heredo trairas ilin. Sed ni devas paroli pri ĉiuj ĉi tiuj kunuloj kaj kelneroj; ili rilatas specife al ĉi tiu paŝo kaj estas necesaj por kompreni kio okazas. Sed ne troŝarĝu: via studento povas studi pli kompleksajn asertojn memstare poste. Plej verŝajne, devus, waitUntil, montrata ();, ekzisti ();, ne (); devus sufiĉi.
La hejmtasko estas evidenta: branĉo, en kiu la enhavo de pluraj paŝoj, kiuj estas necesaj por certa nombro da testoj, estis forigitaj. Lasu la testantojn restarigi ilin kaj fari la kuron denove verda.
Aldone, se la testteamo havas ne nur novajn funkciojn en sia laboro, sed ankaŭ kelkajn cimojn, vi povas peti lin tuj verki testojn por ĉi tiuj cimoj kaj liberigi ilin. Plej verŝajne, ĉiuj elementoj jam estas priskribitaj; nur kelkaj paŝoj eble mankas. Ĉi tio estos la perfekta trejnado.
Paŝo 3. Plena mergo
Kiel eble plej kompleta por testilo, kiu daŭre plenumos siajn rektajn devojn. Fine, ni devas paroli pri xpath.
Unue, ni klarigu, ke ĉiuj ĉi tiuj surCommentBlock kaj komento estas priskribitaj de ili.
Sumo:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"La ordo de la rakonto estas tre grava. Unue, ni prenas ajnan ekzistantan xpath kaj montras kiel la langeto de elementoj enhavas unu kaj nur unu elementon. Poste, ni parolos pri la strukturo: kiam vi bezonas uzi WebElement, kaj kiam vi devas krei apartan dosieron por nova elemento. Ĉi tio permesos al vi pli bone kompreni heredon.
Oni devas eksplicite konstati, ke ununura elemento estas la tuta taskovido, ĝi enhavas infanan elementon - la tutan fluon, kiu enhavas infanan elementon - apartan komenton ktp. Infanaj elementoj estas ene de gepatraj elementoj kaj sur la paĝo kaj en la strukturo de la aŭtotestkadro.
Je ĉi tiu punkto, la spektantaro devus firme kompreni kiel ili estas hereditaj kaj kio povas esti enigita post la punkto ĉe onCommentBlock. Je ĉi tiu punkto, ni klarigas ĉiujn operatorojn: /, //, ., [] ktp. Ni aldonas scion pri uzo en la ŝarĝon @class kaj aliaj necesaj aferoj.
Studentoj devus kompreni kiel traduki xpath tiamaniere. Por firmigi — ĝuste, hejmtasko. Ni forigas la priskribojn de la elementoj, lasu ilin restarigi la laboron de la testoj.
Kial ĉi tiu aparta vojo?
Ni ne superŝarĝu homon kun kompleksa scio, sed ni devas klarigi ĉion tuj, kaj ĉi tio estas malfacila dilemo. Ĉi tiu vojo permesos al ni unue igi aŭskultantojn demandi kaj ne kompreni ion kaj respondi ilin en la venonta momento. Se vi parolas pri la tuta arkitekturo, tiam kiam la temo de paŝoj aŭ xpath estos analizita, la plej gravaj partoj de ĝi jam estos forgesitaj pro ilia nekomprenebleco.
Tamen, iuj el vi verŝajne povos dividi vian sperton pri kiel la procezo povas esti optimumigita eĉ pli. Mi volonte legos similajn sugestojn en la komentoj!
fonto: www.habr.com