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

Transformarea Testării în DevOps

Lucian Ghindă
Trainer @ ANIS



TESTARE

Într-un context DevOps, testarea a evoluat și va continua să evolueze trecând de la un rol făcut de o singură persoană la taskuri de testare făcute de toată lumea din echipă. Motivul pentru o astfel de schimbare este dat chiar de scopul principal al unei echipe DevOps , care este acela de a găsi cea mai rapidă cale de la o idee către lansarea acesteia în producție. În acest context, pentru a avea un produs de calitate și cu cât mai puține defecte, gata de lansare în orice moment, trebuie ca toată lumea să includă testarea (în diverse forme) în responsabilitățile de zi cu zi. Pe scurt, toată lumea trebuie să facă testare într-un astfel de mediu. Aceasta este prima transformare a testării.

Într-un astfel de mediu de tip "Continuous Everything" singurul mod de a obține un astfel de proces este prin dezvoltarea testării automate pe toate nivelele produsului (de la unit testing la acceptanță). Testarea automată presupune cunoștințe tehnice cel puțin medii (programare, arhitectură, baze de date, etc.) și, prin acoperirea tot mai mare și preluarea unor taskuri de la tester, deschide calea acestuia de a se orienta spre o înțelegere mai bună a utilizatorului sau grupului țintă căruia îi este adresat produsul dezvoltat.

Riscurile acestei transformări

Transformarea unui rol atrage după sine foarte multe consecințe care afectează echipele sau oamenii. Este în același timp și un moment oportun de a identifica noi direcții de pregătire și o ocazie bună să definim cine și ce trebuie să știe pentru a asigura o calitate bună a produselor dezvoltate.

Mai departe, analizăm două posibile riscuri ridicate de această transformare, care pot avea un impact semnificativ în rezultatele unui proces de testare. De asemenea, vom lua în considerare și propuneri de temperare a acestora.

Primul risc se referă la subiectivismul și erorile de logică care influențează modul în care se alege ce se testează sau cu ce valori se testează sau strategia de testare.

Al doilea risc îl reprezintă posibila lipsă de claritate în ce privește rolul testerului într-o astfel de echipă în care mai multe persoane fac testare ca parte a jobului de dezvoltare sau de administrare.

Subiectivismul în testare

Subiectivismul este generat de fluiditatea rolurilor în echipele DevOps, mai exact de trecerea la testare automată și integrarea testerului în echipa de dezvoltare și de complexitatea utilizatorilor sau soluțiilor implementate.

Într-un mediu în care toată lumea face testare, există o probabilitate mare ca scenariile alese să fie afectate de erori de logică sau de subiectivism. Ce înseamnă asta? Poate însemna, de exemplu, că persoana care dezvoltă o anumită componentă va tinde să aleagă scenarii de testare care vor demonstra că implementarea făcută este corectă. Ceea ce este foarte diferit de a testa corectitudinea implementării. Este o situație normală care se poate întâmplă unui programator, unui inginer de sistem, unui administrator de rețea și în general oricărei persoane care construiește un sistem și apoi dorește să verifice sistemul respectiv.

O listă posibilă de cauze include distorsiunile cognitive și erorile logice. Majoritatea duc la decizii rapide și involuntare care afectează procesul de analiză sau de generare de idei chiar înainte ca acesta să înceapă. În mod concret, alegerea unui scenariu de testare este predeterminată de acești factori și scade probabilitatea găsirii unui defect.

Modalități de combatere a subiectivismului

Învățarea metodelor, tipurilor de testare și înțelegerea cazurilor în care se aplică

Aceasta presupune ca toată echipa să aibă cunoștințe, cel puțin de bază, despre tipuri de testare și tehnici de design ale testelor. Cu o concentrare sporită pe înțelegerea cât mai bună a cazurilor în care o tehnică sau alta este mai eficientă, atât în situațiile generale, cât și în cele specifice domeniului din care face parte produsul/serviciul dezvoltat.

Această învățare este importantă pentru că fără aceste concepte, unei persoane îi este greu sau imposibil să aleagă un design eficient din posibilități pe care nu le înțelege. Cel mai probabil este să execute doar testele pe care le înțelege, ceea ce înseamnă un risc mai mare să atingă doar o anumită categorie de bug-uri. Această situație este cunoscută, la modul general, sub denumirea de "availability heuristic" și a fost studiată de către Daniel Kahneman și Amos Tversky începând cu 1960 [Gilovich, Thomas; Griffin, Dale; Kahneman, Daniel (2002-07-08). Heuristics and Biases: The Psychology of Intuitive Judgment].

Așadar, prima recomandare este ca toată echipa, indiferent de rolul pe care îl are (mai ales într-o echipă multi funcțională) să treacă printr-un training de testare.

Învățarea de statistică și probabilități pentru diminuarea efectelor prejudecăților

A doua recomandare înseamnă învățarea/aprofundarea probabilităților și matematicii (în special lucrul cu mulțimi/grupuri și matrice).

Motivul acestei recomandări ține chiar de modul în care se aleg cazurile sau valorile cu care se testează. Deseori se aleg doar valorile cele mai probabile pentru dezvoltatorul sau testerul care urmează să scrie scenariul de testare, ceea ce este o greșeală pentru că ar trebui alese cele mai probabile cazuri pentru grupul de utilizatori care vor folosi aplicația. Acesta este doar un exemplu în care subiectivismul, erorile logice și silogismele afectează posibilitatea de a descoperi erori relevante pentru utilizatori.

Evoluția rolului de tester în DevOps

Ceea ce am descris mai sus este util mai ales pentru scrierea testelor automate (sau automatizate?). Dar dacă se execută doar testare automată, atunci se ajunge din nou într-o situație interesantă: când există un număr mare de utilizatori este foarte probabil ca unii dintre ei să facă acțiuni foarte creative, diverse prin aplicație. De obicei, astfel de acțiuni/cazuri nu sunt luate în considerare de testarea automată și în multe situații sunt foarte greu de automatizat.

În această situație, soluția este testarea bazată pe experiență în care cel care testează are libertatea de a fi creativ, de a genera cazuri de test ciudate, paradoxale, puțin probabile și de a-și explora mai mult curiozitatea în direcția lui "Ce-ar fi dacă ...?".

Înțelegerea nevoilor de bază ale utilizatorului este un element esențial într-o echipă DevOps care are ca scop să parcurgă cât mai repede și cât mai bine drumul de la o idee/cerință de business la o lansare cu succes.

În această situație, alegerea cazurilor de testare, a metricilor de acoperire, devine în mod necesar legată de capacitatea testerului de a înțelege cât mai bine nevoile utilizatorului și de a decide cea mai mică arie de testat ce asigură cea mai mare acoperire de riscuri (zone predispuse la erori).

Rolul testerului ar trebui să evolueze mai ales către o specializare în testarea bazată pe experiență, generarea creativă de cazuri de test și înțelegerea foarte bună a utilizatorilor produsului dezvoltat.

Ce urmează

Pe măsură ce instrumentele de testare vor evalua, testarea automată va ajunge și ea să fie făcută cât mai repede și complet integrată în toate fazele și nivelele unui produs indiferent de metodologia de implementare.

În acest context, pentru a avea o viteză mare în implementarea și lansarea unor soluții IT, a fi tester devine un job strategic.

LANSAREA NUMĂRULUI 141

Analiza de business (BA)

miercuri, 27 martie, ora 18:00

sediul Accesa

Facebook Meetup StreamEvent YouTube

NUMĂRUL 140 - Generative AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO