ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 150
Numărul 149 Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 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 80
Abonament PDF

Asigurarea preventivă a calităţii

Rama Anem
Software Professional



TESTARE

General vorbind, QA (asigurarea calităţii) apare în peisaj după ce dezvoltarea este finalizată. Apoi, echipa QA testează funcţionalităţile implementate și găsește defecte la nivelul aplicaţiei. Astfel crește calitatea aplicaţiei dezvoltate. Este oare aceasta cea mai bună abordare? Reduce aceasta costurile? Răspunsul este "Nu". Atunci care ar fi metodele și procesele de urmat prin care un QA aduce cea mai bună calitate?

Dacă același defect ar fi fost identificat în etapa de stabilire a cerinţelor/specificaţiilor (requirements), costurile ar fi fost drastic reduse iar valoarea ar fi fost mai mare. Experienţa ne arată că tehnicile de testare proactive ar putea preveni multe greșeli în faza de dezvoltare și ar reduce timpul necesar creării și executării testelor, din moment ce un specialist QA este deja familiarizat cu toate cerinţele și problemele ascunse. Iată câteva exemple de schimbări la nivel de proces ce pot facilita tranziţia de la testarea reactivă la testarea proactivă:

  1. Înţelegerea informaţiei de business este cel mai important aspect pe care toată echipa, inclusiv echipa de QA, ar trebui să îl înveţe.

  2. Treceţi în revistă cerinţele/specificaţiile.

  3. Verificaţi orice deficienţă ce poate afecta funcţionalităţile vechi (deja implementate).

  4. Creaţi și revizuiţi testele înaintea etapei de dezvoltare.

  5. Validaţi cât de bine sunt acoperite specificaţiile.

  6. Monitorizaţi întrebările deschise sub formă de defecte cu un instrument de gestionare a proiectelor.

Membrii echipei ar trebui să fie experţi în domeniu.

A înţelege proiectul este cheia dezvoltării eficiente: echipa va lucra mai rapid dacă are documentaţie și dacă poate comunica eficient cu product ownerul. De asemenea, uneori, specificaţiile de business nu conţin informaţii evidente pentru un product owner, ceea ce face ca proiectul să fie deschis interpretării de către echipele de dezvoltare și QA. Organizarea de sesiuni de transfer de cunoștinţe cu product ownerul sau cu experţi în domeniu, transformarea specificaţiilor de business în specificaţii tehnice va aduce beneficii pe termen lung. Echipa de teste trebuie să cunoască produsul integral pentru calitate maximă. A înţelege proiectul din punct de vedere funcţional este cheia succesului echipei.

Două perechi de ochi sunt mai bune decât una singură.

Etapa de revizuire este o modalitate de a obţine o perspectivă nouă asupra problemelor sau de a identifica soluţii. Această etapă permite identificarea timpurie a greșelilor. Pot exista mai multe stagii de revizuire (QA manager -> echipa -> product owner) sau o singură revizuire ce implică echipa în totalitate sau în parte (în funcţie de mărimea echipei și de distribuţia responsabilităţilor). Aceasta va permite tuturor să fie pe aceeași lungime de undă, așa cum va arăta programatorilor care sunt așteptările echipei de QA referitor la dezvoltare.

Revizuirea atentă a specificaţiilor dă ocazia testerului de a găsi problemele potenţiale pe baza cunoștinţelor anterioare pe care le deţine despre produs. Problemele identificate în această etapă vor reduce semnificativ costurile și vor aduce valoare.

Specificaţiile nu sunt perfecte.

După cum am menţionat anterior, unele informaţii se pot pierde în timpul conversiunii specificaţiilor de business în specificaţii tehnice. În acest sens, sunt necesare clarificări realizate de echipa de QA. De obicei, există trei moduri pentru a solicita clarificări: email, ședinţe lungi sau monitorizarea fluxului de informaţie/documentaţie/progres printr-un instrument de gestiune. Ultima abordare este cea mai eficientă. Product ownerul și programatorii pot veni din domenii diferite și pot vorbi limbi diferite. Pregătirea subiectelor problematice pentru discuţii în cadrul unui instrument de monitorizare a sarcinilor de lucru va permite părţilor implicate să pregătească și să desfășoare ședinţe eficiente.

Gestionaţi corect regresia și pregătirea testelor.

Adăugarea de funcţionalităţi noi aduce cu sine riscul de a se defecta ceva existent, chiar și în proiectele ce conţin multe teste. Este dificil, dacă nu imposibil, să prezicem astfel de probleme:

Acoperiţi toată gama de specificaţii.

Echipa de teste poate petrece mult timp pentru a asigura acoperirea totală a funcţionalităţilor, ceea ce va avea un impact imens asupra echipei de dezvoltare, dar și asupra echipei de teste ce va identifica problemele posibile. Echipa de teste trebuie să ia în calcul și aspectele non-funcţionale precum: motoarele de căutare, aparatura, sistemele de operare, dimensiunea ecranului etc. . În ceea ce privește testarea API, se vor lua în calcul: testarea backend, testarea middle ware testing, etc.

Triaţi defectele.

Stabilirea defectelor cu un instrument de gestionare a acestora ajută echipa la monitorizarea și prioritizarea reparării lor. Triarea defectelor va permite clasificarea lor în funcţie de gradul de severitate. Mai mult, gestionarea defectelor ajută la măsurarea diferitelor aspecte ale muncii: volum, viteză, calitate, fiabilitate etc.

Concluzii

Nu există o "pastilă magică" pentru ca procesul QA să fie 100% eficient; toate instrucţiunile necesită ajustări specifice proiectului. Contează dinamica echipei și implicarea din partea PO în procesul de dezvoltare. Respectarea acestor instrucţiuni în spiritul Agile poate fi mai benefică decât respectarea unui proces cu orice preţ.

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects