Waterfall, Agile, Test Driven Development (TDD), Behavior Driven Development (DBB), Rapid Application Development (RAD), Spiral Model, Feature Driven Development (FDD), Rational Unified Process (RUP), sunt doar câteva dintre cele mai cunoscute modele de dezvoltare a aplicațiilor software care au apărut ca răspuns la nevoia de a reduce timpul de livrare a software-ului către clienții finali, adică amortizarea investiției și obținerea unui profit mai rapid. Unul dintre efectele produse de evoluția modelelor de dezvoltare este declinul specificațiilor scrise în mod tradițional și definirea lor într-o formă simplificată. În acest context, se impune cu necesitate apariția unui nou concept de specificații care să satureze deplin această nevoie.
SMART Requirements sunt acele seturi de documentații, scrise în limbaj natural, care pot fi automat interpretate, testate și validate fără nici un fel de intervenție umană.
În acest fel, întreaga suită de procese, de la scrierea specificațiilor, definirea testelor, automatizarea și până la execuția lor automată, ar fi redusă la simpla definire a specificațiilor via SMART Requirements, acest lucru traducându-se, în final, prin reducerea timpului de livrare a produsul software către utilizatorii finali.
De ce nu există un model de dezvoltare cvasi perfect care să poată fi aplicat de către toate companiile care dezvoltă produse software?
Pentru că fiecare companie are implementat propriul proces, mai mult sau mai puțin standardizat, adaptat nevoilor sale, iar implementarea unui model care să fie adaptabil în toate situațiile, pentru toate tipurile de aplicații software, s-a dovedit empiric a fi o abordare nerealistă.
Companiile care dezvoltă software, la fel ca orice alte companii, au ca scop final acela de a produce venituri pentru investitorii lor. Cum acest segment de piață s-a dovedit a fi unul profitabil, investitorii, în mod natural, tind să "crească producția", să grăbească livrarea produselor pentru sporirea profiturilor.
Pentru a face față presiunii generate de reducerea timpilor de livrare, companiile și comunitățile software au început să-și transpună modelele de abordare și să dezvolte noi procese, metode și mijloace care vin în întâmpinarea exigențelor de eficiență și velocitate resimțite din partea investitorilor.
Vizavi de producția de software, am fost martorii unei direcții orientate înspre îmbunătățirea proceselor și adaptarea lor la profilul fiecărei companii și la tipul de produs pe care acestea le dezvoltă. Aceste investiții atrag după sine o mai bună productivitate, independent de industriile pe care sunt ele aplicate. Chiar dacă pe termen scurt acestea se dovedesc a fi bune, totuși, pe termen mediu și lung ele sunt perfectibile demonstrând suficient de multe puncte nevralgice.
În dezvoltarea software-ului în particular, în ultimele două decenii am asistat la o conversie în forță, aproape brutală, a modelelor de dezvoltare, iar plusul de valoare pe care investițiile în dezvoltarea de noi procese încă le mai poate livra sunt destul de limitate.
Eficientizarea producției se poate realiza în continuare, însă atenția și eforturile trebuie îndreptate spre optimizarea altor componente din ciclul de dezvoltare a produselor software. Două dintre acestea, costisitoare dar indispensabile dezvoltării software, sunt specificațiile produsului și asigurarea calității.
Paradigme ca 'specificații complete' sau 'testare exhaustivă' au ajuns subiecte tabu. Găsim frecvent situațiile în care specificațiile, în abordarea lor clasică, sunt incomplete sau ambigue, așadar interpretabile la nivelul tuturor actorilor participanți la actul de dezvoltare a produsului finit. Hiatul dintre ceea ce vrea clientul, ce înțelege analistul, ce se implementează și cum sau ce se testează a devenit o problemă des întâlnită și cu atât mai costisitoare cu cât discrepanțele sunt observate mai târziu.
Trei sau patru elemente? Interpretabil. Depinde de perspectivă.
Specificațiile interpretabile generează clivaje în comunicare și introduc discordanțe de percepere a funcționalității la nivelul tuturor actorilor implicați în procesul de dezvoltare.
Imaginea de mai jos este o exemplificare plastică a unor specificații incomplete.
Un important procent din resursele la nivel de proiect sunt alocate, pe de o parte, definirii specificațiilor la un nivel general acceptat pentru a începe dezvoltarea iar, pe de alta parte, testării și validării aplicației care urmează a fi livrată clienților finali.
O investiție tot mai prezentă și acceptată în majoritate de către investitorii din sfera IT este cea în automatizarea testării. Dacă în literatura de specialitate destinată disciplinei testării și validării produselor software s-a vorbit și încă se mai vorbește de paradigma "SMART Testing", de ce să nu avansăm acest concept de "SMART" și la nivelul specificațiilor și, mai mult, la adoptarea unei conexiuni directe între modul de definire a specificațiilor și testarea automată a acestora, adică SMART Requirements.
O interfață automatizată, unică, utilizată atât pentru definirea și validarea specificațiilor cât și pentru testarea automată a produsului, care să fie capabilă să "înțeleagă", să testeze și să valideze automat seturile de specificații venite direct de la client (sau requirement engineer, project owner, etc.), este unul dintre modurile prin care am putea reduce timpii de livrare. Specificațiile ar rămâne în continuare scrise într-un limbaj natural, non-tehnic, dar implementând un set de reguli clare care vor fi validate sintactic și logic la nivelul interfeței de automatizare. Aceeași interfață va genera scripturile de testare automată, reflectând întocmai cerințele specificațiilor și validând produsul software prin execuția testelor asupra modulelor dezvoltate.
Acest flux executat automat, fără a fi nevoie de intervenție umană, ar avea un impact major în reducerea timpul de producție a software-ului pentru că, pe de o parte ar scădea timpul necesar scrierii specificațiilor, iar pe de altă parte ar elimina situațiile de discordanță dintre cei care definesc sau modifică specificațiile și restul actorilor implicați în procesul de producție.
O soluție folosită în conceperea testelor automate cu ajutorul cuvintelor cheie (keywords) este modelul "Precondiție - Acțiune - Rezultat" sau "Given - When - Then" (GWT). Această soluție poate fi extinsă și aplicată direct în faza de definire a specificațiilor, facilitându-se astfel crearea testelor automate care vor reflecta cu strictețe cerințele impuse de aceste specificații.
Considerăm următoarea o exemplificare a modului diferit de abordare a definirii specificațiilor:
Abordare GWT, via Smart Requirements
Given, aplicația accesată.
When, pagina login afișată And click Login button.
Then, pagina home afișată.
În acest mod, specificațiile devin test case-uri sau, viceversa, test case-urile devin specificații.
Oricum am privi, avantajul de a avea specificații corect definite și teste executabile derivate automat din acestea este unul pentru care merită o investiție inițială într-o interfață de acest gen. Iar faptul că deja există comunități și pachete software care abordează aceste aspecte (ex. Cucumber) face ca efortul depus pentru implementarea acestei soluții să fie unul profitabil, iar pragul de rentabilitate a investiției inițiale să fie atins rapid.
Mai mult, această interfață ar putea fi folosită nu doar la implementare testelor funcționale și non-funcționale automate în regim black box, ci și la generarea testelor unitare (white box) sau la crearea unor scenarii complexe de testare bazate atât pe specificațiile produsului cât și pe experiența utilizatorilor cu produsul.
Toți actorii implicați în testarea produsului, inclusiv în fazele de user acceptance sau beta-testing, pot să-și creeze testele folosind modelul SMART Requirements, adăugând astfel valoare suitei generale de regresie automată a produsului final.
Specificațiile clare și asigurarea calității sunt două artefacte ce fac parte din ciclul de dezvoltare a aplicațiilor software unde nu ar trebui să se facă compromisuri.
În abordarea clasică, definitivarea specificațiilor era un proces costisitor, care încetinea dezvoltarea și extindea timpul de livrare a produsului către clienții finali.
O altă latură costisitoare a abordării clasice sunt acele puncte de inflexiune generate de orice schimbare a specificațiilor care impuneau, drept consecință directă, modificarea testelor aferente, fie ele automate sau manuale.
Prin introducerea unor cadre specifice care să implementeze SMART Requirements, avem abilitatea de a regenera scripturile testelor astfel încât ele să reflecte în totalitate orice modificări de la nivelul specificațiilor. Automat. Fără costuri suplimentare. Fără compromisuri.
de Robert Mălai
de Dan Colceriu
