Patru din cinci solicitanți QA doresc să învețe cum să lucreze cu teste automate. Nu toate companiile pot îndeplini astfel de dorințe ale testerilor manuale în timpul orelor de lucru. Wrike a organizat o școală de automatizare pentru angajați și a realizat această dorință pentru mulți. Am participat la această școală tocmai ca student QA.
Am învățat cum să lucrez cu Selenium și acum suport independent un anumit număr de autotestări, practic fără ajutor din exterior. Și, pe baza rezultatelor experienței noastre comune și a concluziilor mele personale, voi încerca să deduc însăși formula pentru cea mai ideală școală de automatizare.
Experiența lui Wrike în organizarea unei școli
Când necesitatea unei școli de automatizare a devenit clară, organizarea acesteia a revenit lui Stas Davydov, liderul tehnic al automatizării. Cine altcineva decât el poate explica de ce au venit cu această inițiativă, dacă au obținut rezultate și dacă regretă timpul petrecut? Să-i dăm cuvântul:
— În 2016, am scris un nou cadru pentru autotestări și l-am făcut astfel încât să devină ușor de scris teste: au apărut pași normali, structura a devenit mult mai ușor de înțeles. Ne-a venit o idee: trebuie să implicăm pe toți cei care doresc să scrie noi teste și, pentru a fi mai ușor de înțeles, am creat o serie de prelegeri. Am venit împreună cu un plan de subiecte, fiecare dintre viitorii lectori și-a luat unul și a pregătit un raport despre acesta.
— Ce dificultăți au avut elevii?
— În principal, desigur, arhitectură. Au fost multe întrebări despre structura testelor noastre. În feedback, s-au scris multe despre acest subiect și a trebuit să ținem prelegeri suplimentare pentru a explica mai detaliat.
— Şcoala a dat roade?
- Da cu siguranta. Datorită ei, o mulțime de oameni au fost implicați în scrierea testelor și, în medie, în spital, toată lumea a început să înțeleagă mai bine ce sunt autotestele, cum sunt scrise și cum sunt lansate. Încărcarea inginerilor de automatizare a scăzut și ea: acum primim de multe ori mai puține solicitări de ajutor pentru analizarea testelor, deoarece testerii și dezvoltatorii au început să facă față ei înșiși în aproape toate situațiile. Ei bine, există mai multe avantaje interne pentru departament: am câștigat experiență în prezentări și prelegeri, datorită căreia unii ingineri de automatizare au reușit deja să facă prezentări la conferințe și au primit, de asemenea, un set puternic de videoclipuri și prezentări pentru integrarea noilor veniți.
În numele meu, voi adăuga că comunicarea între departamentele noastre a fost simplificată la un nivel de-a dreptul ridicol de ușor. De exemplu, acum practic nu trebuie să mă gândesc la ce cazuri și la ce nivel de atomicitate să automatizez. Drept urmare, toate părțile interesate au grijă de acoperirea testelor, care este în continuă creștere. Nimeni nu cere imposibilul de la alții.
În general, impactul asupra muncii echipelor este cu siguranță pozitiv. Poate că și colegii care citesc acest articol se gândesc să facă ceva similar? Atunci sfatul va fi simplu: merită dacă testele automate sunt o prioritate pentru tine. În continuare, vom vorbi despre o întrebare mai complexă: cum să organizați toate acestea cât mai corect posibil, astfel încât costurile tuturor părților să fie minime și producția să fie maximă.
Sfaturi de organizare
Școala a fost utilă, dar, după cum a recunoscut Stas, au existat unele dificultăți, din cauza cărora a fost necesar să se organizeze prelegeri suplimentare. Și în calitate de student recent comparându-mă cu mine însumi, în ignoranță, am formulat următorii pași pentru a crea, în opinia mea, modalitatea ideală de a-i învăța pe testeri să înțeleagă testele automate.
Pasul 0. Creați un dicționar
Desigur, acest pas este necesar nu numai pentru QA. Cu toate acestea, vreau să explic: baza de cod de automatizare trebuie păstrată într-o formă care poate fi citită. Limbaje de programare - nu în ultimul rând limbi, și de aici vă puteți începe scufundarea.
Iată o captură de ecran a unei vizualizări de activități cu numele elementelor. Să ne imaginăm că testezi taskview ca o cutie neagră și nu ai văzut niciodată seleniul în viața ta. Ce face acest cod?
(Spoiler - sarcina este ștearsă prin rest din partea administratorului, iar apoi vedem că există o înregistrare a acestui lucru în flux.)
Numai acest pas aduce limbile QAA și QA mai aproape. Este mai ușor pentru echipele de automatizare să explice rezultatele unei rulări; testerii manuali trebuie să depună mai puțin efort pentru crearea cazurilor: acestea pot fi mai puțin detaliate. Totuși, toată lumea se înțelege. Am primit câștigurile chiar înainte de a începe antrenamentul propriu-zis.
Pasul 1. Repetați fraze
Să continuăm paralela cu limbajul. Când învățăm să vorbim de copii, nu plecăm de la etimologie și semantică. Repetăm „mamă”, „cumpără o jucărie”, dar nu intrăm imediat în rădăcinile proto-indo-europene ale acestor cuvinte. Așa este aici: nu are rost să te scufunzi în profunzimea caracteristicilor tehnice ale autotestelor fără a încerca să scrii ceva care să funcționeze.
Sună puțin contraintuitiv, dar funcționează.
În prima lecție, merită să oferiți o bază despre cum să scrieți direct autotestele. Ajutăm la configurarea mediului de dezvoltare (în cazul meu, Intellij IDEA), explicăm regulile minime de limbaj care sunt necesare pentru a scrie o altă metodă într-o clasă existentă folosind pașii existenți. Scriem cu ei una sau două teste și le dăm teme, pe care le-aș forma așa: o ramură s-a ramificat de la master, dar din ea au fost scoase mai multe teste. Rămân doar descrierile lor. Le cerem testerilor să restaureze aceste teste (nu prin show diff, desigur).
Drept urmare, cel care a ascultat și a făcut totul va putea:
- învață să lucrezi cu interfața mediului de dezvoltare: crearea de ramuri, taste rapide, comite și push;
- stăpâniți elementele de bază ale structurii limbajului și claselor: unde să inserați injecțiile și unde să importați, de ce sunt necesare adnotări și ce fel de simboluri se găsesc acolo, în afară de pași;
- înțelegeți diferența dintre acțiune, așteptați și verificați, unde să folosiți ce;
- observați diferența dintre autotestări și verificări manuale: în autotestări puteți trage unul sau altul handler în loc să efectuați acțiuni prin interfață. De exemplu, trimiteți un comentariu direct la backend în loc să deschideți o vizualizare de activități, să selectați intrarea, să tastați text și să faceți clic pe butonul Trimite;
- formulați întrebări la care se va răspunde în pasul următor.
Ultimul punct este foarte important. Aceste răspunsuri pot fi date cu ușurință din timp, dar este un principiu important de predare că răspunsurile fără întrebări formulate nu sunt reținute și nu sunt folosite atunci când sunt necesare în cele din urmă.
Ar fi ideal dacă în acest moment un inginer de automatizare din echipa QA i-ar fi atribuit o sarcină să scrie câteva teste în luptă și să-i permită să se angajeze în filiala lui.
Ce să nu dau:
- cunoaștere mai aprofundată a funcționalității mediului de dezvoltare și a limbajului de programare în sine, care va fi necesară doar atunci când lucrați cu ramuri în mod independent. Nu va fi amintit, va trebui să-l explicați de două sau de trei ori, dar prețuim timpul inginerilor de automatizare, nu? Exemple: rezolvarea conflictelor, adăugarea de fișiere în git, crearea de clase de la zero, lucrul cu dependențe;
- tot ce tine de xpath. Serios. Trebuie să vorbiți despre asta separat, o dată și foarte concentrat.
Pasul 2. Aruncând o privire mai atentă la gramatică
Să ne amintim captura de ecran din vizualizarea sarcinilor de la pasul #0. Avem un pas numit checkCommentWithTextExists. Testerul nostru înțelege deja ce face acest pas și putem să ne uităm în interiorul pasului și să-l descompunem puțin.
Și în interior avem următoarele:
onCommentBlock(userName).comment(expectedText).should(displayed());Unde este onCommentBlock
onCommonStreamPanel().commentBlock(userName);Acum învățăm să spunem nu „cumpărați o jucărie”, ci „cumpărați o jucărie de la magazinul Detsky Mir, situat în dulapul albastru de pe al treilea raft de sus”. Este necesar să explicăm că indicăm un element secvenţial, din elemente mai mari (flux -> bloc cu comentarii de la o anumită persoană -> acea parte a acestui bloc în care se află textul specificat).
Nu, încă nu este timpul să vorbim despre xpath. Doar menționați pe scurt că toate aceste instrucțiuni sunt descrise de ei și moștenirea trece prin ele. Dar trebuie să vorbim despre toți acești potrivitori și chelneri; ei se referă în mod specific la acest pas și sunt necesari pentru a înțelege ce se întâmplă. Dar nu supraîncărca: studentul tău poate studia singur afirmații mai complexe mai târziu. Cel mai probabil, ar trebui, waitUntil, afișat();, exist();, not(); ar trebui să fie suficient.
Tema este evidentă: o ramură în care a fost eliminat conținutul mai multor pași care sunt necesari pentru un anumit număr de teste. Lăsați testerii să le restabilească și faceți rularea să fie din nou verde.
În plus, dacă echipa de testare are nu numai funcții noi în activitatea sa, ci și unele remedieri de erori, îi puteți cere să scrie imediat teste pentru aceste erori și să le elibereze. Cel mai probabil, toate elementele au fost deja descrise; este posibil să lipsească doar câțiva pași. Acesta va fi antrenamentul perfect.
Pasul 3. Imersie completă
Cât mai complet posibil pentru un tester care va continua să-și îndeplinească sarcinile directe. În cele din urmă, trebuie să vorbim despre xpath.
În primul rând, să lămurim clar că toate acestea peCommentBlock și comentariu sunt descrise de ei.
Total:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"Ordinea poveștii este foarte importantă. În primul rând, luăm orice xpath existent și arătăm cum fila elemente conține unul și un singur element. În continuare, vom vorbi despre structură: când trebuie să utilizați WebElement și când trebuie să creați un fișier separat pentru un element nou. Acest lucru vă va permite să înțelegeți mai bine moștenirea.
Trebuie să se precizeze în mod explicit că un singur element este întreaga vizualizare a activității, conține un element copil - întregul flux, care conține un element copil - un comentariu separat etc. Elementele copil sunt în interiorul elementelor părinte atât pe pagină, cât și în structura cadrului de autotest.
În acest moment, publicul ar fi trebuit să înțeleagă ferm cum sunt moșteniți și ce poate fi introdus după punctul de la onCommentBlock. În acest moment, explicăm toți operatorii: /, //, ., [] și așa mai departe. Adăugăm cunoștințe despre utilizare în încărcătură @class si alte lucruri necesare.
Elevii ar trebui să înțeleagă cum să traducă xpath în acest fel. Pentru a consolida - așa e, teme. Ștergem descrierile elementelor, le lăsăm să restabilească funcționarea testelor.
De ce această cale anume?
Nu ar trebui să supraîncărcăm o persoană cu cunoștințe complexe, dar trebuie să explicăm totul deodată, iar aceasta este o dilemă dificilă. Această cale ne va permite mai întâi să-i facem pe ascultători să pună întrebări și să nu înțeleagă ceva și să le răspundă chiar în clipa următoare. Dacă vorbiți despre întreaga arhitectură, atunci când subiectul pașilor sau xpath-ul este analizat, cele mai importante părți ale acesteia vor fi deja uitate din cauza incomprehensibilitatii lor.
Cu toate acestea, unii dintre voi probabil că veți putea împărtăși experiența dumneavoastră despre modul în care procesul poate fi optimizat și mai mult. Voi fi bucuros să citesc sugestii similare în comentarii!
Sursa: www.habr.com