Utilizarea Testarii Automate Pentru Asigurarea Calitatii Aplicatiilor E Business

CUPRINS

INTRODUCERE 2

Capitolul 1. Cadrul general și descrierea conceptelor teoretice 2

1.1 Testarea manuală vs. Testarea automată 2

Capitolul 2 – Metodologia cercetării 2

Capitolul 3 – Studiul de caz 2

3.1 Introducere – aspectul studiat 2

3.1.1 Declararea problemei 2

3.1.2 Obiectivele cercetării 2

3.1.3 Contextul 2

3.2 Studii anterioare 2

3.3 Studiu de caz 2

3.3.1 “Research question” 2

3.3.2 Setarea strategiei de testare 2

3.3.2.1 Decizia privind instrumentul pentru automatizare 2

3.3.2.2 Setarea mediului de lucru pentru soluția de automatizare 2

3.3.2.3 Arhitectura de testare 2

3.3.2.4 Dezvoltarea și rularea testelor automate 2

3.3.3 Procedura de colectare a datelor 2

3.4 Rezultate 2

Capitolul 4 – Concluzii 2

BIBLIOGRAFIE 2

INTRODUCERE

Internetul este una dintre cele mai importante mecanisme de comunicare și informare a lumii moderne, numărul utilizatorilor de internet fiind în continuă creștere, ajungând la zeci de milioane de utilizatori.Termenul de E-Business (Electronic Business) a fost folosit în premieră în anul 1997 de către IBM, definind business-ul ca o modalitate de”acces securizat, flexibil și integrat pentru desfășurarea diferitelor afaceri prin combinarea proceselor și sistemelor care execută operații de bază ale afacerii cu cele care fac posibilă găsirea informațiilor pe Internet”[Buraga,2005].Conform lui Bill Gates prin conectarea sistemului informatic pe Web se instituie “sistemul nervos central al afacerii” și se dezvoltă practic E-Business-ul. Internetul a devenit un mediu de afaceri foarte competitiv, combinând toate tehnologiile actuale într-un singur loc unde sunt integrate diferite dispozitive eletronice (telefon, fax, tabletă, SmartPhone, PC).

Aplicațiile de tip e-business sunt foarte complexe, durabile și cu implementare scumpă.E-Business-ul presupune cumpărarea și vânzarea de bunuri și servicii (B2B – Business-to-business și B2C – Business-to-consumer), deservirea clienților, procesarea plăților, promoții, gestionarea de control a producției, colaborarea cu partenerii de afaceri, schimbul de informații și altele.Așadar modelarea și construirea aplicațiilor software e-business e un proces delicat ce presupune integrarea mai multor componente ce interacționează (baze de date, sisteme de operare, servere, rețele, management de stocare, diferite module). Asigurarea calității acestora este o adevărată provocare.Asigurarea calității (QA – Quality Assurance) definește procesele și standardele care ar trebui să conducă la produse de înaltă calitate, precum și introducerea proceselor de calitate în ciclul de dezvoltare[Sommerville,2010]. Calitatea sistemului dezvoltat este identificat și considerat ca principala sursă a satisfacției utilizatorului[Lin&Wu&Chang,2011]. Satisfacția utilizatorului se referă la numărul de consumatori sau la procentul total al consumatorilor a căror experiență cu un anumit produs sau serviciu depășește obiectivele de satisfacție specificate [Farris,2010]. Cele mai importante atribute de calitate care trebuie atinse sunt: funcționalitatea, securitatea, utilitatea, siguranța, eficiența.Ciclul de dezvoltare a aplicațiilor e-business necesită un process intens de testare pentru asigurarea calității acestora, testarea lor fiind mult mai complexădecât testarea aplicațiilor clasice. Testarea este o etapă deosebit de importantă din ciclul de realizare a produselor software. Prin testare se urmărește dacă produsul software finit este în concordanță cu specificațiile inițiale ale produsului. Există mai multe metode de testare.

Testerii deobicei folosesc două forme dinamice de analiză: testarea automată (scrierea de cod de test pentru a testa o aplicație) și testarea manuală (folosind interfața grafică a aplicației pentru a aplica input-uri manual)[Whittaker,2009].

Costurile de calitate se referă la costurile care asigură prevenirea, descoperirea și corectarea defectelor în cadrul procesului de dezvoltare software, ele variând între 20 și 40 % din vănzări [KANER, 1996]. Cu ajutorul inginerului de QA multe din aceste costuri ale calității unui produs software sunt reduse sau pot fi evitate dacă se alege cea mai bună strategie de asigurare a calității.

Strategia de testare este un aspect foarte important, pe parcursul dezvoltării aplicațiilor e-business fiind de fiecare dată greu de luat decizia privind arhitectura de testare care să fie aplicată.Întrebarea cel mai des întalnită este dacă să se realize doar testare manuală sau și testare automată.Pentru asigurarea calității software în cadrul unui process de testare reușit, cu atât mai mult în ceea ce privește aplicațiile de tip e-business, trebuie cuprinse în strategia de testare următoare: Testarea funcțională, Testarea bazată pe risc, Testarea interfeței grafice (GUI), Testarea de acceptanță, utilitate și accesibilitate, Testarea de performanță (de stres și cea de încărcare), Testarea de regresie, Testarea de instalare și configurare, Testarea securității, etc. Toate acestea presupun mult timp, mai ales cu cât aplicația testată este mai complexă. De aceea testarea automată poate veni în sprijinul echipei de testare.

Testarea automată, deși în ultimul timp este folosită tot mai des și a devenit foarte populară, este privită cu reticență doarece presupune costuri în plus pe care de cele mai multe ori clienții refuză să le suporte întrucât nu pot vedea beneficiile imediate. În faza incipientă a proiectelor de cele mai multe ori nu se știe faptul că poate cererea de funcționalități va fi în continuă creștere și astfel se poate ajunge în cazul în care să se dezvolte o aplicație cu peste 1000 de cazuri de testare manuale. În acest punct procesul de asigurare a calității devine cu siguranță o provocare, mentenanța testelor devenind foarte dificilă. Pe parcursul procesului de dezvoltare software în Agile, așa cum este și normal, orice aplicație crește constant în fiecare Sprintprin adăugarea de noi funcționalități conform specificațiilorși astfel după fiecare iterație și numărul cazurilor de testare este în continuă creștere. Este momentul în care se caută o metodă de reducere a timpului de testare și îmbunătățirea per total a calității aplicației, fără a se introduce timp de testare suplimentar sau fară a fi nevoie a se mari echipa de testare. Abia acum beneficiile testării automate prind contur. Fără îndoială că în acest punct realizarea pe parcurs de teste automate eficiente ar fi fost o decizie foarte benefică și acum ar fi fost de mare ajutor pentru echipa de testare.

Așadar în lucrarea de față vom evalua cum testarea automată ar putea ajuta la economisirea timpului de testare și impactul pe care îl are asupra asigurării calității software. Întrebarea științifică la care răspunde lucrarea este următoarea: ”De ce trebuie introdusă testarea automată în strategia de testarea unei aplicații de EB?”. Am ales această temă deoarece introducerea testării automate în test strategy-ul de testareeste o decizie controversată,întrucât poate fi foarte costisitoare și nu produce întotdeauna randamentul scontat, deși este de mare actualitate în sfera QA și nevoia de aceasta este în continuă creștere. De cele mai multe ori clienții nu doresc să suporte costurile presupuse de testarea automată deoarece nu înteleg rolul acesteia.Deși prezintă o serie de avantaje și puncte forte, multe eforturi de automatizare eșuează sau nu dau randamentul așteptat în urma investițiilor.

Capitolul 1. Cadrul general și descrierea conceptelor teoretice

Asigurarea calității (QA – Quality Assurance) este parte a ingineriei software cedefinește procesele și standardele care ar trebui să conducă la produse de înaltă calitate, precum și introducerea proceselor de calitate în ciclul de dezvoltare a produselor software [Sommerville,2010].Calitatea programelor se evidențiază prin procesul de testare.

Testarea software este procesul prin care se detectează erorile și se verifică dacă aplicația îndeplinește cerințele specificate. În timpul ciclului de dezvoltare software programatorii și inginerii de QA colaborează împreună pentru a găsi bug-uri și a le rezolva pentru asigurarea calității produsului pe care îl dezvoltă pentru ca la final produsul să fie livrat cu toate funcțiile cerute în concordanță cu standardele de calitate. Pentru o lungă perioadă de timp testarea software a fost realizată manual, însă încă de la începutul industriei software inginerii au depus eforturi mari pentru a automatiza procesul de testare[Kanglin&Menqi,2004].

De ceva timp testării folosesc testarea automată în încercarea de a se scuti de testarea manuală (care implică construirea cazurilor de testare, selectarea datelor de test, stabilirea precondițiior sistemului, executarea testelor, compararea rezultatelor cu cele așteptate conform specificațiilor și ulterior raportarea eventualelor defecte). Se știe că testarea automată promite să simplifice aceste operații, însă testarea automată eficientă și de success (atât din punctul de vedere al costurilor) este dificil de realizat, iar din cauză că multe procese de testare automată sunt adesea inițiate mult prea târziu își pierd scopul și eșuează. [Graham&Fewster,2012]

1.1 Testarea manuală vs. Testarea automată

Testarea manuală presupune că testerul să joace rolul end-user-ului și să folosească toate functionalitățile aplicației pentru a se asigura că funcționează corect, în conformitate cu comportamentul așteptat, după rularea aplicației cu datele de test. [Sommerville,2010] Acesta este cel mai vechi și mai riguros proces manual de testare software pentru găsirea defectelor și se potrivește foarte bine în strategia globală de realizare a software-ului de calitate. Pentru a se asigura completitudinea testării, testerul deobicei urmărește un plan scris de testare care conține un set de cazuri de testare importante. Testarea manualăeste o activitate laborioasă care solicită anumite calități pe care un tester trebuie să le posede cum ar fi: răbdarea, curiozitatea, atenția sporită, creativitatea, inovația, iscusința.

Testarea manuală presupune prezența umană a unui inginer de QA. Testerul ”își folosește creierul, degetele și iscusința sa pentru a crea scenarii care vor determina aplicația fie să eșueze, fie să-și îndeplinească misiunea”. Prezența fizică a testerului oferă cea mai bună șansă de a se creea scenarii de utilizare realiste, folosind date reale pe adevăratele medii de lucru ale utilizatorilor aplicației și care permite posibilitatea de a recunoaște bug-urile, atât cele subtile cât și cele evidente.[Whittaker,2009]Testarea manuală rămâne cea mai bună alegere pentru găsirea bug-urilor care stau la baza logicii de business a aplicației (logica de afaceri se referă la codul prin care se implementează cerințele utilizatorilor și, fiind complex, necesită un om ca să il verifice dacă este corect, o sarcină pe care testarea automată este de multe ori inadecvată în a o realiza).

Este recomandat ca întotdeauna pentru testarea software să fie folosite tehnicile de testare manuale(black box and white box testing). Tehnicile Black Box se bazează pe analiza documentației de bază, incluzând atât aspectele funcționale cât și cele non-funcționale (nu se folosește nici o informație cu privire la structura internă a sistemului testat). Tehnicile White Box se referă la tehnicile de proiectare a cazurilor de testare bazate pe cele care derivă din structura unei componente sau a sistemului dezvoltat. Tehnicile White Box mai sunt cunoscute și sub denumirea de tehnici structurale (se bazează pe structura internă mai degrabă decât pe cea externă și se folosesc pentru a explora componentele sau sistemul dezvoltat pe anumite nivele)[Hambling,2010].

Testarea manuală ajută la descoperirea bug-urilor software sau discrepanțelor legate de funcționalitatea produsului și trebuie să fie prezentă pe tot parcursul procesului de dezvoltare software.Trebuie precizat faptul că testerii care folosesc debug build-uri, depanatoare, proxy-uri și alte tipuri de instrumente de analiză se încadrează tot la testare manuală (ei doar le utilizează practic)[Whittaker,2009].

Testarea automată este un proces care utilizează instrumente (așa numitele tool-uri de testare automată) pentru a rula programul care umează a fi testat, oferind input-uri adecvate și verificarea rezultatelor cu output-ul care se așteaptă. Testarea automată necesită date de test pentru a explora AUT-ul (“Application Under Test” – după faza de design și implementare a codului fiecărei funcționalități din specificații în ciclul de dezvoltare a software-ului aplicația trebuie testată, în acest moment statusul aplicației find AUT). Datele de testare trebuie să reproducă scenariile de testare care execută funcțiile importante ale sistemului. Testele automate sunt eficiente numai în cazul în care datele de testare sunt alese bine [Mosley&Posey,2002].

Odată ce framework-ul de testare este setat, proiectat și suita de teste scrisă, testele vor rula automat fără intervenție umană. Framework-ul de testare automată face asta și oferă un raport al execuției testării la final care include statusul pass/fail a test case-urilor. De exemplu, pot fi mai mult de 200 de cazuri de testare care pot fi rulate peste noapte prin programarea unui job automat care rulează suita de teste automate.

Testele automate pot fi rulate rapid, repetitiv, de câte ori se dorește. Testarea automată este adesea cea mai cost-efectivă metodă de testare pentru produsele software care au o perioadă lungă a procesului de mentenanță., deoarece chiar și reparațiile minore în timpul duratei de viață a aplicației pot cauza defectarea caracterisiticilorcare funcționau anterior corect.

Pe piață există foarte multe tool-uri de testare automată care oferă înregistrarea și redarea funcționalităților care permit utilizatorilor să înregistreze interactiv acțiunile utilizatorului și să le răspundă ori de câte ori este nevoie, comparând rezultatele actuale cu cele așteptate.

Testarea automată poate fi capabilă să reducă sau să elimine costul testării actuale, dar nu toate testele pot fi automate. De multe ori este dificil să se decidă ce se automatizează și ce se testează manual.

Testarea manuală este de preferat pentru proiectele pe termen scurt, dacă cazurile de testare a unei aplicații trebuie să fie executate doar de câteva ori (nu se merită să se scrie script-uri automate), pentru testarea instalării și configurării (acestea implică anumite acțiuni, de exemplu schimbări hardware, și alte activități care pot fi gestionate doar manual de către un tester care să fie acolo prezent fizic), pentru testarea localizării (doar un tester competentpoate decide dacă o traducere are sens sau nu), pentru testarea utilității (pentru aceasta este deasemenea nevoie de raționamentul uman pentru a verifica dacă sunt probleme cu simplitatea, facilitate și eleganța interfeței grafice cu workflow-urile aplicației), pentru testarea/verificarea documentației (verificarea documentației necesită judecată umană).

Testarea automată este de mare ajutor în cazul proiectelor pe termen lung prin reducerea eforturilor de testare manuală repetată, putând fi executată pentru: testarea de regresie (reexecutarea unui test după un nou release pentru a se asigura că totul funcționează intact, conform așteptărilor sau pentru a confirma că un bug a fost într-adevăr fixat), pentru Monkey Testing (testarea automată este profitabilă pentru testele care necesită un volum mare de date și secvențe lungi de pași, tranzacții, sau alte intrări la nivel de sistem într-o căutare aleatorie de erori), pentru testarea de performanță, pentru Unit Testing, pentru testarea interfeței grafice (GUI) și pentrutestarea de compatibilitate browser (testele automate după ce au fost scrise pot fi rulate pe mai multe browsere – Chrome, Firefox, Netscape, Internet Explorer, Safari, etc).

Testarea compatibilității browser (testarea end-user a environment-ului) “este unul dintre cele mai provocatoare aspecte din testarea aplicațiilor bazate pe internet”[Glenford,2004]. Combinația de browsere și sistemul de operare (OS) este foarte mare (nu trebuie testat doar fiecare configurație browser ci și diferite versiuni ale aceluiaș browser). Testarea automată ajută deasemenea la testarea de performanță (Load/ Stress/ Capacity/Volume Testing) prin faptul că uneori sistemele trebuie verificate dacă suportă un volum mare de accesări. De exemplu, dacă trebuie simulat că 10000 de utilizatori accesează aplicația pentru a folosi functionalitățile, nu se pot angaja 10000 de oameni care să facă asta în același timp, în schimb orice număr de utilizatori poate fi simulat prin intermediul tool-urilor de testare automată corespunzătoare. De asemenea multe tool-uri de testare automată disponibile permit executarea Unit testelor pentru a analiza dacă diferitele secțiuni ale codului acționează conform așteptărilor în diferite circumstanțe. Prin faptul că prin intermediul tool-urilor de testare automată se oferă posibilitatea de înregistrare și redare a acțiunilor utilizatorilor, testerilor le este permis să redea acestea ori de câte ori este nevoie, comparând rezultatele actuale cu cele așteptate în ceea ce privește GUI,această abordare putând fi aplicată la orice aplicație care conține interfață grafică (unele tool-uri realizează screenshot-uri care se vor regăsi în rapoartele de testare).

Există foarte multe tool-uri de testare automată open-source care trebuie alese cu grijă astfel încât să se potrivească foarte bine cu aplicația care se dezvoltă (trebuie precizat faptul că nici un intrument nu va oferi o soluție completă, nici măcar cele licențiate care se dovedesc a fi costisitoare și limitează la arhitectura lor). Atât tool-urile open source cât și cele licențiate au atât plusuri cât și minusuri (voi reveni asupra acestora pe parcursul lucrării).

Beneficiul principal al utilizării instrumentelor de testare automată este faptul că acea cantitate de timp și efort consumat cu task-urile repetitive este foarte mult redus, acest timp putând fi salvat și apoi folosit pentru a reduce costurile de testare pe termen lung sau permite testerilor să petreacă mai mult timp cu sarcini intelectuale de planificare a testării. Cele mai multe dintre riscurile asociate cu utilizarea intrumentelor de testare se referă la așteptările mult prea optimiste cu privire la ceea ce poate face un astfel de instrument de testare și lipsa aprecierii corecte a efortului presupus de implementarea și obținerea beneficiilor pe care instrumentul le poate aduce pentru testare[Hambling,2010].

Întrucât cea mai controversată problemă de testare în cadrul procesului de dezvoltare software este dacă să se folosească testarea manuală sau testarea automată, întrucât nu toate testele pot fi automatizate și la unele etape de testare este utilă testarea automată, este de preferat atât testarea manuală cât și testarea automată, deși aparent pare dificil alegerea a ceeace să se automatizeze și ce nu. Testarea funcțională poate fi adesea automatizată, constând adesea într-un efort de a crea o suită de teste de regresie sau Smoke Testing.Cu toate acestea este logic ca înainte de a încerca testarea funcțională automată să se țină procesul de testare sub control prin testarea manuală. Prin înșiruirea împreună a testelor funcționale în workflow-uri se crează scenarii de utilizare realiste, fie manual sau automat, evităndu-se aici automatizarea dacă workflow-urile implică intervenția umană (a testerului). Deasemenea, deși testarea de bază a UI-ului poate fi automatizată, trebuie ținut cont de frecventele schimbări ale design-ului care pot conduce la costuri mari de întreținere pentru suita de teste automate, acestea trebuind acutalizate defiecare dată când apar modificări la nivel de UI.

Dacă facem o parală între testarea manuală și testarea automată cele mai importante aspecte care trebuie avut în vedere sunt: crearea test case-urilor, executarea cazurilor de testare, managementul și raportarea testului, mentananța și potrivirea metodei de testare cu nevoile de testare pentru aplicația verificată.

Efortul de creare a test case-urilor este mai mic decât în cazul automatizării. Crearea de script-uri automatizate consumă timp, dar este o activitate ce trebuie realizată deobicei o singură dată, însă se vor putea executa de câte ori va fi nevoie printr-o simplă comandă.

Execuția cazurilor de testare în ceea ce privește testarea manuală este de durată și tendențioasă din moment ce cazurile de testare sunt executate manual de către tester. Testarea automată reduce timpul de execuție a test case-urilor datorită faptului că scripturile apelează automat aplicația și rulează cazurile de testare.

Dacă luăm în considerare raportarea și managementul testului este evident că în cazul testării manuale acestea sunt realizate manual și acuratețea lor depinde de testeri, în timp ce în cazul testării automate acestea oferă o vedere automatizată asupra activității de testare (imediat după rularea testelor se poate obține raportul rulării).

În ceea ce privește mentenanța testelor este evident că în cazul testării manuale toate cazurile de testare vor fi actualizate manual de câte ori va apărea vreo schimbare, în timp ce în cazul testării automate dacă structura proiectului de automation este corect el va facilita mentenața testelor permițând testerului să facă ușor schimbări la nivelul funcției pentru a actualiza script-urile asociate cu acea funcție.

Testarea manuală se potrivește foarte bine pentru aplicațiile mai mici (cu un număr mic de pagini), astfel și numărul cazurilor de testare va fi mic. Testarea automată este recomandată pentru aplicațile de demensiuni mai mari (cu mai multe pagini) unde testarea este repetitivă (apar frecvent cicluri de regresie) și sub nici o formă nu se recomandă pentru aplicațiile instabile (în cazul acestora mententața script-uilor va fi de durată, se va pierde mult timp cu modificările apărute în urma instabilițății, practic testarea automată nu se va dovedi eficientă).

Există o serie de factori care influențează aceste avantaje și dezavantaje:performanțele tool-urilor de testare, nivelul de cunoștinte al echipei de QA, creșerea continuă a software-ului de testat, numărul regresiilor necesare. Deși testarea automată este foarte eficientă ea nu va da randament dacă tool-urile alese sunt nepotrivite cerințelor de testare. Deasemenea trebuie ținut cont de cunoștințele echipei deoarece dacă se alege o strategie de automation pentru care va fi nevoie de instruirea echipei costurile vor fi mai mari.

Capitolul 2 – Metodologia cercetării

Anton Pann spunea că ”Știința este o ușă a cărei cheie este cercetarea”. Cercetarea în cadrul domeniul IT este foarte importantă. Este binecunoscut faptul că, în ultimii ani, domeniul IT s-a bucurat deun avânt spectaculos, câștigând o pondere tot mai mare în economie. Cauza pentru această ascensiune este evidentă: evoluția tehnologieide la o zi la alta cu o viteză uluitoare, a pătruns în aproape toate domeniile de activitate, iar cererea de noi soluții software sau hardware se află în continuă creștere. În cadrul IT procesul de asigurare a calității produselor software (QA) este foarte important întrucât companiile dezvoltatoare au început să conștientizeze tot mai mult faptul că mai ales calitatea este ceea ce diferențiază produsele și serviciile lor de celelalte companii, acordând tot mai mult atenția cuvenită acesteia (toate companiile de IT au departamente de QA de sine stătătoare).Prin metodologia cercetării se întelege procesul folosit pentru colectarea informațiilor cu scopul de a lua decizii de business.Cercetarea este un proces care are etape distincte: după determinarea domeniul de studiu se face studiul biografiei din domeniu, se formulează ipotezele (se alege întrebarea științifică la care răspunde cercetarea), se proiectează designul cercetării, urmând apoi efectuarea ei. După efectuarea cercetării are loc analiza, se evaluează rezultatele după care se finalizează cercetarea prin prezentarea concluziilor. [Boehm,1980]

În cercetare există două mari metode de raționament: deducția și inducția. În cadrul capitolui următor vom folosi metoda studiului de caz și raționamentul deductiv (acesta are o abordare top-down, pornind de la general și ajungând la specific). După ce am studiat teoriile din domeniu vom formula o ipoteza care va fi sau nu confirmată în final, pe baza observațiilor. Studiul de caz este definit ca fiind o așa numită abordare de cercetare care se concentrează asupra dobândirii unei înțelegeri în profunzime a unei teme. Carla Wiling afirma despre studiile de caz că ”nu sunt caracterizate prin metodele utilizate pentru colectarea și analiza datelor, ci mai degrabă se concentreză pe o anumită unitate de analiză: un caz”. Studiile de caz prezintă date care sunt deobicei colectate printr-o varietate de mijloace inclusiv interviuri, observații. [Wiling,2008]Studiul de caz poate să fie explorativ, descriptiv sau explicativ. În cazul de față va urma un studiu de caz explorativ (în care cercetarea și colectarea de notițe a fost facută înainte de formularea ipotezei)[Yin,2009].

Studiul de caz este o metodă foarte populară de analiză calitativă și presupune observarea foarte atentă și completă a aspectului studiat[Kothari,2004]. Această metodă este cea mai recomandată atunci când se dorește o investigare completă și în profunzime a unui subiect, dar și a contextului în care aceasta se desfășoară. Studiul de caz are o serie de caracterisitici specifice, cele mai importante fiind: accentul pus pe alegerea unității de studiu și pe delimitarea sa în detrimentul considerentelor legate de metoda de cercetare, și faptul că este mai intesiv și mai detaliat. [Flyvbjerg,2011]. Studiul de caz poate folosi mai multe tehnici de colectare a datelor precum: analiza documentelor, observația, interviul, sondajele de opinie, experimentul. În studiul de caz prezentat în capitolul următor am folosit observația. Observația este cea mai veche metodă de cercetare. Se cunosc mai multe tehnici de observare, prima distincție făcându-se între observațiile non-participative (este exterior fenomenului) și cele participative (observatorul este integrat în mediu). Principalele caracteristici ale observației care trebuie amintite sunt: se desfășoară cel mai des în mediul natural al subiecților, este directă, permite și analiza contextului în care se desfășoară cazul studiat.

Scopul cercetării de față prin metodologia aplicată este de a îmbunătăți teroriile și de a spori cunoștințele din domeniu. Va fi o cercetare mai mult calitativă și explicativă (urmărește descrierea comprehensivă a cazului dezbătut) decât cantitativă.

Studiul de caz trebuie să aibă urmatoarele caracteristi cheie: fenomenul descris este examinat într-un cadru natural, datele să fie colectate prin mijloace multiple, doar una sau câteva entități(persoană, grup, organizație) sunt examinate, complexitatea unității este studiată intens, studiile de caz sunt mai potrivite pentru explorare – investigatorul ar trebui să aibă o atitudine receptivă privind explorarea, nu sunt implicate controale experimentale sau de manipulare, cercetătorul poate să nu specifice în avans setul de variabile independente și dependente, rezultatele obținute depind în mare măsură de competențele de integrare ale investigatorului iar accentul se pune pe evenimente conteporane[Izak,Goldstein&Mead,1987].

Am ales ca și metodologie de research pentru ITstudiul de caz deoarece aceasă metodă permite formularea răspunsurilor la întrebările de tipul „cum?” și „de ce?” pentru a înțelege natura și complexitatea procesului dezbătut și deoarece mi-a permis studierea proceselorunui sistem informațional în cadru natural, am aflat mai multe despre și am putut genera observațiile din practică. Așadar studiile de caz ar putea fi folosite pentru a documenta experiența practică[Izak,Goldstein&Mead,1987].

Întrucât întrebarea științifică la care răspunde cercetarea este”De ce trebuie introdusă testarea automată în strategia de testarea unei aplicații de EB?”era nevoie să fie examinat ciclul de dezvoltare a unei aplicații EB. Pentru studiul de caz mă interesa mai ales strategia de testare aplicată din cadrul procesului de asigurare a calității și trebuia să aleg unitatea de analiză cea mai potrivită pentru a ajunge la niște concluzii (dacă să fie un proiect sau departamentul de QA dintr-o companie). Am examinat strategia de testare aplicată pe un proiect EB dezvoltat într-o companie IT.Am avut grijă ca acest caz să fie în funcție de teoria testată și am ales să urmăresc strategia de testare pentru un proiect EB foarte complex care avea atât front office cât și back office. În studiul de caz se vor regăsi observațiile participative întrucât eu făceam parte din echipa de dezvoltare a aplicației selectate pentru studiu. Modalitățile obiective de identificare a rezultatelor cercetării se face prin evaluarea mai multor factori din ciclul de dezvoltare a aplicației evaluate: complexitatea aplicației, durata de dezvolatare a aplicației, metodele de dezvoltare, componența echipei de dezvoltare, TTM (time-to-market), costuri cu testarea, ROI, numărul de user stories per sprint, identificarea de bug-uri, timp alocat pentru testare, timpul necesar pentru testarea de regresie, atingerea scopului fiecărui sprint.Prin observarea directă și evaluarea acestor factori vom vedea impactul introducerii testării automate în strategia de testare a unei aplicații E-Business de tip B2B (Business-to-Business).

Capitolul 3 – Studiul de caz

3.1 Introducere – aspectul studiat

Asigurarea calității este, în ceea ce privește dezvoltarea de servicii și produse, orice proces sistematic prin care se verifică dacă un produs sau serviciu dezvoltat satisface toate cerințele conform specificațiilor. În domeniul IT multe companii au un department de sine stătător,dedicat asigurării calității. Asigurarea calității ajută la creșterea încrederii cumpărătorilor și credibilității unei companii prin îmbunătățirea proceselor de lucru și a eficenței, și deasemenea permite companiei să concureze mai bine cu alții. Sistemele de asigurarea a calității de azi subliniază găsirea defectelor înainte de a ajunge în producție la consumatorii finali. Trebuie precizat faptul cătestarea software nu este o fază ci este un proces care trebui întegrat în tot ciclul de dezvoltare a unui produs software.

Testarea software este procesul de executare a unui program sau sistem cu intenția de a constata defectele [Myers,2004]. În prezent este cea mai importantă și utilizată, pe scară largă, tehnică de asigurare a calității aplicătă în industrie. Aceasta poata solicita mai mult de 50% din timpul și bugetul alocate pentru dezvoltare [Beizer,1990].Prin testare se identifică bug-urile cât mai curând posibil prin toate testele corespunzătoare și se evită livrarea lor către consumatorul final. Din proprie experiență pot spune ca cea mai des întălnită problemă într-o companie este dacă să se automatizeze funcționalitățile implementate sau să se testeze manual. Se cunoaște faptul că nu toate testele pot fi automatizate și că de foarte multe ori devine dificil de decis ce să se automatizeze și ce să se testeze manual. Ambele metodede testare prezintă avantaje șidezavantaje. Așadarpentru a se asigura calitatea aplicațiiloreste recomandat să se opteze atât pentru testarea manuală cât și pentru testele automate pentru a obține produse de calitate. Este foarte cunoscut faptul că foarte mulți clienți nu se lasă convinși să plătească costurile implicate de scrierea testelor automate pentru că nu văd beneficiile imediate. Dacă aplicația este relativ mică se consideră că aceasta se poate testa manual și astfel costurile cu testarea automată ar fi o risipă de bani. Pentru început fiind vorba de o aplicație mică este adevărat, deoarece este relativ ușor de corectat bug-uri într-o aplicație a cărei cod de bază este de dimensiuni mici. Într-o etapă următoare când complexitatea aplicației crește controlul asupra eventualelor erori devine mai dificil. Când o aplicație se extinde devine mai grea indentificarea bug-urilor și acoperirea testării (test coverage). Timpul necesar pentru a realiza testarea manuală crește exponențial. Doar atunci când sistemul atinge o dimensiune/complexitate căruia este greu de asigurat fiabilitatea doar cu testele manuale se realizează faptul că testele automate scrise din timp deveneau foarte utile și aduceau un plus de valoare procesului de dezvoltare. Este foarte important înțelegerea a cum funcționează testareamanuală și cum funcționează testarea automată. Pentru a evidenția cum funcționează testarea manuală în cadrul unei aplicații aflate în dezvoltare (presupunând că nu există nici un test automat implementat) vom lua un exemplu banal în care se cere a fi verificat manual crearea unui cont de utilizator nou într-o aplicație care este în curs de dezvoltare. Pentru crearea contului trebuie să se specificice următoarele în cadrul unui formular: nume, prenume, adresa de email, parola, confirmare parolă. Pentru a testa formularul trebuie introduse corect aceste date în câmpuri. În final se dă click pe butonul ”Înregistrează-te” și înregistrearea va fi finalizată, însă nu și testarea acestei funcționalități. Este finalizată doar testarea unui scenariu din utilizarea formularului de înregistrare, urmând apoi a se verifica celelalte scenariiprecum de exemplu: ”ce se întamplă dacă email-ul există deja în sistem?”,”ce se întamplă dacă utilizatorul nu introduce numele?” , ”ce se întamplă dacă adresa de email introdusă este invalidă?”, etc. După ce se vor finaliza de verificat scenariile gândite se constată că aceasta ia destul de mult timp deși este vorba doar de un banal formular de înregistrare. Dar când este vorba de alte părți ale sistemului care ar trebui testate înainte de fiecare deploy, sprint după sprint. Dar dacă trebuie testat pe mai multe environment-uri, SO sau browsere? Acum, cu cât este mai mare aplicația dezvoltată și mai mare presiunea de a livra functionalități ale aplicației, cu atât șiprocesul de testare manuală devine mai time consuming. Scopul testării automate este același ca și la testarea manuală, diferența fiind faptul că aici comportamentul utilizatorului este practic programat în cadrul scripturilor de către echipa de QA, aceștia din urmă având posibilitatea să ruleze testele scrise pe environment-ul local sau pe un serverul special de test ori de câte ori este nevoie. Testarea automată nu se limitează doar la compotamentul utilizatorului. Unit Testing-ul se focusează pe unități individuale a codului sursă. De exemplu UT este utilizat pentru a testa o metodă a unei clase dacă returnează valoarea corectă. Unit testele sunt scrise de programatori în timpul implementării funcționalităților, fiecare metodă care conține calcule și operații complexe fiind recomandate pentru a fi testate în acest fel (Unit Testele din cauza timpului redus se scriu în special pentru zonele care conțin funcționalitățile cele mai complexe, importante și sensibile). Programatorul trebuie să se asigure că scrie suficiente teste pentru a acoperi toate cazurile și să se asigure că astfel metoda se va comporta corect chiar dacă aceasta primește parametri absurdi. Tot programatorii scriu și teste de integrare (de exemplu: verifică interacțiunile dintre module sau clase). Există deasemenea niveluri mai generale de testare a sistemului pentru a verifica dacă sistemul integrat complet îndeplinește cerințele și specificațiile sau dacă testarea de integrare a sistemului se focusează pe integrarea dintre aplicația curentă și terțe părți ale sistemului.

Întrebarea științifică la care va răspunde lucrareaeste ”De ce trebuie introdusă testarea automată în strategia de testare a unei aplicații de EB?”. Am ales această temă deoarece introducerea testării automate în test strategy-ul de testare este o decizie controversată, întrucât poate fi foarte costisitoare și nu produce întotdeauna randamentul scontat, deși este de mare actualitate în sfera QA și nevoia de aceasta este în continuă creștere. În cadrul studiului de caz voi descrie strategia de testare care conține și testare automată, aplicată pe un caz practic pentru a evalua eficiența automatizării.

3.1.1Declararea problemei

Deși în IT este binecunsocut faptul că testele automate sunt foarte eficiente și că aceastea ar trebui introduse aproape pe orice proiect de dezvoltare software, de fiecare dată când trebuie convinsă echipa de management că trebuie alocat timp și pentru aceastea datorită benefiicilor ulterioare, nu prea se ascultă. Deși majoritatea sunt de accord că testarea automată este un lucru benefic atitudinea imediată față de acestea este următoarea: “Nu, este prea mare pierdere de timp, să lăsăm echipa de QA să testeze funcțional, este mult mai fiabil”.

Deși aplicațiile E-Business sunt în general foarte complexe foarte mulți clienți când le sunt prezentate obțiunile de testare nu se lasă convinși să plătească costurile implicate de scrierea testelor automate pentru că nu văd beneficiile imediate și nici managementul echipei de dezvoltare deoarece asta ar însemna alocarea de resurse suplimentare din bugetul proiectului care nu ar fi acoperite. La aplicațiile cu termen scurt de dezvoltare și complexitate redusă se poate testa manual fără probleme. Aici costurile cu testarea automată ar fi o risipă de bani. Dar in cazul unor aplicații complexe cu mai multe modele și servicii, unde complexitatea aplicației crește constant, controlul asupra eventualelor erori este dificil. Când o aplicație se extinde, cu cât sunt implementate mai multe funcționalități cerute prin specificații, cu atât ea devine mai complexă și devine mai grea indentificarea și corectarea bug-urilor. Timpul necesar pentru testarea manuală crește exponențial întrucăt aplicația ajunge la dimensiunile în care este pur și simplu dificil de a asigura fiabilitatea promisă doar cu testele manuale având același număr de testeri.

Automatizarea presupune timp consumat cu crearea testelor, verificarea funcționării, documentarea, în cazul modificării funcționalităților sau a GUI, necesită mentenanță. De aceea trebuie convinși clienții și echipele de management că acele costuriconsumate cu scrierea testelor automate sunt nimica în comparație cu plusurile de care se vor bucura dupa ce acestea vor fi realizate.

3.1.2 Obiectivele cercetării

Obiectivul principal al acestui studiu de caz se concentrează asupra importanței testării automate asociate cu celelalte tehnici de testare din ingineria software, prin care se va clarifica decizia de luat cu privire la includerea testării automate în strategia de testare a proiectelor de E-Business.

Testarea automată este noua abordare în procesul de dezvoltare software, care a evoluat foarte mult în ultimii ani. Testarea automată a software-ului este procesul prin care se automatizează pașii executați de utilizator în cadrul cazurilor de testare folosind unul sau mai multe instrumente de testare automate (free sau open-source) pentru a scurta ciclul de viață a procesului de testare.

Testarea de regresie este folosită foarte fecvent pentru a testa în mod eficient sistemul prin selectarea sistematică a numărului minim de teste corespunzătoare din suită, necesare pentru a acoperi în mod adecvat schimbările apărute la nivelul sistemului dezvoltat. Metodele comune de testare de regresie includ reexecutarea testelor rulate anterior și verificarea dacă defectele fixate anterior au reapărut sau sunt fixate și dacă ceea ce funcționa anterior corespunzător funcționează în continuare conform așteptărilor. În cadrul acestei cercetări se va observa pe un caz practic necesitatea și beneficiile utilizării testării automate și utilitatea tool-uri de testare atât pentru partea de scriere și rulare a testelor, cât și pentru partea de raportare. Evaluarea cost beneficiu a automatizării este o problemă care trebuie abordată de fiecare dată când se realizează un plan de testare.

Tratând automatizărea testării ca orice alt proces de dezvoltare software apar niște întrebări juste la care se caută răspunsuri înainte de a se lua decizia de a se folosi testarea automată:vaîntârzia găsirea erorilor? (întrucât resursele de rulare a testelor manuale vor fi diminuate), se vor găsi suficiente erori (sau vor fi localizate tot prin testarea manuală)?, e reutilizabilă?, e eficientă sau se pot automatiza doar teste ușoare?.Prin citirea acestui studiu sper ca decizia privind introducerea testării automate în strategia de testare să nu mai fie o decizie atât de controversată.

3.1.3 Contextul

În cadrul acestui studiu de caz voi descrie strategia de testare(care conține și testare automata) a unei echipe de dezvoltare în Agile aplicată unei aplicații web E-Business. Studiul a fost realizat la o companie de IT din Cluj-Napoca care este prima companie din Europa Centrală care s-a alăturat ecosistemului de parteneri Hybris (Hybris Software SAP Company), de mai bine de 5 ani, oferind astfel clienților cele mai bune soluții pentru a le satisface nevoile. Aplicația dezvoltată în cadrul proiectului este o aplicație de tip E-Commerce B2B foarte complexă pentru un client din sectorul serviciilor de turism.Clientul este una dintre companiile de turism și agrement lider internațional, operând în mai mult de 180 de țări și 240 de brand-uri, la peste 30 de milioane de clienți. Acest proiect a fost unul dintre cele mai complexe implementări de hybris în Europa. Platforma Hybriseste o soluție de implementare SAP, licențiată, care a fost selectată ca tehnologia care permite comerțul front office și retail. Hybris a fost capabilă să servească cerințelor multichannel ale companiei cliente, gestionând informația produsului de bază responsabilă pentru transmiterea conținutului la toate canalele, incluzând desktop, mobile, web și print. Aplicația pe lângă integrarea cu Hybris a fost dezvoltată utilizând un mix de limbaje, tehnology și framework-uri (Java, JavaScript, Spring, Spring MVC, Mustache, ElasticSearch, Apache Ant Java library pentru build, HTML, CSS, json, ajax, etc) și servicii externe precum CRM Data, SmartXML (pentru plată), Content Delivery Platform. Fiind o aplicație e-commerce complexădin sectorul serviciilor de turism (pentru vânzarea și promovarea de vacanțe și servicii) specificațiile erau foarte clare, grupate pe procese (Înregistrare, Logare, Cont utilizator, Căutare oferte, Filtrare oferte, Vizualizare oferte, Rezervare, Cumpărare, Închirieri mașini, Plată, Email Support, Promoții). Aplicația fiind dezvoltată Agile a avut specificațiile transpuse în peste 220 de User Stories.Sprint-urile erau estimate la 2-3 săptămâni. Astfel după fiecare iterație s-a livrat funcționalitateanouă, conform duratei unui sprint. Logica de business a aplicației era foarte complexă. Integrarea cu hybris (care avea module deja dezvoltate) trebuia testată la fiecare funcționalitate adăugată. Modulele Hybris care au fost integrate cu aplicația web sunt: HMC (Hybris Management Module) pentru gestionarea conținutului,CMS Cockpit, HAC(Hybris Administration Console), WCMS (Web Content Management Module) pentru gestionarea conținutului.

Fig.1 – Arhitectura Standard hybris (Sursa: [Site1], slide nr.15)

S-a luat decizia de a introduce în strategia de testare automatizareapentruaajuta la regresie deoarece echipa era conștientă de complexitatea proiectului și din experiența avută pe proiectele anterioare (când nu s-a inclus testarea automata) pe parcurs ce treceau sprint-urile și se livra din ce în ce mai multă funționalitate era tot mai greu la testarea de regresie și după sesiunile defixare a defectelor, deoarece tebuia acoperit mult mai mult cu același număr de testeri. Este foarte dificil să testezi atât funcționalități noi dezvoltate într-un anume sprint cât și să faci testare de regresie la vechile caracteristici pentru a te asigura că totul funcționează confom așteptărilor și că nu a fost nimic afectat. Nu era primul proiect hybris și echipa era deasemenea conștientă că implementarea hybris însemna mult mai mult timp pentru testarea și verificarea integrării funcționalităților aplicațiile cerute de client cu modulele ajutătoare livrate de hybris. Aplicația care trebuia testată era dezvoltată în cea mai mare parte în limbajul de programare Java (Spring MVC Framework). O provocare majoră a echipei de testare era diversitatea de medii pe care trebuia testat: environmentul local, environmentul de test și cel de stage la finalul sprint-ului după ce se livra funcționalitatea. Trebuia să fie suportate toate sistemele de operare și browsere (IE8, IE9, IE10, IE11, FF v.11.0 și în sus, Chrome, Safari, Opera, etc). Astfel s-a generat o matrice cu potențiale combinații, o provocare pentru a acoperi tot.

Am prezentat caracterisiticile studiului de caz în tabelul următor:

Tabelul 1 – Caracteristicile contextului studiului de caz

Obiectivul echipei era să se livreze cod de calitate. O parte din testeri aveauexperiențăînautomatizare pe proiecte. Testele automate au ajutatfoartemult la testarea de regresie, iar împreună cu testarea manuală au adus un plus de valore proiectului. Echipa de QA a fost nevoită să facă o strategie de succes pentruaimplementasuita de teste pentrutestarea de regresie. Toți cei implicați în proiect s-au asigurat cătoateactivitățile de testareplanificateau fost executate la fiecareiterație.

3.2 Studii anterioare

Există destul de multă bibliografie în domeniul asigurării calității iar în ultima vreme au apărut tot mai multe lucrări care abordează aspecte privind tehnici de testare eficiente. Există lucrări care detaliază practicile găsite în cele mai de succes eforturi de automatizare dar și experiențele cu testarea automată pusă în aplicare.Articolele din reviste sau de pe site-urile online de specialitate (cum-ar-fi:-http://www.testingmagazine.com/,-http://www.testingexperience.com/, https://www.ministryoftesting.com/, etc) sau prezentările de la conferințele de testare tematice (de exemplu: Romanian Testing Conference) abordează deasemenea tema testării automate frecvent.

Cartea autorilor Dorothy Graham și Mark Fewster intitulată”Software Test Automation: Effective Use ofTest Execution Tools”, publicată în anul 1999, se pare că a stabilit standardul pentru cărțile care abordează acest subiect. În prima parte a cărții se detaliază practicile aplicate în cele mai de succes eforturi de automatizare cum ar fi tehnicile de scripting, compararea automată a rezultatelor, arhitectura de testare, iar în a doua parte au fost descrise și prezentate experiențele unui număr de organizații care au pus în aplicare testarea automată și au avut succes sau dimpotrivă, scot în evidență probleme întâlnite din care se poate învăța pentru a fi evitate[Graham&Fewster,1999].Ulterior cei doi autori au mai scos o carte la fel de interesantă. Prin cartea ”Experiences of Test Automation – Case Studies of Software Test Automation” de Dorothy Graham și Mark Fewsterse oferă un alt set de experiențe personale și la nivel de organizații pentru a se ghida benefic munca de automatizare. Autorii au punctat prin această carte atât descrierea abordării clasice de testare automată cât și cea mai modernă abordare de testare automată.Cartea oferă citirilor interesați îndrumare prin fiecare capitol. Fiecare capitol prezintă o poveste practică a unui efort unic de testare, inclusiv automatizare, precizând atât succesele cât și eșecurile pentru fiecare în parte[Graham&Fewster,2012].

Timp de decenii testerii au folosit testarea automată în încercarea de a se scuti de testarea manuală – construirea cazurilor de testare și a datelor de test, stabilirea precondițiilor sistemului, executarea testelor, comparea rezultatelor actuale cu cele așteptate, și raportarea posibilelor defecte. Testarea automată promiteasă simplifice toate aceste operații și chiar mai mult, însă din nefericire, testarea automată de succes, eficientă și având costuri reduse este dificil de realizat. Proiectele de testare automată sunt adesea inițiate mult prea tărziu și, pierzându-și astfel scopul lor,sunt ulterioraruncate în grămada mare de proiecte eșuate. Testarea automată eșuează în practică din multe motiv cum ar fi: așteptările prea mari (nerealizabile chiar) de la procesul automatizare – este poate cel mai comun motiv urmat de alocarea necorespunzătoare a resurselor (timp, oameni și bani). Alți factori includ alegerea instrumentelor de testare care sunt slab potrivite nevoilor, pura nerăbdare pentru success care împiedică de cele mai multe ori munca de calitate, precum și o lipsă de înțelegere a faptului că testarea automată este un mod diferit de dezvoltare software, unul care necesită acceași abordare profesională ca și toate celelalte eforturi de dezvoltare [Graham&Fewster,2012].

O concluzie general valabilă întâlnită atât în cărți, articole din reviste, articole online de pe site-urile de specialitate din domeniu sau în prezentările tematice la conferințeeste că tool-urile de testare automată sunt folosite de peste 30 de ani și încă multe tentative eșuează, sau cel puțin au success doar parțial. Cauza diferă și datorită potențialelor beneficii pe care le oferă testarea automată există un interes pentru acest timp de lucrări pentru că se dorește înțelegerea principiilor testării automate eficiente .

3.3 Studiu de caz

3.3.1 “Research question”

Întrebarea științifică la care se dorește a răspunde lucrarea este următoarea: ”De ce trebuie introdusă testarea automată în strategia de testare a unei aplicații de EB?”. Introducerea testării automate în strategia de testare a aplicațiilor este o decizie controversată, întrucât poate fi foarte costisitoare și nu produce întotdeauna randamentul scontat, deși este de mare actualitate în sfera QA și nevoia de aceasta este în continuă creștere. De răspunsul la această întrebare ar trebui să țină cont managerii de proiect și echipele de testare când aleg strategia de testare ce urmează a fi aplicată pentru aplicațiile de E-Business în curs de dezvoltare, dar și clienții cărora li ce recomandă să plătească resurse suplimentare pentru partea de testare.

3.3.2 Setarea strategiei de testare

Strategia de testare a fost stabilită de managerul de proiect împreună cu echipa de QA. Decizia privind introducerea și testării automate în startegiea fost evaluată luând în calcul experiența noastră cu alte proiecte, complexitatea specificațiilor aplicației în dezvoltare dar și o serie de alți factori precum: calitatea, TTM (time-to-market), estimarea nevoilor viitoare, costurile. În ceea ce privește calitatea am ajus la concluzia că prin automatizare numărul de teste care să fie rulate în fiecare sprint ar putea crește și deasemenea acestea s-ar putea rula mai rapid pe toate mediile specificate. Pentru evaluarea TTM-ului am estimat timpul necesar pentru scrierea și rularea testelor automate în comparație cu timpul care ar fi nevoie pentru rularea lor manual pe mediile cerute. Pentru estimarea nevoilor viitoare am estimat numărul de teste de care ne așteptam pe viitor să avem nevoie bazându-ne pe ciclul de dezvoltare a produsului după care am extrapolat economisirea TTM-ului pe care l-am obține cu automatizarea. În ceea ce privește costurile bazându-ne pe experiența anterioară și pe estimarea nevoilor viitoare ne era foarte ușor să estimăm costul non-automatizării și deasemnea puteam estima efortul necesitat pentru dezvoltarea mediului de automatizare și cel pentru scrierea testelor. Estimarea costurilor privind mentenanța testelor era practic imposibilă dat fiind faptul că schimbările ulterioare care puteau fi cerute nu se cunoșteau. De fiecare dată când apar modificări în aplicație în zonele unde sunt scrise testele automate pentru rularea suitei de teste va fi nevoie de actualizarea testelor pentru a se potrivi la rulare cu schimbările aplicate(din experiența mea pot spune că o mare parte din efort este cosumat cu acest aspect dar cu toate acestea probalilitatea schimbărilor care pot interveni nu se poate estima). După parcurgerea planului de dezvoltare, specificțiilor și strategiei de testare am conștientizat mai bine provocările (scrierea testelor automate mentenabile era un obiectiv cheie) și am stabilit de comun acord țintele pentru automatizare pe care le vom urmări (TTM, calitate, productivitatea echipei).

Odată ce s-a hotărât aplicarea testării automate în cadrul proiectului tebuia luată decizia privind instrumentul pentru automatizare care va fi folosit. Pentru aceasta s-a făcut un research pentru a vedea noutățile și părerile din domeniu. Testele automate au fost dezvoltate pentru cele mai importante funcționalități din aplicație. Funcționalitățile nou dezvoltate au fost testate manual pentru a se atinge DOD-ul echipei (definition of done). Fiecare task sau subtask implementat era deployat pe mediul de test și alocat task-ul corespunzător de către programator unui QA actualizând statusul cu ”Resolved”. Task-ul era testat funcțional și dacă totul era în ordine se actualiza statusul acestuia cu ”Closed”, dacă nu se deschideau noi bug-uri care se alocau la programator. Abia după rezolvarea problemelor task-ul era retestat și dacă totul era în ordine se închidea. În cadrul procesului de dezvoltare echipa a folosit Jirapentru alocarea task-urilor, înregistrarea timpului de lucru pe diferite task-uri și pentru urmărirea progresului. Fiecare Story din planul proiectuluiera înregistrat în jira sub formă de task și după caz se creau subtask-urile specifice. Task-urile puteau avea următoarele status-uri (Fixed, Won’t fixed, Open, Resolved și Closed) și mai multe rezoluții după caz (Unresolved, Fixed, Won’t fixed, Obsolete, Duplicate, Incomplete, Cannot reproduce, Postponed, Done). La sfârșitul fiecarui sprint s-au livrat funcționalitățile curente după care se facea un Smoke Testing și Testare de regresie (teoretic automatizarea testelor de regresie urma să asigure o acoperire mai mare a testării însă presupunea o investiție de bani și eforturi în plus).

3.3.2.1 Decizia privind instrumentul pentru automatizare

(Intrumente licențiate vs. instrumente open-source)

Costul automatizării este determinat și de instrumentele de testare care se aleg. Există multe instrumente de testare open-source (gratuite), dar și licentiate (care dacă sunt alese vor ridica costul automatizării).În urma studiului bibiografic se observă că majoritatea specialiștilor susțin că atât instrumentele open source cât și cele licențiate au atât plusuri cât și minusuri.Așadar prin alegerea pentru planul de testare a instrumentelor licențiate sau open-source există beneficii dar și riscuri. Beneficiul imediat al utilizării instrumentelor de testare automată licențiate e faptul că crearea de script-uri se începe imediat și rapid, fără să fie nevoie de a dezvolta inițial ceva (crearea unui framework de testare), însă există riscul ca acel instrument să nu satisfacă pe deplin cerințele aplicației testate sau ca echipa să nu se poată adapta comportamentului cerut de instrumentul de testare datorită faptului că nu există acces la codul sursă. Este evident că dacă instrumentul de testare automată se dovedește ineficient atunci se va pierde mai mult timp decât s-ar fi pierdut cu dezvoltarea acestuia.

În ceea ce privește utilizarea unui instrument de testare open source beneficiile sunt următoarele: nu afectează bugetul proiectului fiind fără bani și se poate dezvolta prin adăugarea de noi caracteristici în funcție de necesități întrucât echipa are acces la codul sursă.

Instrumentele de testare open-source în general folosesc limbaje de scripting populare, prevenind situațiile în care echipa să rămănă blocată pe viitor deoarce nu s-ar descurca cu acesta, întrucât există foarte multe soluții la îndemână în funcție de ceea ce este nevoie. Riscul asumat în cazul utilizării unui anume instrument open-source e probabilitatea mare că se va petrece mai mult timp cu crearea scripturilor și meținerea lor, întrucât pe lângă scrierea script-urilor mai trebuie făcute anumite configurări și adăugate mai multe caracteristici pentru a acoperi nevoile echipei de testare în ceea ce privește verificarea aplicației.

O soluție de mijloc cu siguranță cea mai bună ar fi combinarea a câtorva instrumente de testare automată, astfel alegându-se cea mai bună abordare pentru fiecare cerință (rulare, raportare, etc). Într-adevăr există riscul ca unele instrumentesă nu funcționeze foarte bine cu altele dar cu mici configurări și ajustări acest risc poate fi atenuat, existând la o simplă căutare pe Google nenumarate soluții pentru acest gen de “conflicte”.

Astfel cea mai bună abordare rămâne selectarea instrumentelor de testare automată open-source și combinarea acestora pentru a răspunde necesităților echipei de testare și obținerea beneficiilor așteptate în cadrul procesului de testare: reducerea timpului pentru a crea script-uri (ex. folosirea Test Data, constantelor, workflow-urilor, librărilor), reducerea timpului pentru mentenanța testelor (ex. folosirea step group-urilor). Prin folosirea combinată a acestor instrumente se utilizează în testare beneficiile fiecăruia și se estompează punctele slabe ale acestora. Unele caracterisitici dezvoltate se folosesc pentru toate testele cum ar fi: capturile de ecran, conectarea la baza de date, generarea automată de rapoarte, etc. Cel mai evident exemplu de tool folosit cu succes în combinație cu altele este Selenium. Un alt avantaj este faptul că se pot combina instrumente care să ajute atât pentru rularea testelor pe desktop cât și mobile (Appium).

Am ales ca și tool-uri open source SeleniumWebdriver pentru scrierea testelor la care am integrat Thucydides pentru a ajuta la partea de raportare (în momentul de față soluția aleasă atunci Thucydides și-a schimbat denumirea în Serenity BDD[Thucydides(Serenity)Doc,2015]).

Selenium ”automatizează browserele”[SelediumDoc,2015]. Este un tool folosit pentru automatizarea aplicațiilor web în scopul testării, dar nu este limitat doar la asta, sarcinile plictisitoare de administrare bazate pe web pot fi deasemnea automatizate. Cu un tool de testare cum este de exemplu Selenium webdriver QA-ul are posibilitatea de a vedea cum sunt accesate butoanele și link-urile în browser, cum sunt completate formularele, etc (pașii care au fost specificați în teste). În acest caz testarea nu este la fel de rapidă ca și în cazul testelor executate fără a fi afișate în browser dar tot este mai rapidă decât efectuarea tuturor acțiunilor manual.Un sprijin puternic pentru testele automate bazate pe Selenium este oferit de Thucydides (Serenity BDD).

Thucydides este un tool open source conceput pentru a face scrierea testelor automate de acceptanță și regresie mai ușoară. Acesta oferă caracteristici ce fac mult mai ușoară organizarea și structurarea testelor de acceptanță, asociindu-le cu user story-urile sau caracteristicile pe care le testează. Odată ce testele sunt executate Thucydides generează ilustrarea documentației descriind cum aplicația este folosită bazată pe story-urile descrise de teste.Framework-ul Thucydides observă și analizează testele de acceptanță și înregistrează o evidență detaliată a execuției lor – oferă un raport detaliat cu privire la rezultatele rulării testelor automate (Passed Test sunt cu culoarea verde, cele Failed ies în evidență prin culoarea Roșie)[Ferguson,2014] .

În ceea ce privește testarea de performanță s-a ales JMeter. Deasemenea la testarea anumitor funcționalități care nu erau foarte stabile (eram conștienți că UI-ul se va schimba frecvent) unde presupunea completarea de formulare cu date random pentru a micșora timpul s-a folosit DalekJS care este foarte simplu de utilizat.Practic se scriu rapid niște script-uri într-un singur cu JavaScript cu pașii din Test Case care să conțină niște funcții care completează cu date random pentru a se verifica rapid validările conform mai multor scenarii pentru a se economisi timpul (Selenium nu este recomandat pentru a testa automat părțile instabile deoarece mentenanța acelor teste este time consuming, scrierea testelor în Selenium este mai complexă la fel și actualizarea testelor). Când apar modificări în UI testele se pot actualiza rapid prin schimbarea elementelor din test conform modificărilor (modificările trebuie făcute într-un singur loc). DalekJS este un instrument UI open source scris în JavaScript care: lansează și automizează browser-ul, completează și trimite formulare, dă click și urmărește link-uri, capturează screenshot-uri, rulează teste funcționale pe toate SO[DalekJsDoc,2015]. Dezavantajul acestuia e că nu are o raportare a rezultatelor frumos ilustrată – rezultatele apare în linia de comandă unde sunt rulate sub forma de javaScript evidențiându-se pașii unde au apărut probleme pentru a fi investigate de testeri. Cu toate acestea script-urile din DalekJS tot sunt de ajutor pentru QA (completarea la nesfărșit de formulare cu date poate fi plictisitoare și testerii să își piardă interesul – automizarea cu Selenium știindu-se că nu e stabil UI-ul nu era o soluție deoarece timpul consumat cu actualizările testelor de câte ori era nevoie era ridicat).

3.3.2.2Setarea mediului de lucrupentru soluția de automatizare

(SeleniumWebdriver, Apache Maven+ Thucydides)

Soluția aleasă pentru structura proiectului de automation era compusă din următoarele instrumente principale: Selenium (instrument de automatizare open source) WebDriver (browser API automation) + Thucydides (rulează testele și generează rapoarte complexe automat). Întrucât datorită faptului că soluția aleasă a fost dezvoltată în Javapentru setarea environment-ului de testare trebuia să ne asigurăm că avem instalatși configurat Java Development Kit-ul. Deasemenea era nevoie de plugin-ul Apache Mavenpentru a putea ulterior să se ruleze testele din cmd. Apache Maven este un instrument de management și înțelegere de proiect software bazat pe conceptul unui POM (Project object model) care poate gestiona build-ul, raportarea și documentarea unui proiect de la o bucată centrală de informație[MavenDoc,2015].Apoi a fost nevoie de setarea variabilelor de sistem pentru Java, Maven și adăugarea unui nou Path (C:\apache-maven-3.3.3\bin;%JAVA%;%M2%).Deasemenea pentru setarea environment-ului de testare a fost nevoie de adăugarea plugin-ului de Thucydides pentru Maven (Trebuia adăugat ”net.thucydides.maven.plugins” înfișierul settings din folder-ul cu Maven după care am rulat comanda:

mvn clean verify thucydides:aggregate -Dmaven.test.failure.ignore=true în CMD).

După acestea environment-ul a fost pregătit și se putea genera proiectul de automation din cmd. Mediul de dezvoltare a testelor ales pentru proiectul de automation a fost Eclipse, așadar proiectul generat trebuia importat în Eclipse ca Maven Project. Testele au fost scrise în limbajul Java conform princiipiilor OOP. După setarea environment-ului și generarea proiectului de automation aveam o structură de test de bază care trebuia extinsă nevoilor aplicației e-commerce testate. Așadar s-au aplicat o serie de artificii de programare OOP structurii proiectului pentru a ajunge la o soluție de testare automată dezvoltă de colegii din departamentul de QA anterior.O persoană a fost responsabilă cu customizarea proiectului pentru ca mai apoi sa fie deploiată pe Git urmând a fi folosită de membri echipei de testare la dezvoltarea testelor.

3.3.2.3Arhitectura de testare

Întrucât automatizarea nu are sens dacă costă mai mult decât beneficiile pe care le oferă s-a ales o soluție ieftină cu un mix de tool-uricare să poată fi configurat. Structura unui proiect Selenium de automation implicit este următoarea:

Fig.2 – Structura unui proiect Selenium implicit

Pages => Page objects (conține identificareaelementelor web HTML)

Application.java => conține funcționalitățile cu teste ale aplicației

Steps =>conține pașii din test case-uri pentru fiecare funcționalitate

Tests => conținetestele (scrise conform cazurilor de testare)

Target => Report location => – target – site – thucydides– index.html

Resources – conține drivere și clase ajutătoare pentru teste ( de ex. webdriver-ulpentru chrome)

Apoi s-a configurat structura pentru a fi mai organizată și pentru a fi mai ușoară construcția și rularea de noi teste. Componentele testelor de Selenium au fost reconfigurate pe 3 module (Backoffice, FrontOffice și Tools). Așadar clasele cu pages, steps și workflows corespunzătoare pentru testarea funcționalităților ce țineau de frontoffice au fost create în modulul ”frontoffice” fiecare tip în submodul corespunzător (”pages”, ”steps” sau ”workflows”), iar cele care erau folosite în testele pentru testarea funcționalităților de back officeîn modulul de ”backoffice” .

Sub-modul ”workflows” conține anumite flow-uri din aplicație care sunt folosite la testarea altor funcționalități fără să fie nevoie să se rescrie acei pași pentru a economisi timp cum ar fi anumite precondiții (de exemplu pentru a testa funcționalitatea de plată utilizatorul trebuie să se logheze în aplicație dar atunci când s-a scris testul s-a apelat workflow-ul de login și a mai fost nevoie doar de scrierea pașilor caracteristici cazurilor de testare pentru funcționalitatea de plată). Și workflow-urile (grupuri de pași apelați într-o singură funcție) sunt organizate pe modulul caracteristic (back sau front office).

Modulul ”tools” conține diferite module și clase care conțin artificii pentru scrierea rapidă a testelor: Constants, RandomGenerator, etc (RandomGenerator generează automat text pentru a completa anumite input-uri).

Toate Constantele din aplicație vor fi scrise o singură dată în submodul ”constants” pentru a putea fi actualizate ușor și folositeoridecâte ori e nevoie la testele unde se cer în scenariul de testare. Folosirea datelor variabile de test sub formă de variabileeste un plus la mentenanța testelor. Pentru a se putea rula testele în mai multe browsere s-a adăugat în proiect driverele specifice (exemplu chromeDriver) și a trebuit configurat fișierul pom.xml corespunzător.

Structura proiectului de testare automată după ce a fostpersonalizat conform nevoilor de testare pentru aplicația de EB testată (la finalul proiectului) este ilustrată în cele ce urmează:

Fig.3 – Structura proiectului de TA personalizat

3.3.2.4Dezvoltarea și rularea testelor automate

Mediul de automatizare a fost scris cu scopul de a face scrierea noilor teste cu ușurință șide a oferi posibilitatea refolosirii unor metode deja scrise la mai multe teste după cum am explicat mai sus arhitectura. La scrierea script-urilor testerii au avut grijă să respecte elementele stabilite de comun acord pentru ca testele să fie reușite (configurarea testului: etapele necesare pentru a configura testul, executarea testului: pașii actuali ai testului din test case-ul stabilit, metoda de comparare: metoda pentru a compara rezultatele reale și așteptate (assertion-uri), precizarea clară a rezultatui așteptat al testului). Reutilizarea testelor era ușoară nu doar datorită artificiilor de programare aplicate la configurarea structurii proiectului de automation ci și prin faptul că se putea copia un test existent la care să se schimbe părți unde testul diferă și astfel practic s-a obținut un test nou într-un timp mult mai scurt).

Un dezavantaj pe care l-am observat pe parcursul dezvoltării testelor a fost faptul că testerii trebuiau formați să scrie corect testele conform structurii pentru a fi ușor refolosirea anumitor părți de către ceilalți testeri care lucrau pe aceeași structură (se facea code review de către persoana responsabilă cu configurarea structurii care avea o experiență mai mare cu testarea automată, fiecare test se și documenta și se discutau în fiecare zi în timpul întălnirilor de stand-up). Acest dezavantaj a fost un preț mult prea mic în comparație cu flexibilitatea câștigată prin automatizare. Odată ce un test a fost scris a putut fi adăugat în suita de teste automate a aplicației testate ușor (tester-ul comitea clasele noi și modificările createGit în brach-ul de automation).De fiecare dată când s-a dorit o testare de regresie completă s-a putut rula suita de teste fără probleme. Întrucât metoda de dezvoltare era Agile Scrum testele erau rulate la finalul fiecarui sprint pentru testarea de regresie pe toate enviroment-urile (cel de test și stage, precum și cel de producție) și browsere (FF, Chrome, Safari). Așadar la finalul fiecarui sprint după Demo la client și realese version se rula peste noapte suita de teste pentru a vedea ca totul este în regulă pe fiecare mediu. Deasemnea dacă se făcea bug-fixing foloseam suita de teste pentrua verifica dacă nu au apărut alte probleme în alte părți ale codului, sau rulam doar un test care a fost fixat, și în paralel testării făceau exploaratory testing. Dacă un test va fi rulat foarte rar atunci ROI (return on investment) al automatizării nu ar fi fost atât de evident.

Mediul de testare automată folosit ne permitea cu ușurință să scoatem din diferite motive teste din suită: dacă testul nu mai era valid, dacă s-a constatat că un test indica în mod eronat un eșec și trebuiau reparate greșelile de dezvoltare sau dacă acel test trebuia actualizat datorită schimbărilor apărute pe parcurs. Acest lucru s-a dovedit a fi un avantaj foarte mare însemnând că suita de teste putea fi rulată fără să fie întârziată de mentenanța testelor (chiar dacă desigur am avut de luat în considerare reducerea test coverage-ului). La începutul fiecărui sprint până se dezvoltau noi funcționalități se dezvoltau testele automate pentru funcționalitățile livrate în sprint-ul anterior (pentru că aveau o versiune stabilă). Experiența în cadrul testării a echipei a arătat de-a lungul timpului că una dintre deciziile cheie la testarea automată este deciderea cu privire la ce teste să se automatize și ce teste să se testeze manual. În pricipiu funcționalitățile se automatizau după ce aveau o variantă stabilă, în general funcționalitățile cele mai importante, care luau mult timp să fie testate manual (de exemplu Procesul de Checkout, Promoțiile).Trebuie precizat faptul că programatorii când au dezvoltat anumite funcționalități importante, complexe și sensibile (cum ar fi modalitățile de plată sau funcționalități de securitate) au scris și Unit Teste metodelor. Unit Testele au fost scrise doar pentru zonele sensibile din cauza timpului redus – Programatorul trebuia să se asigure că scriu suficiente teste pentru a acoperi toate cazurile și să se asigure că astfel metoda se va comporta corect chiar dacă aceasta va primi parametri absurdi. Tot programatorii au scris și teste de integrare (de exemplu verificara interacțiunilor dintre module sau clase).Testele de integrare Unit-level au în general cea mai bună rentabilitate a ROI. Testele care nu erau automatizate erau testate manual conform test case-urilor.

Framework-ul de lucru era foarte bine structurat și a oferit o serie de beneficii pe parcursul creării și mentenaței testelor automate.Testele erau organizate pe module, foarte bine structurate. În total am creat aproximativ 76 de teste JUnit (rularea sutei de teste cu toate acestea dura. 76 de teste nu este mult dar fiecare test reprezenta multe assertion-uri.Durata de execuție a fiecărui test depindea de complexitatea workflow-ului verificat de test – fiecare test cuprindea mai multe scenarii (de ex. 1 scenariu de la Checkout care presupunea căutarea unui produs, navigarea la pagina de detalii, adăugarea produsului în coș și completarea datelor pentru finalizarea comenzii dura aproximativ 40.23 sec).

Testele automate nu au fost negliajate pe tot parcursul proiectului făcându-se code refactor de câte ori s-a putut. Revizuirea rezultatelor după rularea testelor era simplă întrucât sistemul de automatizare generau automat un rezumat și test report detaliat ca rezultat al testării datorită integrării cu Thucydides. Acesta trebuia doar analizat ulterior. La finalul fiecărui sprint se trimitea un raport la client cu privire la situația procesului de testare.

Odată ce testele funcționale de automation erau sub control, s-a dorit automatizareatestării de performanță. Asta a fost o provocare pentru că nimeni din echipă nu mai făcuse asta așa că a fost nevoie de puțin research și un training rapid. Timpul petrecut cu research-ul nu a fost o pierdere de vreme datorită beneficiilor pe care le-a adus ulterior rularea testelor de performanță care erau aproape imposibil de realizat manual (de exemplu simulareaa 1000 utilizatori și simularea a 300 de accesări pe secundă). Prin realizarea testelor de performanță am observant faptul că testarea automată este mai puternică și mai versatilă – Un tester nu poate crea manual 100000 de utilizatori pentru a verifica dacă aplicația îndeplinește cerințele de performanță; mai precis, s-a putut verifica dacă generarea de statistici la acel număr de utilizatori va dura mai puțin de 2 secunde.Pentru testarea de performanță s-a alesutilizarea Jmeter.Testele de performanță nu au fost adăugate la sistemul de automatizare, dar au fost lăsate să fie administrate într-un mod semi-automat.

La testarea de regresie faptul că rulam suita de teste pe toate mediile (test și stage) ne oferea timp pentru exploratory testing al aplicației și mai mult timp pentru testarea fiecărui story și astfel rareori au intrat defecte în producție.

3.3.3 Procedura de colectare a datelor

Datele au fost colectate prin observarea directă pe parcursul dezvoltării aplicației (1 an și 4 luni). S-a urmărit procesul de testare a aplicației E-Businss de-a lungul ciclului de dezvoltare și s-a pus accent pe observarea progreselor și problemelor întâlnite la punerea în aplicare a testării automate. Pentru a evidenția progresele aveam nevoie de unele metrici (Numărul de teste JUnit, test pages, durata de execuție a testelor, funcționalități acoperite prin teste automate, productivitatea echipei). Așadar în studiul de caz se vor regăsi observațiile participative întrucât eu făceam parte din echipa de dezvoltare a aplicației selectate pentru studiu. Modalitățile obiective de identificare a rezultatelor cercetării se face prin evaluarea mai multor factori din ciclul de dezvoltare a aplicației evaluate: complexitatea aplicației, durata de dezvolatare a aplicației, metodele de dezvoltare, componența echipei de dezvoltare, TTM (time-to-market), costuri cu testarea, ROI, numărul de user stories per sprint, identificarea de bug-uri, timp alocat pentru testare, timpul necesar pentru testarea de regresie, atingerea scopului fiecărui sprint.

3.4 Rezultate

De cele mai multe ori în cazul testării automate nu se văd beneficiile de ansamblu. Dacă nu se fac teste automate QA-ul putea petrece mai mult timp cu testarea funcționalităților noi sau să gasească noi bug-uri. Este adevărat că viteza de testare a noilor functionalități/defecte fixate a scăzut în primele sprint-uri după introducerea testării automate, dar apoi viteza a crescut treptat și chiar s-a îmbunătățit. La început a fost puțină bătaie de cap cu începerea testării automate dar o certitudine e faptul că pe parcurs ce sprint-urile au înaintat numărul de teste automate de scris a devenit stabil și proporțional cu noile caracteristici. Numărul de teste care au fost scrise după cinci sprinturi a fost exact ceea ce era necesar pentru noile sarcini făcute în sprint-ul anterior conform strategiei stabilite. Am observat deasemenea că efortul cu testarea manuală scade după o perioadă ce testarea automată a fost introdusă. Cu cât se scriu mai multe teste cu atât se consumă mai puțin timp cu testarea manuală, timpul astfel economisit poate fi folosit la crearea unor teste noi sau la îndeplinirea altor task-uri pentru a crește calitatea fiecărei funcționalități pentru a reduce livrarea de bug-uri noi în producție.Calitatea software-ului (măsurată prin defecte) a fost deasemenea îmbunătățită semnificativ în principal prin combinarea testării automate și testării manuale. Prin soluția aplicată la automatizare aceasta a fost ușor de întreținut și timpul și costul de execuție au fost reduse condiderabil. Pentru mediul de automatizare este dificil să calculăm ROI (totul a fost open source, singurele cheltuieli fiind cele cu efortul de muncă depus de echipă).

Prin folosirea testelor automate la testarea de regresie echipa de QA a fost scutită de maratonul care era la finalul sprint-urilor pe parcurs ce aplicația s-a dezvoltat. Faptul că s-a trecut la automatizare pentru toate testele de regresie a fost un foarte mare avantaj. S-a economisit aproximativ 40% din timp care s-a putut folosi la alte activități.

Din experiența aceasta am observant că în ceea ce priveștecalitatea, aceasta s-a îmbunătățit pe de-o parteprin rularea periodică a testelor automate și pe de altă parte prin faptul că rămâne mai mult timp pentru testarea manuală (functional testing, exploratory testing). Costurile au fost reduse prin faptul că testarea automată reduce efortul manual și astfel sunt reduse și costurile procesului de testare și se îmbunătățesc timpii TTM prin găsirea unor bug-uri mai devreme – cu cât un bug este identificat mai devreme cu atât mai repede se poate fixa (și mai ieftin). Folosirea automatizării în proiect a îmbunătățit TTM prin faptul că s-au scurtat programările datelor de realease și s-au respectat termenele. Am observant deasemenea faptul că prin testarea automată motivația echipei de QA a fost îmbunătățită prin reducerea cantității de testare manuală care din cauza rutinei devine plictisitoare (repetarea flow-urilor după fiecare sprint din nou și din nou reduce implicarea și scade atenția). TTM-ului (durata de timp necesară de la conceperea și dezvoltarea unui produs până la scoaterea pe piață și vânzarea acestuia) a fost îmbunătățit prin faptul că rezultatele testelor erau obținute mai devreme ca rezultat al faptului că rezultatele suitei de teste automate erau disponibil mult mai repede decât echivalentul acelor teste executate manual.

Trebuie precizat că echipa de testare a avut o contribuție foarte semnificatică pentru reușita strategiei de testare: este un lucru cert faptul cătestarea automată poate crește contribuția dacă este facută bine (și desigur să o reducă dacă este făcută prost).

Capitolul 4 –Concluzii

În aceast studiu de caz am discutat despre testarea manaulă și testarea automată pentru a susține luarea controversatei decizii cu privire la automatizarea testelor. Beneficiile prezentate pe parcurs consider că răspund la întrebarea științifică aleasă. Dacă suntem adepții calității susțin cu tărie ca aplicațiile de tip E-Business să fie testate în mod corespunzător prin testarea manuală dar și testare automată .Testele automate pot contribui foarte mult la acoperirea test coverage-ului și îmbunătățirea calității aplicației. Testele automate vin ca un cost în avans și iau timp să se dezvolte și implementeze, însă investiția se va recupera în ceea ce privește volumul de muncă, costurile și timpul mai târziu în timpul ciclului de dezvoltare a produsului. Per ansamblu, testarea automatăeste mai rapidă și mai ieftină decât testarea manuală. Și aceasta ajută la asigurarea calității într-un mod în care testarea manuală nu o va putea face. Însă trebuie să rămână clar și faptul că chiar și atunci când sistemul este complet acoperit de teste automate tot va trebui efectuată testare manuală pentru identificarea bug-urilor (ex.problemele de UI ). Totuși, nu putem presupune că testarea manualăva fi vreodată capabilă să asigure beneficiile oferite de testele automate așa că și testarea automată trebuie inclusă în strategia de testare a aplicațiilor de E-Business. Testarea automată nu este cu siguranță un remediu final pentru toate problemele de asigurare a calității dar cu siguranță este indispensabilă pentru o strategie de testare reușită în cadrul procesului de dezvoltare a aplicațiilor E-Business.

BIBLIOGRAFIE

[KANER, 1996] Cem Kaner (1996), Articolul ”Quality Cost Analysis: Benefit and Risks”, Software QA, Volumul 3, Nr. 1 , p. 23

[Myers,2004] Glenford. J. Myers(2004), “ The Art of Software Testing – Second edition, Edtura “John Wiley & Sons, Inc”, p.19

[Beizer,1990] [Beizer,1990] Boris Beizer (1990),“Software Testing Techniques”, International Thomson Computer Press, p.17

[Graham&Fewster,2012] Dorothy Graham și Mark Fewster (2012), ”Experiences of Test Automation – Case Studies of Software Test Automation” , Addison-Wesley Professional, p. XXIX

[Graham&Fewster,1999] Dorothy Graham și Mark Fewster (1999), ”Software Test Automation: Effective Use ofTest Execution Tools”,Addison-Wesley Professional

[Sommerville,2010] Ian Sommerville (2010), SOFWARE ENGINEERING, Ediția a 9-a, 210, 652

[Whittaker,2009] James A. Whittaker (2009), ”Exploratory Software Testing~ Tips, Tricks, Tours, and Techniques to Guide Test Design”,Addison-Wesley Professional, 13, 14, 16

[Buraga,2005] Sabin Buraga (2005), “Proiectarea site-urilor Web – ediția a II-a”, Polirom, 87

[Lin&Wu&Chang,2011] C. C. Lin, H. Y. Wu, and Y. F. Chang (2011), ”The critical factors impact on online customersatisfaction”, Procedia Computer Science

[Farris,2010] P. W. Farris, N. T. Bendle, P. E. Pfeifer and D. J. Reibstein(2010), “Marketing metrics: The definitive guide to measuring marketing performance”, Pearson Education

[Hambling,2010] Brian Hambling-editor (2010), “SOFTWARE TESTING – An ISTQB–ISEB Foundation Guide (Second Edition)”, BCS The Chartered Institute for IT, 81, 82, 170

[Mosley&Posey,2002], Daniel J. Mosley și Bruce A. Posey(2002), “Just Enough Test Automation”(2002), Pearson, 9

[Kanglin&Menqi,2004], Wu(2004), “Effective Software Test Automation: Developing an Automated SoftwareTesting Tool”, Sybex, 17

[Kaner&Hung,2004], Cem Kaner, Jack Falk și Hung Quoc Nguyen (2004),“Testing Computer Software”,  International Thomson Computer Press, 138

[Glenford,2004], Glenford J. Myers (2004), "The Art of Software Testing, Second Edition", Word Association, Inc, 139

[Wiling,2008], Carla Wiling, “Introducing qualitative research…” (2008), p.74

[Boehm,1980], Virginia.R.Boehm, “Research in the „Real World” – a Conceptual Problem”, din cartea“Personnel Psychology”, vol. 33, 1980, Pitch, p. 496

[Yin,2009]Yin, Robert K., ”Case Study Research: Design and Methods” (2009), Sage Publications, p.240

[Flyvbjerg,2011], Flyvbjerg Bent, ‘Case Study’ din “The Sage Handbook of Qualitative Research – 4th Edition” (2011), Sage, p.301-316

[Kothari,2004], C.R.Kothari, “Research methodology – Methods and Techniques (second revised edition) (2004), New Age International Publishers, p.30

[Izak,Goldstein&Mead,1987], Izak Benbasat, David K. Goldstein și Melissa Mead (1987), “The Case Research Strategy in Studies of Information Systems” articol din cartea “MIS Quarterly” -Vol. 11, No. 3, publicit de ”Management Information Systems Research Center”, University of Minnesota, pp. 369-386

[Ferguson,2014], John Ferguson Smart (2014), “The Thucydides Reference Manual”, Wakaleo Consulting, p.12

Referințe Web

[SelediumDoc,2015], Documentație Selenium disponibilă la: http://docs.seleniumhq.org/

[Thucydides(Serenity)Doc,2015] http://thucydides.info/docs/serenity-staging/

[DalekJsDoc,2015], Documentație DalekJS disponibilă la http://dalekjs.com/index.html

[MavenDoc,2015], Documentație Maven disponibilă la https://maven.apache.org/

[Site1]-http://www.slideshare.net/youngculture/developing-enterprise-ecommerce-solutions-using-hybris-by-drazen-nikolic