Behavior Driven Development în Python

În ziua de azi, testerii sunt priviți ca fiind cei care execută munca de rutină, de o dificultate mai ușoară, și ale căror skill-uri tehnice nu sunt atât de puternice pe cât cele ale programatorilor. Există echipe fragmentate, două tabere practic: developeri și testeri. Accentul nu se pune pe comunicare și colaborare, ci se investește efort și energie în acel vechi "battle", în care fiecare dorește să demonstreze că echipa proprie e mai bună.

Astfel de situații au dus în final la apariția conceptului de Testers = second class citizens. Ce înseamnă acest lucru mai exact? Nu se lucrează constructiv împreună, unde atât testerul cât și developerul pot beneficia unul de expertiza celuilalt, ci testerul lucrează doar după ce o bună parte din munca developerului e gata (există ceva palpabil pentru testare).

Proiectul nostru

...este unul complex, unde lucrează o echipa de aproximativ 50 persoane. Dacă nu am insista foarte mult pe colaborare și comunicare, nu am reuși să facem față metodologiei Kanban ce o abordăm, ce presupune un număr mare de teste automate, inițiativă și proactivitate din partea tuturor.

Cum am ajuns noi să depășim această situaţie? Prin efort colaborativ și comunicare. Testerii nu trebuie să aștepte ca un build să fie gata pentru testare, pentru a-și putea începe munca, ci pot lucra împreună cu developerii încă din momentul în care detaliile unui epic/story sunt clarificate. Împreuna pot stabili scenariile relevante ce trebuie testate, și scrie codul de automation necesar.

Suntem mândri să lucram într-un mediu unde fiecare membru al echipei se ghidează după principiul Quality is a team effort.

Trebuie să ținem cont de un lucru: această abordare nu ar fi posibilă fără un număr mare de teste automate, care să asigure regression testing-ul. În caz contrar, toată această comunicare cu echipa de development ar deveni un overhead pentru testeri (și nu numai), deoarece presupune multe discuții în prealabil, care consumă din timpul necesar scrierii și executării testelor. Poate vă gândiți că o simplă abordare Agile-Scrum ar fi suficientă, pentru că detaliile necesare implementării și testării unui feature nou se pot stabili în cadrul unui meeting de stand-up. Dar cred că știți cu toții că aceste meeting-uri pot devia de la formatul lor standard, depășindu-se deseori numărul de 15 minute alocate în mod ideal, și nu se ajunge la un consens în ceea ce privește rolul fiecărui membru al echipei.

Concepte teoretice Behavior Driven Development

Pentru a îmbunătăți și mai mult lucrul în echipa noastră, ne-am îndreptat atenția către Behavior Driven Development¹, o metodologie ce se axează pe comunicare și colaborare ca puncte forte. Definiții pentru BDD sunt multe, dar noi vă prezentăm câteva dintre conceptele BDD așa cum le-am aplicat în cadrul proiectului nostru:

• Comparativ cu Test Driven Development (unde testele dictează arhitectura), Behavior Driven Development reprezintă o extensie. Ca și în TDD, testele reprezintă catalizatorul metodologiei, dar sunt scrise într-un format ușor de înţeles de către toată lumea. Vorbim aici de limbajul Gherkin (Given-When-Then), care permite și persoanelor non-tehnice din echipă să contribuie la scrierea și menținerea testelor.
• Comunicarea și Colaborarea reprezintă fundamentele BDD. Fără aceste două concepte, BDD nu poate fi aplicat cu succes.
• Diferite perspective asupra sistemului sunt oferite atunci când se aplică BDD. Și acest lucru este posibil pentru că BDD ne dă ocazia să punem câteva întrebări cheie echipei de product management:
• De ce este nevoie de acest feature?
• Care este problema ce o adresează? Care este publicul țintă?
• Care sunt alternativele?
• ...and so on

Răspunzând la întrebări de acest gen, putem să privim produsul din prisma product owner-ului, fiind capabili astfel să înțelegem mai bine business value-ul ce un produs/feature nou îl poate aduce.

• De asemenea, dacă cele mai de sus se aplică cu succes, o mai bună relaționare cu clienții este un alt avantaj ce rezultă aproape fără efort.
• Living documentation - Documentația formată din testele scrise în limbajul Gherkin, constituie principalul avantaj al acestei metodologii.

Procesul BDD în echipa noastră

Practic, pașii ce îi urmăm noi din momentul în care apare o idee de feature nou, până când aceasta se materializează sunt următorii:

• Echipa de management are o idee despre un feature/produs nou, idee transpusă în backlog.
• Această idee este transpusă de multe ori direct ca soluție tehnică. Această abordare este greșită și aici este un aspect asupra căruia BDD ne permite să lucrăm. Product managementul trebuie să propună ideea, iar toată echipa contribuie la găsirea celei mai eficiente soluții tehnice.
• În mod ideal, product managementul și business analyst-ul participă la discuțiile preliminare, unde se pun întrebările cheie și se clarifică diverse aspecte.
• În lipsa unui business analyst, noi am descoperit că cel puțin în acest caz, atribuțiile business analyst-ului pot fi preluate de către echipa tehnică: tech leads, developeri, testeri.
• Se discută pe seama ideii, până când se ajunge la un consens asupra soluției și a strategiei de implementare/testare.
• În final, ideea este transpusă în bug tracker, nu ca o soluție venită direct din partea product management-ului, ci ca un rezultat al efortului colaborativ din partea întregii echipe, ajungându-se astfel la un epic/story cu detaliile bine clarificate.

După cum vă puteți da seama, BDD este un proces complex, care se poate aplica sub diferite "flavours" în cadrul mai multor echipe. Este o metodologie ce se ghidează după context, aceeași rețetă BDD ce funcționează pentru un proiect aducând alte rezultate dacă aplicată altui proiect. Sunt multe challenge-uri ce pot apărea de-a lungul timpului, iar noi am încercat să le abordăm pe fiecare în parte, evitând pe cât se poate recurgerea la compromisuri:

• Implicarea activă a echipei de product management
• Challenge: rolul PO-ului este mult mai mare într-un proces BDD, iar aportul lor la scrierea și menținerea testelor în limbajul Gherkin trebuie să fie într-un procentaj mai mare decât cel al echipei tehnice. În cazul nostru, încă nu am ajuns în această situație. Ținând cont de timpul limitat pe care PO-ul îl poate acorda acestui task, developerii și testerii sunt cei care scriu scenariile Gherkin, acestea urmând a fi revizuite periodic împreună cu managementul. Este o soluție de compromis ce funcționează în acest moment pentru echipa noastră.
• Folosirea cât mai eficientă a limbajului Gherkin
• Challenge: acest lucru este unul dintre cele mai complexe concepte ale BDD, deși în aparență poate părea destul de simplu. A scrie teste astfel încât să fie ușor de înţeles, ușor de menținut, din care să reiasă cu exactitate business value-ul feature-ului respectiv, se poate dovedi a fi un challenge în sine.
• Living Documentation
• Challenge: documentația formată exclusiv din teste poate deveni un challenge, deoarece sunt multe checkpoint-uri ce trebuie bifate, pentru a atinge acest goal:
• oglinda codului, reflectă întocmai situația actuală a codului,
• să fie accesibilă tuturor
• să fie ușor de înțeles, ușor de menținut
• presupunând că se dorește o schimbare majoră, într-un sistem legacy, Living Documentation poate reda riscurile ce pot apărea ca urmarea implementării schimbării respective. Acest lucru este posibil pentru că având teste scrise corect în limbajul Gherkin, putem urmări interacțiunea dintre componente, prin intermediul testelor, și vom reuși astfel să anticipăm posibilele riscuri.

Am insistat asupra limbajului Gherkin, exemplificând modul cum se poate descrie un feature prin scenarii scrise cu ajutorul acestui limbaj. Aceste teste sunt ținute în același loc cu codul, reprezentând datele de intrare ale unui tool specific BDD (Cucumber, Lettuce, Freshen, etc.). De aceea vom ști că sunt mereu up to date - testele sunt modificate de îndată ce codul este modificat, pentru a continua să reflecte situația actuală a codului.

Concluzii

Conceptele BDD aplicate în acest moment cu succes, obțin rezultatele dorite, dar suntem conștienți de faptul că mai avem mult de lucru. Printre obiectivele noastre în viitor, amintim:

• Comunicare și colaborare în permanență
• BDD depinde foarte mult de context, așa că încercăm mereu să ne adaptăm stilul de lucru astfel încât să acoperim particularitățile fiecărui proiect
• Codul scris de developeri trebuie să fie de la bun început testabil. Fără acest lucru, nu vom putea să scriem scenarii Gherkin care să îndeplinească cerințele Living Documentation menționate mai sus.
• Living Documentation reprezintă goal-ul nostru principal pe toată durata existenței unui proiect unde se aplica BDD.

BDD este un proces complex, dar avantajele sale sunt multe, și contribuie mult la închegarea unei echipe în adevăratul sens al cuvântului și la livrarea unui produs de succes. Recomandăm sincer abordarea acestei metodologii, indiferent de complexitatea proiectului sau dimensiunea echipei. Aplicat astfel încât să țină cont de nevoile clare ale proiectului, BDD poate deveni cu ușurință o poveste de succes.

Bibliografie

Mai multe informații cu privire la cum se pot descrie funcționalități folosind un limbaj ubiquitos² (Gherkin) , în funcție de tool-ul ales, se pot găsi la:

Lettuce tutorial (http://lettuce.it/tutorial/simple.html#id1)-tool specific BDD, poate fi folosit cu Python

Cucumber tutorial (http://cukes.info/) - tool specific BDD, poate fi folosit cu Ruby

Freshen tutorial (https://github.com/rlisagor/freshen)- tool specific BDD, poate fi folosit cu Python

Behat tutorial (http://behat.org/) - tool specific BDD, poate fi folosit cu Python

...și lista poate continua