Un ghid rapid pentru implementarea ATDD

Acest articol oferă un ghid rapid pentru oricine este interesat să implementeze ATDD în echipele și proiectele lor. El subliniază beneficiile urmăririi acestei abordări Agile pe baza experienței mele directe într-o echipă de dezvoltare software corporativă.

Colaborarea este una dintre valorile de bază ale metodologiei Agile. Odată, în timp ce lucram la un proiect de mari dimensiuni, am observat o lipsă de colaborare între dezvoltatori, testeri și persoane cu preocupări de afaceri; o lipsă de claritate în ceea ce privește cerințele; o depășire frecventă a domeniului de aplicare a cerințelor; o lipsă de vizibilitate în ceea ce privește testarea finalizată; și defecte identificate târziu în ciclul de viață al proiectului. Cel mai important pentru mine, însă, a fost faptul că nimeni nu avea nicio idee despre cadrul nostru de automatizare, astfel încât toate testele de automatizare au fost scrise după ce funcțiile erau dezvoltate și pregătite pentru testare. Din cauza acestor observații, am început să cercetez modul în care oamenii abordează acest tip de probleme. Ca urmare, am descoperit Acceptance Test Driven Development (ATDD) ca fiind una dintre abordările folosite pentru a atenua multe dintre aceste probleme. Aceasta este adesea folosită ca sinonimă cu Behavior Driven Development (BDD), Story Test Driven Development (SDD) și Specification By Example (SBE). Principala distincție a ATDD, spre deosebire de alte abordări agile, este faptul că se concentrează pe faptul că dezvoltatorii, testerii, oamenii de afaceri, proprietarii de produse și alte părți interesate colaborează ca o singură unitate și creează o înțelegere clară a ceea ce trebuie implementat.

Pe baza propriei mele experiențe, voi împărtăși ideile mele cu privire la modul în care echipele pot implementa ATDD în propriile proiecte.

Contextul

Am lucrat la o companie mare care avea o mentalitate de startup, astfel încât orice idei inovatoare și feedback erau încurajate de către echipă. Construiam rapid prototipuri pentru a vedea dacă o idee ar face produsul nostru mai bun sau ar ajuta la obiectivele generale ale companiei. Am fost testerul principal într-o echipă de 25 de membri, care era formată dintr-un scrum master, un lider tehnic și mai mulți analiști de afaceri, designeri, dezvoltatori și testeri. Ca urmare a culturii de inovare, în cadrul echipei exista deseori haos, inclusiv schimbări frecvente ale cerințelor privind caracteristicile, persoane care lucrau în medii izolate, iar moralul echipei era la un nivel foarte scăzut. Acest lucru era îngrijorător pentru mine, așa că m-am oferit voluntar să ajut la găsirea unei soluții la aceste puncte dureroase, ceea ce m-a condus la ATDD.

Toate învățăturile și experiența mea cu ATDD pot fi clasificate în cei 3 pași de mai jos.

Ciclul de implementare a ATDD

Creat de Raj Subramanian

Pasul 1 – Formare și experimentare

Există multe moduri de abordare a sarcinilor, mai ales atunci când se iau în considerare experiențele indivizilor care lucrează în diferite echipe agile în interiorul și în afara organizațiilor lor actuale. Pentru a aduce o înțelegere comună și împărtășită a obiectivelor echipei și ale organizației, este important să se ofere o instruire adecvată. În ceea ce privește în mod specific ATDD, aceasta ar trebui să includă scopuri, obiective, așteptări și informații despre rezultatele care vor rezulta din utilizarea acestei abordări. După instruire, este important să se înceapă cu o implementare la scară mică pentru a încerca diferite lucruri și pentru a primi feedback iterativ.

De exemplu, după ce am cercetat ATDD, am explicat diferitelor părți interesate de ce trebuie să explorăm această abordare și ce beneficii vom primi de pe urma ei. Am evidențiat câteva dintre posibilele aspecte pozitive, cum ar fi creșterea colaborării în echipă, o mai bună clarificare a cerințelor, identificarea mai rapidă a defectelor în cadrul ciclului de viață al dezvoltării software (SDLC), creșterea vizibilității și utilizarea mai rapidă a automatizării în SDLC, precum și implicarea întregii echipe în elaborarea unor criterii de acceptare clare.

În timpul discuției mele cu părțile interesate, am subliniat faptul că acest lucru va necesita o anumită experimentare, dar, fără a o încerca, nu vom putea cunoaște niciodată beneficiile sale. După câteva discuții îndelungate, am decis să împărțim echipa inițială de 25 de persoane în 2 echipe mai mici: Echipa A era formată din 12 persoane și urma să implementeze ATDD. Echipa B era formată din restul de 13 persoane și ar fi continuat să facă ceea ce făcea deja.

Am planificat un atelier de instruire de 2 zile pentru echipa A, învățând despre ATDD, determinând ce concepte aveau sens în contextul proiectului nostru și cum am putea valorifica automatizarea pe parcursul acestui proces. Am inclus un amestec de exerciții teoretice și practice în cadrul instruirii. Unele dintre exerciții sunt prezentate mai jos:

• Cum se scriu declarațiile Gherkin – Given/When/Then (GWT)
• Care sunt atributele cheie ale unei povești de utilizator bune?
• O demonstrație a cadrului nostru de automatizare, inclusiv atât modul în care a funcționat, cât și modul în care a fost structurat. Au existat, de asemenea, exerciții privind modul de a scrie coduri simple de testare de automatizare în echipă. Înainte de atelier, un membru al echipei și cu mine am modificat cadrul nostru de automatizare pentru a fi în concordanță cu abordarea ATDD. Am folosit pluginul Cucumber cu Java și Appium pentru cadrul nostru de automatizare.

Sursa

Pasul 2 – Creșterea vizibilității

Când un proiect trăiește prin mai multe sprinturi, este ușor să pierzi urma diferitelor procese care trebuie urmate. Așadar, cheia este de a face ca scopurile, obiectivele și așteptările să fie vizibile pentru întreaga echipă.

Când am început să folosim ATDD, am început prin a scrie pur și simplu fiecare dintre procesele zilnice care ar trebui urmate pe o tablă albă, pe care am plasat-o în locul în care echipa noastră își ținea întâlnirile zilnice de stand-up. La fiecare poveste de utilizator am adăugat o listă de verificare a elementelor care trebuiau să fie realizate înainte ca povestea să fie considerată completă. În acest fel, nu a existat nicio ambiguitate cu privire la procesele ATDD care trebuie urmate. Un astfel de element din lista de verificare a fost o ședință de lansare, în timpul căreia dezvoltatorul, testerul și oamenii de afaceri au discutat în echipă despre cerințe, au identificat cerințele care ar putea fi automatizate și au subliniat criteriile de acceptare ale poveștii în format GWT. Un alt element din lista de verificare a fost QA-Dev Handoff, în care dezvoltatorul îi arăta testerului, printr-o demonstrație rapidă sau o discuție, cum au fost completate cerințele și ce teste unitare au fost scrise ca parte a poveștii. Prin acest transfer, testerul a aflat ce zone nu au fost acoperite de testele unitare și a dezvoltat o mai bună înțelegere a caracteristicii implementate, ceea ce a dus la o mai bună acoperire a testelor. Elementele din lista de verificare au fost uneori evidente, dar este bine să fie clar precizate. Am inclus unul pentru a ne asigura că toate defectele asociate poveștii au fost închise; un altul a fost aprobarea finală de către o persoană de afaceri după vizionarea unei demonstrații, asigurându-ne că caracteristica a fost construită în conformitate cu cerințele și așteptările stabilite anterior.

Am început, de asemenea, să avem un „Șoim al procesului”. Acesta era un membru individual al echipei; putea fi un scrum master, un manager de proiect sau oricine care se asigura că echipa va respecta procesul. În cazul meu, acesta a fost un alt tester senior din cadrul echipei; el și cu mine am reamintit în mod regulat tuturor să urmeze procesul ATDD în toate întâlnirile, inclusiv standup, planificare, retrospectivă și alte întâlniri de echipă.

Pasul 3- Învățare iterativă și feedback

Având o buclă de feedback constantă este crucială în implementarea oricărei abordări agile, inclusiv ATDD. Organizarea de întâlniri retrospective săptămânale sau bisăptămânale cu întreaga echipă este o modalitate importantă de a ști care părți ale procesului sunt de fapt benefice pentru echipă și care dintre ele ar putea fi modificate. După cum știm deja, ceva care nu ajută echipa duce la pierderea de timp și efort. După cum afirmă Brian Tracy, autorul cărții Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time (Mănâncă broscuța aia!: 21 de moduri grozave de a nu mai amâna și de a face mai multe lucruri în mai puțin timp), „Una dintre cele mai proaste utilizări ale timpului este să faci foarte bine ceva care nu trebuie făcut deloc.”

În era actuală a tehnologiei informației, organizațiile nu își pot permite să piardă timp și energie pe abordări ineficiente; mai degrabă, avem nevoie de procese eficiente și ușoare. Acest lucru se leagă de principiul Lean Startup al învățării validate: ciclul Construiți, Măsurați, Învățați.

Cu acest lucru în minte, am început să am întâlniri de 30 de minute în fiecare joi cu echipa A pentru a verifica modul în care echipa se descurcă cu noul proces. Aceasta a fost o modalitate bună de a evalua ce schimbări trebuiau făcute pe baza reacțiilor din partea echipei. Această ședință a avut loc separat de ședința retrospectivă, care avea loc la sfârșitul sprinturilor de două săptămâni. Această abordare a adus un feedback continuu din partea echipei, ceea ce ne-a permis să facem schimbări imediate și eficiente. Feedback-ul nu provenea doar din verificările săptămânale ale procesului; întâlnirile zilnice de stand-up s-au dovedit a fi, de asemenea, o sursă valoroasă de informații. Actualizările și discuțiile individuale ale membrilor echipei au scos la iveală semnale de alarmă legate de proces și am putut să le abordăm imediat înainte ca acestea să afecteze restul echipei.

Rezumat

Ca urmare a urmării ciclului de implementare ATDD, echipa A a început să observe diferențe considerabile în ceea ce privește moralul echipei, colaborarea și cerințele.

Moralul echipei

Toată lumea a început să lucreze ca o echipă și s-a simțit împuternicită. Fiecare persoană a deținut o poveste de la început până la sfârșit. El/ea s-a asigurat că povestea avea toate informațiile necesare pentru a începe activitatea de dezvoltare și testare. Membrul echipei s-a asigurat, de asemenea, că toate acțiunile de urmărire legate de poveste au fost realizate. În cele din urmă, persoana era responsabilă de demonstrarea poveștii pentru toate părțile interesate la sfârșitul sprintului. Acest sentiment de proprietate a sporit semnificativ moralul echipei.

Colaborare

Întrunirile de lansare au adus împreună persoana de afaceri, dezvoltatorul și testerul, pentru a dezvolta o înțelegere comună a poveștii utilizatorului. QA-Dev Handoff, care a avut loc înainte de a împinge build-ul către serverele QA, a ajutat atât dezvoltatorul, cât și testerul să știe ce teste vor fi finalizate ca parte a poveștii și a adus o mai bună înțelegere a caracteristicii implementate. A existat o vizibilitate sporită în ceea ce privește automatizarea, deoarece întreaga echipă și-a asumat responsabilitatea, în loc să fie vorba doar de testeri. În cele din urmă, în cadrul ședințelor de planificare, întreaga echipă a discutat împreună povestea, generând astfel mai multe idei, întrebări și discuții. Creșterea colaborării a dus, de asemenea, la o mai mare învățare – echipa a decis să aibă sesiuni de coaching de la egal la egal pentru a învăța unii de la alții, testerii au început să facă teste exploratorii în perechi și sesiuni de lunch-n-learn au fost găzduite de diferiți membri ai echipei pentru a discuta diverse subiecte referitoare la tehnologie. Toate aceste lucruri au dus la îmbunătățirea colaborării generale a echipei.

Exigențe

Una dintre principalele probleme ale proceselor noastre anterioare a fost reprezentată de schimbările frecvente ale cerințelor și de creșterea domeniului de aplicare. Cu abordarea ATDD, era imperativ ca, odată ce dezvoltatorul începea să lucreze la o poveste, cerințele să fie blocate. Orice modificări trebuie să fie prioritizate alături de celelalte povestiri viitoare și adăugate la următoarele sprinturi. Acest lucru a redus volumul de muncă atât pentru dezvoltatori, cât și pentru testeri, și a împiedicat ca părțile interesate să aibă așteptări nerealiste privind caracteristicile finalizate.

După ce a văzut toate îmbunătățirile de mai sus, echipa B a început să implementeze și ea ATDD. Ca urmare, întreaga echipă inițială a folosit această abordare după ce a experimentat în mod regulat și a primit feedback.

Concluzie

Recomandăm abordarea ATDD, iar aceasta se aliniază cu „Paradigma Shift Left” care afirmă că dezvoltarea și testarea ar trebui să înceapă cât mai devreme posibil în SDLC. A adus mai multă vizibilitate în ceea ce privește automatizarea, deoarece am început să scriem teste automate la începutul SDLC, ceea ce, la rândul său, a sporit colaborarea în cadrul echipei.

Sursa

Rețineți, ATDD nu este o soluție „unică pentru toți”. A fost abordarea agilă care a avut cel mai mult sens în contextul proiectului meu, dar există diverse alte modalități de a îmbunătăți procesele în cadrul echipelor. Am folosit această abordare datorită accentului pus pe teste de acceptare mai bune, dar mai ales datorită accentului pus pe colaborare. Partea de colaborare este o parte integrantă a acestei abordări și cred că este cea mai valoroasă.

Despre autor

Raj Subrameyer este un strateg de carieră în domeniul tehnologiei care se concentrează pe a-i ajuta pe oameni să își găsească locul de muncă de vis și să devină lideri de succes. Este pasionat de îndrumarea profesioniștilor pentru a-și maximiza oportunitățile și pentru a-și descoperi zona de geniu. Își folosește experiența din industria tehnologică pentru a cerceta, vorbi și scrie despre cum putem îmbrățișa tehnologia și deveni cetățeni digitali cu drepturi depline. Este un vorbitor căutat la diverse conferințe și a fost prezentat în numeroase podcasturi și publicații, printre care CEOWORLD Magazine, Authority Magazine, Career Addict, Thrive Global, Addicted2Success și The Good Men Project. Este, de asemenea, autorul noii cărți – „Skyrocket Your Career”. Domeniile sale de expertiză includ avansarea în carieră, leadership-ul, motivația, productivitatea și antreprenoriatul. În timpul liber, îi place să călătorească și să savureze berea artizanală. Puteți găsi mai multe informații despre cum îi servește pe oameni prin intermediul site-ului său.

.