Dacă sunteți familiarizați cu TDD, atunci ATDD este cumva TDD cu un nivel mai ridicat de testare și cu mai multe părți interesate implicate, cu alte cuvinte, este mai mult o testare de acceptare decât o testare unitară. Dacă doriți să știți mai multe despre TDD, atunci vă rugăm să consultați următoarea postare:
Dezvoltarea bazată pe teste de acceptare (ATDD) este o metodologie de dezvoltare bazată pe comunicarea între clienții de afaceri, dezvoltatori și testeri. ATDD înglobează multe dintre aceleași practici ca și specificarea prin exemplu, dezvoltarea bazată pe comportament (BDD), dezvoltarea bazată pe exemple (EDD) și dezvoltarea bazată pe suport, denumită și dezvoltarea bazată pe testare a poveștilor (SDD). Toate aceste procese îi ajută pe dezvoltatori și pe testeri să înțeleagă nevoile clientului înainte de implementare și permit clienților să poată dialoga în propriul limbaj al domeniului lor.
Dispus pe scară largă în cadrul echipelor Agile, ATDD este o practică în care analiștii de afaceri, dezvoltatorii ,testerii și utilizatorii lucrează împreună pentru a defini criteriile de acceptare a fiecărei povești (sau caracteristici) într-o etapă timpurie a procesului de dezvoltare (Înainte de începerea codării). Această abordare permite tuturor părților interesate să aibă și să mențină același nivel de rezultate așteptate înainte ca orice dezvoltator să înceapă să codifice.
Știu că am auzit cu toții acest stereotip: „Dezvoltatorilor nu le pasă de specificații, iar testerii nu vor să facă automatizări”, dar cu ATDD acest lucru va economisi o mulțime de timp și bani pierduți, asigurându-se că dezvoltatorii sunt mai implicați în primele etape ale specificațiilor, iar testerii automatizează testele de acceptare.
Cum se implementează ATDD în „viața reală”?
Utilizați SCRUM? Dacă da, atunci deja faceți cea mai mare parte a muncii în ATDD. dacă nu, atunci următorul exemplu trebuie să vă alimenteze curiozitatea :
Exemplu
Să presupunem că proprietarul produsului sau clientul a solicitat următoarea caracteristică în aplicația noastră mobilă: „În calitate de utilizator, doresc să ocolesc ecranul de autentificare, astfel încât să pot utiliza aplicația în mod anonim.” După revizuirea acestei solicitări cu toată echipa (analist de afaceri, dezvoltatori, testeri…) și cu mai multe detalii adăugate poveștii sau caracteristicii, vom avea niște teste de „acceptare” sau „funcționale” asemănătoare cu aceasta (Vă rugăm să rețineți că acesta este doar un exemplu, lipsesc multe teste de acceptare pentru această caracteristică):
- Criteriul de acceptare 1: Aplicația acceptă opțional login/parolă pentru autentificare
- Criteriul de acceptare 2: Butonul de ocolire permite utilizatorului să navigheze în cadrul aplicației fără a se autentifica.
- Criteriul de acceptare 3: Atunci când este selectat butonul de ocolire, aplicația nu stochează și nu afișează nicio informație specifică utilizatorului.
- Criteriul de acceptare 4: Atunci când se utilizează login/parolă, interfața grafică a aplicației trebuie ajustată la setările utilizatorului.
Beneficii
1- Alinierea client-vânzător: Având criteriile de acceptare de mai sus ca informație de intrare, noi (fiecare membru al echipei) suntem acum siguri că aplicația își va menține funcționalitatea de autentificare/parolă și va adăuga doar un buton care să permită utilizatorului să ocolească ecranul de autentificare.
2- Calitate și rentabilitate: Testele de mai sus pot fi automatizate cu ușurință chiar înainte ca dezvoltatorii să înceapă să codifice.
3- Time to Market: Odată ce testele sunt implementate, dezvoltatorii își pot valida sarcinile necesare înainte de a anunța că au terminat.
ATDD nu necesită instrumente specifice. Este important de știut, că NU toate testele de acceptare trebuie să fie automatizate. Automatizarea testelor depinde de mai multe aspecte, cum ar fi: provocările tehnice, termenul limită și costul.
Se recomandă vreun instrument?
ATDD nu necesită instrumente specifice. Este important de știut, că NU toate testele de acceptare trebuie să fie automatizate. Automatizarea testelor depinde de mai multe aspecte, cum ar fi: provocările tehnice, termenul limită și costul.
În această secțiune vă voi oferi doar o prezentare generală a celor mai utilizate instrumente de automatizare pe ATDD:
FitNess: Cadrul complet integrat de sine stătător pentru wiki și teste de acceptare
Robot framework: Cadrul generic de automatizare a testelor pentru teste de acceptare și dezvoltare bazată pe teste de acceptare (ATDD)
Calabash: Testarea automatizată a acceptării pentru aplicații mobile – Rețineți că este posibil ca acest cadru să nu suporte cea mai recentă versiune a sistemului de operare (peste Android O )