Procesul de Testare în Context PDF

**1.4.2. Procesul de Testare în Context** Testarea nu este efectuată în izolare. Activitățile de testare sunt parte integrantă a proceselor de dezvoltare desfășurate în cadrul unei organizații. Testarea este finanțată de părțile interesate, iar scopul final este de a contribui la îndeplinirea nevoi...

**1.4.2. Procesul de Testare în Context** Testarea nu este efectuată în izolare. Activitățile de testare sunt parte integrantă a proceselor de dezvoltare desfășurate în cadrul unei organizații. Testarea este finanțată de părțile interesate, iar scopul final este de a contribui la îndeplinirea nevoilor lor de afaceri. Astfel, modul în care se desfășoară testarea depinde de mai mulți factori contextuali, inclusiv: - **Părțile interesate** (nevoi, așteptări, cerințe, disponibilitatea de a coopera etc.) - **Membrii echipei** (competențe, cunoștințe, nivel de experiență, disponibilitate, nevoile de instruire etc.) - **Domeniul de afaceri** (importanța critică a obiectului testat, riscuri identificate, nevoile pieței, reglementări legale specifice etc.) - **Factori tehnici** (tipul de software, arhitectura produsului, tehnologia utilizată etc.) - **Constrângeri ale proiectului** (scop, timp, buget, resurse etc.) - **Factori organizaționali** (structura organizației, politici existente, practici utilizate etc.) - **Ciclul de viață al dezvoltării software** (practici inginerești, metode de dezvoltare etc.) - **Instrumente** (disponibilitate, utilizabilitate, conformitate etc.) Acești factori influențează diverse aspecte legate de testare, inclusiv: strategia de testare, tehnicile de testare utilizate, gradul de automatizare a testării, nivelul necesar de acoperire, detalierea documentației de testare, raportarea etc. **1.4.3. Testware** **Testware-ul** reprezintă produsele de lucru generate ca rezultat al activităților de testare descrise în secțiunea 1.4.1. Modul în care diferite organizații produc, modelează, denumesc, organizează și gestionează aceste produse de lucru variază semnificativ. O gestionare adecvată a configurației (vezi secțiunea 5.4) asigură consistența și integritatea produselor de lucru. Următoarea listă de produse de lucru nu este exhaustivă: - **Produsele de planificare a testelor** includ: planul de testare, programul testelor, registrul de riscuri și criteriile de intrare și ieșire (vezi secțiunea 5.1). Registrul de riscuri este o listă de riscuri împreună cu probabilitatea, impactul acestora și informații despre mitigare (vezi secțiunea 5.2). - **Produsele de monitorizare și control** includ: rapoartele de progres (vezi secțiunea 5.3.2), documentația directivei de control (vezi secțiunea 5.3) și informații despre riscuri (vezi secțiunea 5.2). - **Produsele de analiză a testelor** includ: condiții de testare (prioritizate), cum ar fi criteriile de acceptare (vezi secțiunea 4.5.2), și rapoarte privind defectele din baza de testare (dacă nu sunt corectate direct). - **Produsele de proiectare a testelor** includ: cazuri de testare prioritizate, scenarii de testare, elemente de acoperire, cerințe de date și cerințe pentru mediul de testare. - **Produsele de implementare a testelor** includ: proceduri de testare, scripturi automate, suite de teste, date de testare, programul de execuție a testelor și elemente ale mediului de testare (ex.: stubs, drivere, simulatoare, virtualizări de servicii). - **Produsele de execuție a testelor** includ: jurnale de testare și rapoarte de defecte (vezi secțiunea 5.5). - **Produsele de finalizare a testelor** includ: raportul de finalizare a testelor (vezi secțiunea 5.3.2), elemente de acțiune pentru îmbunătățirea proiectelor sau iterațiilor viitoare, lecții învățate documentate și cereri de schimbare (ex.: elemente din backlog-ul produsului). **1.4.4. Trasabilitatea între Baza de Testare și Testware** Pentru a implementa un control și o monitorizare eficiente, este important să se stabilească și să se mențină trasabilitatea pe parcursul procesului de testare între elementele bazei de testare, testware-ul asociat (ex.: condiții de testare, riscuri, cazuri de testare), rezultatele testelor și defectele detectate. Trasabilitatea precisă sprijină evaluarea acoperirii și este foarte utilă dacă în baza de testare sunt definite criterii măsurabile de acoperire. Aceste criterii pot funcționa ca indicatori-cheie de performanță pentru a ghida activitățile ce demonstrează măsura în care obiectivele testării au fost atinse (vezi secțiunea 1.1.1). Exemple: - Trasabilitatea cazurilor de testare la cerințe poate verifica faptul că cerințele sunt acoperite de cazurile de testare. - Trasabilitatea rezultatelor testelor la riscuri poate evalua nivelul de risc rezidual dintr-un obiect testat. În plus, trasabilitatea bună facilitează evaluarea impactului schimbărilor, auditarea testelor și conformarea cu criteriile de guvernanță IT. Aceasta sprijină rapoartele privind progresul și finalizarea testării prin includerea stării elementelor bazei de testare, ajutând la comunicarea aspectelor tehnice către părțile interesate într-un mod ușor de înțeles. Trasabilitatea oferă informații pentru evaluarea calității produsului, capacității procesului și progresului proiectului față de obiectivele de afaceri. **1.4.5. Roluri în Testare** Acest curriculum acoperă două roluri principale în testare: rolul de **management al testării** și rolul de **testare**. Activitățile și sarcinile asociate cu aceste roluri depind de factori precum contextul proiectului și produsului, competențele persoanelor din aceste roluri și organizația în care activează. - **Rolul de management al testării** implică responsabilitatea generală pentru procesul de testare, echipa de testare și conducerea activităților de testare. Se concentrează în principal pe planificare, monitorizare și control, precum și pe finalizarea testelor. În dezvoltarea Agile, unele sarcini pot fi gestionate de echipa Agile, iar cele ce implică mai multe echipe sau întreaga organizație pot fi realizate de manageri de testare externi echipei de dezvoltare. - **Rolul de testare** este responsabil pentru aspectele inginerești (tehnice) ale testării, cu focus pe analiză, proiectare, implementare și execuție a testelor. Rolurile pot fi preluate de persoane diferite în momente diferite. De exemplu, rolul de management poate fi îndeplinit de un lider de echipă, un manager de testare sau un manager de dezvoltare. Este, de asemenea, posibil ca o singură persoană să îndeplinească ambele roluri simultan. **1.5. Abilități esențiale și bune practici în testare** **Abilitatea** reprezintă capacitatea de a face ceva bine, dobândită prin cunoștințe, practică și aptitudini. Testatorii buni ar trebui să dețină anumite abilități esențiale pentru a-și îndeplini sarcinile eficient. De asemenea, ar trebui să fie membri eficienți ai echipei și să poată efectua testări la diferite niveluri de independență. **1.5.1. Abilități generale necesare pentru testare** Deși generale, următoarele abilități sunt deosebit de relevante pentru testatori: - **Cunoștințe de testare** (pentru a crește eficiența testării, de exemplu, utilizând tehnici de testare). - **Atenție, meticulozitate, curiozitate, atenție la detalii, metodologie** (pentru a identifica defecte, mai ales pe cele greu de detectat). - **Abilități bune de comunicare, ascultare activă, spirit de echipă** (pentru a interacționa eficient cu toți stakeholderii, a transmite informații și a raporta sau discuta defecte). - **Gândire analitică, critică și creativă** (pentru a crește eficacitatea testării). - **Cunoștințe tehnice** (pentru a crește eficiența testării, de exemplu, utilizând instrumentele potrivite). - **Cunoștințe despre domeniu** (pentru a înțelege și comunica eficient cu utilizatorii finali/reprezentanții de business). Testatorii joacă adesea rolul mesagerilor de vești proaste. Este o trăsătură comună să fie învinovățit cel care aduce vești proaste. Aceasta face ca abilitățile de comunicare să fie esențiale pentru testatori. Rezultatele testării pot fi percepute ca o critică a produsului și a autorului acestuia. Biasul de confirmare poate face dificilă acceptarea informațiilor care contrazic convingerile existente. Unii oameni pot percepe testarea ca pe o activitate distructivă, deși aceasta contribuie semnificativ la succesul proiectului și la calitatea produsului. Pentru a îmbunătăți această percepție, informațiile despre defecte și erori ar trebui comunicate într-un mod constructiv. **1.5.2. Abordarea întregii echipe** O abilitate importantă pentru un testator este capacitatea de a lucra eficient într-un context de echipă și de a contribui pozitiv la atingerea obiectivelor acesteia. **Abordarea întregii echipe** -- o practică provenind din **Extreme Programming** -- se bazează pe această abilitate. În abordarea întregii echipe, orice membru al echipei care are cunoștințele și abilitățile necesare poate îndeplini orice sarcină, iar toți sunt responsabili pentru calitate. Membrii echipei împart același spațiu de lucru (fizic sau virtual), deoarece co-localizarea facilitează comunicarea și interacțiunea. Abordarea întregii echipe îmbunătățește dinamica echipei, sporește colaborarea și comunicarea și creează sinergii prin valorificarea seturilor de abilități diverse în beneficiul proiectului. Testatorii colaborează strâns cu ceilalți membri ai echipei pentru a asigura atingerea nivelurilor dorite de calitate, inclusiv lucrând cu reprezentanți ai afacerii pentru a crea teste de acceptare adecvate și cu dezvoltatorii pentru a stabili strategia de testare și pentru a decide metodele de automatizare a testării. Această colaborare permite transferul de cunoștințe de testare către ceilalți membri ai echipei și influențează dezvoltarea produsului. În funcție de context, abordarea întregii echipe poate să nu fie întotdeauna potrivită. De exemplu, în anumite situații, cum ar fi cele critice pentru siguranță, poate fi necesar un nivel ridicat de independență a testării. **1.5.3. Independența testării** Un anumit grad de independență face ca testatorul să fie mai eficient în identificarea defectelor datorită diferențelor dintre biasurile cognitive ale autorului și ale testatorului. Independența nu este însă un substitut pentru familiaritate -- de exemplu, dezvoltatorii pot identifica eficient multe defecte în propriul cod. Produsele de lucru pot fi testate de: - Autorul lor (fără independență). - Colegii autorului din aceeași echipă (un grad de independență). - Testatori din afara echipei autorului, dar din aceeași organizație (independență ridicată). - Testatori din afara organizației (independență foarte ridicată). Pentru cele mai multe proiecte, este ideală utilizarea mai multor niveluri de independență (de exemplu, dezvoltatorii testând componente, echipa de testare testând sistemul, iar reprezentanții afacerii realizând testarea de acceptare). **Beneficiile independenței testării:** - Testatorii independenți pot recunoaște tipuri diferite de defecte, datorită experienței și perspectivelor tehnice diverse. - Un testator independent poate verifica, provoca sau infirma ipotezele stakeholderilor în timpul specificării și implementării sistemului. **Dezavantajele independenței testării:** - Testatorii independenți pot fi izolați de echipa de dezvoltare, ceea ce poate duce la probleme de comunicare sau relații adversariale. - Dezvoltatorii pot pierde simțul responsabilității pentru calitate. - Testatorii independenți pot fi percepuți ca un obstacol sau învinovățiți pentru întârzierile în lansare. **Cap 2.** **2.1. Testarea în contextul ciclului de viață al dezvoltării software (SDLC)** Un **model de ciclu de viață al dezvoltării software (SDLC)** este o reprezentare abstractă și de nivel înalt a procesului de dezvoltare software. Un model SDLC definește cum diferitele faze de dezvoltare și tipurile de activități asociate acestora se relaționează logic și cronologic. Exemple de modele SDLC: - **Modele de dezvoltare secvențială** (e.g., modelul cascadă, modelul V). - **Modele de dezvoltare iterativă** (e.g., modelul spirală, prototiparea). - **Modele de dezvoltare incrementală** (e.g., Procesul Unificat - Unified Process). Unele activități din procesele de dezvoltare software pot fi descrise și prin metode de dezvoltare mai detaliate și practici Agile, cum ar fi: - Dezvoltarea condusă de teste de acceptare (**ATDD**). - Dezvoltarea condusă de comportament (**BDD**). - Proiectarea condusă de domeniu (**DDD**). - Programarea extremă (**XP**). - Kanban, Lean IT, Scrum, Dezvoltarea condusă de teste (**TDD**). **2.1.1. Impactul ciclului de viață al dezvoltării software asupra testării** Testarea trebuie să fie adaptată la modelul SDLC utilizat pentru a avea succes. Alegerea SDLC-ului influențează: - **Domeniul de aplicare și momentul activităților de testare** (de exemplu, nivelurile și tipurile de testare). - **Nivelul de detaliere a documentației de testare.** - **Alegerea tehnicilor de testare și abordării testării.** - **Gradul de automatizare a testării.** - **Rolul și responsabilitățile unui testator.** **În modelele de dezvoltare secvențială**, în fazele inițiale, testatorii participă de obicei la: - Revizuirea cerințelor. - Analiza testării și proiectarea testelor. Codul executabil este creat în fazele ulterioare, astfel încât testarea dinamică nu poate fi efectuată devreme în SDLC. **În modelele de dezvoltare iterativă și incrementală**, fiecare iterație livrează de obicei un prototip sau un increment de produs. Aceasta implică faptul că în fiecare iterație pot fi efectuate atât testări statice, cât și dinamice, la toate nivelurile de testare. Livrarea frecventă de incrementuri necesită: - Feedback rapid. - Testare extensivă de regresie. **În dezvoltarea Agile**, se presupune că schimbările pot apărea pe parcursul proiectului. Din acest motiv: - Documentația produsului de lucru este minimalistă. - Automatizarea testării este extinsă pentru a ușura testarea de regresie. - Majoritatea testărilor manuale se realizează folosind **tehnici de testare bazate pe experiență** care nu necesită analize și designuri extensive prealabile ale testării. **2.1.2. Ciclul de viață al dezvoltării software și bunele practici de testare** Indiferent de modelul SDLC ales, următoarele **bune practici** sunt recomandate: - **Pentru fiecare activitate de dezvoltare există o activitate corespunzătoare de testare**, astfel încât toate activitățile de dezvoltare să fie supuse unui control al calității. - **Diferitele niveluri de testare** au obiective specifice și diferite, permițând testarea să fie suficient de cuprinzătoare fără a genera redundanță. - **Analiza și proiectarea testelor** pentru un anumit nivel de testare încep în faza corespunzătoare de dezvoltare, permițând respectarea principiului **testării timpurii**. - Testatorii participă la **revizuirea produselor de lucru** de îndată ce acestea sunt disponibile ca proiecte, sprijinind astfel strategia de **shift-left**. **2.1.3. Testarea ca factor de conducere a dezvoltării software** **TDD, ATDD și BDD** sunt abordări de dezvoltare similare, în care testele sunt definite pentru a direcționa dezvoltarea. Aceste abordări implementează **principiul testării timpurii** și urmează o **strategie shift-left**, deoarece testele sunt definite înainte de scrierea codului. Ele susțin un model de dezvoltare iterativ. **Test-Driven Development (TDD):** - Ghidează scrierea codului prin cazuri de testare, în loc de design extensiv (Beck 2003). - Testele sunt scrise înainte, codul este apoi scris pentru a satisface testele, după care urmează procesul de refactorizare. **Acceptance Test-Driven Development (ATDD):** - Derivează testele din criteriile de acceptare ca parte a procesului de proiectare a sistemului (Gärtner 2011). - Testele sunt scrise înainte de dezvoltarea părților aplicației pentru a le satisface. **Behavior-Driven Development (BDD):** - Exprimă comportamentul dorit al aplicației cu ajutorul cazurilor de testare scrise într-un limbaj natural simplu (de obicei utilizând formatul **Given/When/Then**). - Cazurile de testare sunt apoi traduse automat în teste executabile. Testele rezultate din aceste abordări pot persista ca teste automate, asigurând calitatea codului în adaptările sau refactorizările viitoare. **2.1.4. DevOps și testarea** **DevOps** este o abordare organizațională care creează sinergie între dezvoltare (inclusiv testare) și operațiuni, pentru atingerea unor obiective comune. Aceasta necesită o **schimbare culturală** în organizație pentru a elimina barierele dintre dezvoltare și operațiuni, tratându-le ca funcții de valoare egală. **DevOps** promovează: - **Autonomia echipelor.** - **Feedback rapid.** - **Toolchains integrate.** - Practici tehnice precum **integrarea continuă (CI)** și **livrarea continuă (CD)**. Din perspectiva testării, **DevOps** aduce beneficii precum: - Feedback rapid privind calitatea codului. - Automatizarea proceselor prin CI/CD, reducând nevoia de testare manuală repetitivă. - Vizibilitate sporită asupra caracteristicilor de calitate non-funcționale (e.g., performanță, fiabilitate). - Reducerea riscurilor de regresie datorită testelor automate extinse. Cu toate acestea, DevOps are și provocări, inclusiv: - Necesitatea definirii și stabilirii unui pipeline de livrare DevOps. - Mentenanța instrumentelor CI/CD și a testării automate. Deși DevOps se bazează pe un nivel ridicat de automatizare, testarea manuală din perspectiva utilizatorului rămâne importantă. **2.1.5. Abordarea shift-left** **Principiul testării timpurii** este denumit uneori **shift-left**, sugerând că testarea trebuie realizată mai devreme în SDLC. Shift-left presupune testare mai timpurie, fără a neglija testarea din etapele ulterioare. **Exemple de bune practici shift-left:** - Revizuirea specificațiilor din perspectiva testării pentru a identifica defecte precum ambiguități sau inconsistențe. - Scrierea cazurilor de testare înainte de scrierea codului și rularea acestuia într-un mediu de testare. - Utilizarea CI/CD pentru feedback rapid și teste automate ale componentelor. - Realizarea analizei statice a codului sursă înainte de testarea dinamică. - Începerea testării non-funcționale la nivelul de testare a componentelor, dacă este posibil. Deși abordarea **shift-left** poate necesita eforturi suplimentare sau costuri mai mari în etapele inițiale, se estimează economii semnificative pe termen lung. **2.1.6. Retrospective și Îmbunătățirea Proceselor** Retrospectivele (cunoscute și ca „întâlniri post-proiect" sau „retrospective de proiect") se desfășoară frecvent la sfârșitul unui proiect, unei iterații sau unui moment de lansare, dar pot avea loc și atunci când este necesar. Calendarul și organizarea retrospectivei depind de modelul SDLC (Ciclul de Viață al Dezvoltării Software) urmat. În cadrul acestor întâlniri, participanții (nu doar testeri, ci și dezvoltatori, arhitecți, proprietari de produse, analiști de business etc.) discută: - Ce a fost de succes și ar trebui păstrat? - Ce nu a fost de succes și ar putea fi îmbunătățit? - Cum se pot implementa îmbunătățirile și păstra succesul în viitor? Rezultatele trebuie înregistrate și, de obicei, fac parte din raportul de finalizare a testării (vezi secțiunea 5.3.2). Retrospectivele sunt esențiale pentru implementarea cu succes a îmbunătățirii continue, iar recomandările făcute trebuie să fie urmărite. Beneficiile tipice pentru testare includ: - Creșterea eficienței și a eficacității testării (prin implementarea sugestiilor pentru îmbunătățirea proceselor). - Îmbunătățirea calității documentației de testare (prin revizuirea comună a proceselor de testare). - Consolidarea echipei și învățarea (prin oportunitatea de a ridica probleme și de a propune puncte de îmbunătățire). - Îmbunătățirea calității bazei de testare (prin identificarea și rezolvarea deficiențelor din cerințe). - O mai bună colaborare între dezvoltare și testare (prin revizuirea și optimizarea regulată a colaborării). **2.2. Niveluri și Tipuri de Testare** Nivelurile de testare reprezintă grupuri de activități de testare organizate și gestionate împreună. Fiecare nivel de testare este o instanță a procesului de testare, realizată în raport cu software-ul aflat într-o anumită etapă de dezvoltare, de la componente individuale la sisteme complete sau, unde este cazul, la sisteme integrate. Tipurile de testare reprezintă grupuri de activități de testare axate pe caracteristici specifice de calitate, care pot fi aplicate la orice nivel de testare. **2.2.1. Niveluri de Testare** În acest material, sunt descrise următoarele cinci niveluri de testare: 1. **Testarea componentelor** (cunoscută și ca testare unitară): - Se concentrează pe testarea componentelor în izolare. - Necesită suport specific, precum cadre de testare unitară. - Este realizată, de obicei, de dezvoltatori în mediile lor de dezvoltare. 2. **Testarea integrării componentelor**: - Se axează pe testarea interfețelor și interacțiunilor dintre componente. - Depinde de strategii de integrare, precum abordările de jos în sus, de sus în jos sau integrarea „big-bang". 3. **Testarea sistemului**: - Evaluează comportamentul general și capacitățile unui sistem complet. - Include testarea funcțională a sarcinilor cap-coadă și testarea non-funcțională a caracteristicilor de calitate. - Poate implica simulări ale subsistemelor sau un mediu de testare reprezentativ. 4. **Testarea integrării sistemului**: - Verifică interfețele dintre sistemul de testare și alte sisteme sau servicii externe. - Necesită medii de testare adecvate, asemănătoare cu mediul operațional. 5. **Testarea de acceptanță**: - Se concentrează pe validare și pe demonstrarea pregătirii pentru implementare. - Este realizată, ideal, de utilizatorii finali și include forme precum testarea de acceptanță a utilizatorului (UAT), testarea operațională, testarea contractuală și de reglementare, testarea alfa și beta. **2.2.2. Tipuri de Testare** În proiecte pot fi aplicate multe tipuri de testare. În acest material, se tratează următoarele patru tipuri: 1. **Testarea funcțională**: - Evaluează funcțiile pe care un component sau un sistem ar trebui să le îndeplinească. - Se concentrează pe completitudinea funcțională, corectitudinea și adecvarea funcțională. 2. **Testarea non-funcțională**: - Evaluează caracteristici ale calității software-ului, altele decât cele funcționale. - Exemple de caracteristici non-funcționale: performanță, compatibilitate, utilizabilitate, fiabilitate, securitate, mentenabilitate, portabilitate. 3. **Testarea de confirmare**: - Confirmă că un defect a fost corectat cu succes. 4. **Testarea de regresie**: - Asigură că nicio schimbare efectuată nu a cauzat consecințe adverse, inclusiv în componentele conexe sau în medii externe.