De ce să alegeți calitatea peste cantitate în testarea software-ului?

Fiind în industria software-ului ca parte a asigurării calității, este de așteptat să purtați întotdeauna un stick de calitate pentru a vă asigura că calitatea este menținută până la „T”. Ni se cere întotdeauna să ne punem în locul clienților și să ne asigurăm că produsul / proiectele îndeplinesc așteptările sale cu cea mai înaltă calitate realizată.

Dar ironia reală stă în care toate valorile noastre de calitate se rezumă la numere cantitative și termeni precum bug-uri înregistrate, un număr de cazuri de test scrise, un număr de cazuri de testare executat, timpul petrecut la testare, adresele URL testate, browserele verificate pentru testarea încrucișată a browserului, scurgerea defectelor etc.

Ne-am proiectat sistemul de lucru în care ni se cere să plasăm calitatea peste cantitate, dar în cele din urmă suntem analizați pe abordarea cantitativă. Cred că concentrarea pe abordarea cantitativă pentru testare este nedreaptă pentru echipa dvs. de testare a software-ului și chiar dacă urmăm abordarea cantitativă, trebuie să existe o modalitate sistematică de a judeca efortul individual depus pe baza valorilor noastre de testare a software-ului.

Este în regulă să justificăm valorile noastre de testare a software-ului numai cu numerele?

Trebuie să ne întrebăm cum să justificăm abordarea noastră de testare în care fiecare cale a fost vizualizată cantitativ? Acesta este unul dintre motivele pentru care calitatea testării s-a redus drastic. Un exemplu simplu ar putea fi atunci când măsurați eficiența sau eficacitatea echipei dvs. cu numărul de erori înregistrate.

Prima abordare pe care o va lua fiecare membru al echipei dvs. este aceea de a găsi cât mai multe bug-uri pe care le poate oriunde în aplicație. Știu că mulți s-ar certa afirmând, cum contează până când găsim erori în aplicația web. Dar, în cele din urmă, aici intervine calitatea testării.

Privind abordarea agilă de dezvoltare software la care lucrăm în aceste zile, cu cicluri de reducere și teste care au fost împinse până la sfârșitul fiecărui ciclu, tot ce ne-a rămas este presiunea aparent ridicată pentru a testa aplicațiile în cel mai scurt interval disponibil . Efectuăm toate aceste teste bazate pe risc și testarea fumului pentru fiecare versiune pentru a ne asigura că aplicația oferă o experiență perfectă utilizatorilor săi finali.

Conducerea echipei cu acest sistem de numerotare nu va ajuta în astfel de situații cruciale. Nu numărul este cel care contează, ci esența fiecărui bug care poate provoca nivelul de întrerupere dacă este transmis clientului . Așadar, chiar dacă am putea ridica numărul „x” de bug-uri în găleată, s-ar putea să fi greșit extrem de mult atunci când livrăm un produs din punct de vedere al calității, din cauza abordării mentalității pe care am stabilit-o în timp ce ne căutăm aplicația. Acesta este unul dintre cele mai mari motive care trebuie luate în considerare la definirea valorilor noastre de testare a software-ului în care calitatea ar trebui să depășească cantitatea oricând.

Astăzi, abordarea menținerii calității este complet diferită și vorbește doar în ceea ce privește satisfacția părților interesate. Calitatea este complet orientată către clienți . Calitatea este egală cu profiturile conform părților interesate. Cu cât calitatea este mai înaltă, este nivelul de predictibilitate al software-ului, ceea ce înseamnă că se poate asuma un risc în ceea ce privește jocul de stabilire a prețurilor pe piață .

Părțile interesate ar ști unde se află în ceea ce privește stabilitatea produsului și cât de aprofundat poate împinge produsul pe piață. Dar acest lucru se pierde complet din cauza modului în care începem să lucrăm în timp ce demarăm proiectul, care colectează cerințe, definește domeniul de testare, coordonarea și alocarea echipei, activitățile de testare etc., avem tendința de a uita misiunea noastră reală ca testeri care este „ obiectivul principal al construirii proiectului ”. Acesta este singurul motiv din spatele realizării proiectului care ajută la rezolvarea problemelor utilizatorilor finali.

Cu toate acestea, întrebarea importantă ar trebui să fie, că testăm pentru a ne asigura că aceste probleme sunt rezolvate? Dacă nu, oferim feedback frecvent părților interesate pentru a le ajuta să profite de o perspectivă mai bună asupra proiectului. Este important să ne întrebăm în continuare „ La asta se așteaptă clientul?” Sau „Există o modalitate mai bună de a rezolva aceeași problemă ”. Simpla luare a cerințelor de la client și construirea acestora nu ne îndeplinește treaba. Pe măsură ce începem să lucrăm la proiect, trebuie să stăm cu clientul nostru pentru a înțelege care sunt așteptările lor de la proiect și cum vizualizează aspectul de calitate al acestuia.

De exemplu, dacă clientul dvs. este mai concentrat pe aspectul de branding decât chiar și o problemă cu logo-ul pixelat ar fi severă pentru dvs., dacă nu pentru dezvoltator. Dacă intenționează să construiască o aplicație financiară, poate că interfața de utilizare și UX ar putea fi o preocupare mai mică pentru el în comparație cu securitatea datelor utilizatorului său. Aici „obiectivul” este cheia . Acesta este ceva de care avem nevoie pentru a ne îngropa în noi înșine ca testeri. Acesta ar trebui să fie OKR-ul echipei dvs. ( Obiective și rezultate cheie ), mai degrabă decât acele valori bazate pe număr.

OKR este un proces popular de leadership care ajută indivizii, echipele și organizația să lucreze împreună pentru a-și îndeplini obiectivele într-o singură direcție unificată . Setează obiective între echipe și organizație. Astfel de OKR-uri ajută la concentrarea pe productivitate și stimulează cultura companiei.

Calitatea este subiectivă & amp; Se poate schimba de la client la client.

Este important modul în care ne stabilim eforturile de testare în conformitate cu aceste obiective. De fapt, acest lucru ne ajută să conducem decizia noastră de a remedia și a nu face asta. Prin urmare, totul se reduce la linia de jos, cu cât aveți o imagine mai clară pentru părerile părților interesate și misiunea proiectului lor, cu atât va fi mai bine să vă construiți și să vă acordați prioritate eforturilor de testare. Analizând riscul dvs. întrebându-vă pe dvs. „ ce dorește clientul dvs. ” vă va ajuta să obțineți calitate. Acest lucru poate părea mai degrabă roluri și responsabilități ale unui analist de afaceri, dar să nu uităm că, în calitate de testeri, trebuie să avem și această abilitate elementară. Strategia noastră de testare se bazează pe aceste analize în sine.

Deci, să ne concentrăm pe scrierea unui număr suficient de cazuri de testare care să conducă obiectivele clientului și a proiectului, mai degrabă decât să ne concentrăm pe scrierea unui număr mare de cazuri de testare, fără a exista un element crucial. Evidențierea problemelor de severitate ridicată, mai degrabă decât simpla umplere a găleții cu acel număr mare de bug-uri minore. Acordați prioritate riscului care poate duce la reducerea clientului dvs. și nu a matricei de evaluare .

Calitatea a fost și va fi câștigătorul incontestabil . Cuantificarea procesului de testare nu va fi oricum suficientă, dar, desigur, întrebarea va rămâne fără răspuns tuturor acelor organizații care undeva în linie au nevoie de o măsurare „ cum măsurăm atunci calitatea? ” de a avea aceste valori a fost să ne concentrăm asupra modului de a aduce aceste numere în sus / în jos sau poate fi la același nivel pentru a atinge calitatea, dar, deoarece oamenii sunt oameni, intrăm în această afacere de numere mai în serios și îi conducem, deoarece au fost marcați ca evaluarea creșterii noastre. Prin urmare, este important să ne amintim, ce ne determină ca testeri și cum să construim matricea noastră de evaluare. Dacă sunteți îngrijorat de abordarea testelor de compatibilitate a browserului, iată un articol care vă va ajuta să evaluați matricea de compatibilitate a browserului pentru fluxul de lucru de testare.

Deci, știm de departe că testarea calității este mai bună decât testarea cantității. Modul de a vă asigura că pășiți în direcția corectă este prin recrutarea testerilor software corecți din echipa dvs. și pentru a absorbi conceptul calitatea testării calității și nu a testării cantității , în echipa de testare software pe care deja o aveți au.

Cum să judeci un tester de calitate în afară de ceilalți?

Sunt în industrie de șapte ani acum și, după ce am îndrumat atât de mulți profesioniști în testare în devenire, întreaga mea idee despre măsurarea persoanelor pe baza calității a derivat întotdeauna din capacitatea lor de a analiza cerințele afacerii, de a le descompune la un nivel mai mic de bucăți și asigurați-vă că acestea sunt construite și lucrate așa cum se intenționează.

Întotdeauna a fost intenția testerului care a contat pentru mine, mai degrabă decât numerele pe care mi le dă în ceea ce privește cazurile de testare sau erorile. Întotdeauna am preferat persoanele care pun întrebări și înțeleg sensul priorității, mai degrabă decât persoanele care „doar testează”.

Cel mai frecvent comportament pe care l-am observat la atât de mulți testeri este că încep să scrie cazuri de testare imediat ce povestea / cerința le este alocată. Ei tind să uite pasul de bază de bază, care este să stea și să analizeze cerințele menționate în poveste. Uită să se pună întrebări, îmbrăcând pantofii unui utilizator final și realizând fluxurile de lucru pe care utilizatorii finali ar putea să le folosească. Descoperiți zonele afectate și vedeți prin toate validările pe care utilizatorul le poate valida în timpul fluxului.

Întotdeauna insist să fac o listă de verificare înainte de a începe să scriu cazuri eficiente de testare, ceea ce ajută la acoperirea corectă a testelor. Un alt aspect important este backtracking-ul, fie că este vorba de cerințe sau de eroarea apărută. Acest lucru ajută la asigurarea cerințelor care nu sunt lăsate deoparte și se poate găsi cauza principală a erorii, ceea ce ajută la reducerea apariției unor astfel de erori. Raportarea bună a erorilor și atitudinea pozitivă ajută și la crearea unui tester bun.

Acestea sunt câteva dintre aspectele de calitate pe care le promovez de obicei în rândul echipei mele. În măsura în care sunt necesare măsurători, le-am introdus în secțiunea de competențe și îi marchez pe indivizi peste ei, mai degrabă decât acele valori.

Unele dintre calitățile testerilor buni includ:

Ar putea exista abilități mai eficiente pentru a deveni un software de testare de succes.

Noi, ca testeri, datorită acestui maraton de valori, avem tendința de a absorbi unele dintre calitățile „ nu sunt necesare ” sau „ rele ” ca tester și aveți încredere în mine, acestea sunt ceva foarte frecvent în zilele noastre, de exemplu:

Cheia este să injectați aceste calități și să le aduceți pe cele pozitive în echipa dvs. Iată cum îi încurajez să scoată la iveală cele mai bune dintre calitățile lor:

Nu te îndepărta de obiectivele tale!

Am văzut că se întâmplă de multe ori, ca testerii software să se concentreze prea mult pe creșterea numărului de bug-uri și, ca rezultat, vor ajunge să se îndepărteze de obiectivul funcționalității pe care erau meniți să le testeze. Sunt sigur că și tu trebuie să fi experimentat același lucru!

Ei bine, cazurile de testare a calității sunt foarte critice și dacă nu ne ținem de obiectivele noastre și nu raportăm erorile pe baza creșterii numărului zilnic de jurnale de erori, atunci am putea ajunge să umbrim cazurile critice de testare a calității.

Gândiți-vă la aceasta ca la configurarea OKR-urilor potrivite (cheie obiectiv și rezultate) pentru departamentul de testare. Dacă sunteți un conducător QA sau un manager, responsabil pentru alinierea echipei de testare în managementul lansării, devine foarte important să stabiliți obiectivele potrivite pentru departamentul de testare.

Puteți marca abilitățile pozitive discutate mai sus ca obiectiv principal și vă puteți măsura echipa pe aceste baze. Acest lucru ajută la îmbunătățirea membrilor echipei dvs. și la o creștere suplimentară, care ar avea un impact direct asupra proiectului / produsului dvs. OKR-urile sau matricea de evaluare ar trebui să fie create pentru a răspunde la întrebări precum :

Cu acele OKR-uri clar definite, putem ajuta la livrarea unui produs de calitate ca o echipă, mai degrabă decât compararea și analizarea numerelor fără valoare (valori) între membrii echipei. Acestea fiind spuse, colectarea acestor numere pentru a vă îmbunătăți obiectivul de calitate ar trebui să fie singura esență. Credeți sau nu, numerele conduc psihologia oamenilor, de aceea este important modul în care le încadrăm și le utilizăm.

Deci, să nu împingem cantitatea pentru a stimula calitatea. Calitatea ar trebui să fie orientată individual și ar trebui să fie considerată a fi singurul aspect major al atingerii satisfacției clienților.

Sadhvi Singh este un manager QA. În cei 7 ani de călătorie profesională, a lucrat la mai multe domenii și tehnici de testare, cum ar fi testarea automatizării, testarea bazelor de date, testarea API, testarea manuală și testarea securității. Cu expunerea la mai multe instrumente adăugate la experiența ei, s-a calificat în continuare prin cele două premii majore la nivel internațional prin ISTQB, cu niveluri fundamentale și avansate. Are un blog tehnic numit qavibes.blogspot.com, unde răspunde tuturor provocărilor oferite în călătoria de zi cu zi a aspiranților la asigurarea calității. În timpul liber, ea lucrează și ca trainer tehnic și mentor pentru mulți profesioniști în QA în devenire.

Publicat inițial la LambdaTest

Autor Sadhvi Singh

Lecturi suplimentare

Dacă îți place postarea, te rugăm să aplaudă👏 și să-i ajuți și pe alții să o găsească.