ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 125
Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 64
Abonament PDF

Smart Requirements pentru Smart Testing

Narcis Oancea
Technical Manager @ 3Pillar Global
TESTARE


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.

Conjectură

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.

Noemă

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.

Argumente și raționament 

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. 

Definirea specificațiilor cu ajutorul cuvintelor cheie

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:

 

Î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. 

Concluzie 

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.

VIDEO: NUMĂRULUI 125

Sponsori

  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • AboutYou
  • Colors in projects

VIDEO: EXTRA