Meniu

Ce este testarea timpurie: testați devreme, testați deseori DAR cum? (Un ghid practic)

what is early testing

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Ce este testarea timpurie?

Testarea software-ului ar trebui să înceapă devreme în ciclul de viață al dezvoltării software-ului. Acest lucru ajută la captarea și eliminarea defectelor în primele etape ale SDLC, adică faze de colectare și proiectare a cerințelor. Un început devreme de testare ajută la reducerea numărului de defecte și, în cele din urmă, a costului relucrării la final.

Diferitele aspecte ale Testarea timpurie care ar ajuta managerii și liderii de asigurare a calității în timpul dezvoltării sau conceperii documentului Strategiei de testare în SDLC sunt explicate aici.

Adoptarea testului timpuriu va avea ca rezultat imens livrarea cu succes a unui produs de calitate.

testare timpurie (1)

Până la sfârșitul acestui tutorial, cititorii, managerii de asigurare a calității, clienții potențiali și testerii vor cunoaște corect conceptele de mai jos:

cine este cel mai bun furnizor de e-mail
  • De ce testarea timpurie în SDLC (proiect sau o versiune software)?
  • Scopul efortului de testare timpurie
    • Ce să testăm devreme?
    • Start și Exit
  • Argumente pro şi contra

Să explorăm acum detaliile nuanțelor !!

Ce veți învăța:

Principiile testării

Figura 1 - Vedere simplificată a principiilor testării

1. Principiile testării

Pentru o anumită versiune de software sau sistem sau produs în SDLC, există diverse metodologii sau strategii bine definite pentru majoritatea următoarelor principii de testare.

  • Ce este testarea?
  • De ce testarea?
  • Ce să testez?
  • Cum se testează?

Cu toate acestea, unele dintre cele mai persistente întrebări pe care mulți cititori, testeri, clienți potențiali și manageri de asigurare a calității le-ar pune sau ar dori să obțină mai multă claritate cu privire la includ (zona gri în figura 1 )

  • Când începe testarea într-o versiune de software sau Când trebuie să înceapă testarea într-un proiect?
  • Când să începeți testarea și când să opriți testarea?
  • De ce ar trebui să înceapă testarea devreme în SDLC?
  • Ce este un test timpuriu în dezvoltarea de software?

Pentru o înțelegere ușoară a publicului, am ascuns toate întrebările despre „zona gri” sub o umbrelă numită Testarea timpurie.

De ce să testăm devreme în SDLC?

Să discutăm câteva evenimente și activități care fac parte din testare.

De obicei, echipa de gestionare a programului atribuie un manager de program (PM) unei anumite versiuni de software sau unui proiect. Primul ministru, în colaborare cu toate părțile interesate, inclusiv echipele de marketing, dezvoltare, QA și asistență, vine cu un program de lansare

În acest tutorial am ales Program trimestrial de lansare folosind modelul Cascada pentru a explica Concepte de testare timpurie detaliat.

Program de testare a lansării software-ului

Majoritatea organizațiilor respectă în continuare tradiționalul Eliberare bazată pe timp (TBR) modele în care versiunile de software sau produse sunt planificate pentru livrare trimestrială, semestrială sau anuală.

În mod predominant, modelul Waterfall este utilizat pentru executarea acestor versiuni de software. În unele cazuri, pentru un ciclu de lansare mai scurt, se adoptă modelul Agile / Scrum.

Figura 2 - Program tipic trimestrial de testare a lansării (nu este proiectul general sau programul de lansare)

Program trimestrial de testare a lansării

Impactul defectelor critice sau de severitate ridicată

Figura 3 - Impactul tipic al defectelor critice

Impactul tipic al defectelor critice

În principal , în timpul testării, este de așteptat ca.

  • Defectele critice sau de severitate ridicată trebuie identificate și înregistrate de testeri.
  • Dezvoltatorii vor trebui să remedieze aceste defecte.
  • Ulterior, testerii vor trebui să verifice remedierile.

În al doilea rând , este recunoscut pe scară largă de numeroase organizații de inginerie de produse și software că remedierea și verificarea erorilor de severitate ridicată sau critice la un număr foarte mare este

  • Consumă timp
  • Hogging de resurse (om + mașină)
  • Predispus la garanții, remedierea erorilor critice atinge în mare parte o mare parte a codului, inclusiv zonele de intersecție.

în cele din urmă , dacă un număr mare de bug-uri critice se găsesc la sfârșitul unei versiuni date, atunci au loc una sau mai multe dintre următoarele evoluții negative.

  • Probabilitate mare de extindere a ciclului de testare.
  • Probabilitate ridicată de ratare a termenului de lansare.
  • O caracteristică specială cu un număr mare de defecte poate fi necesară scoaterea din acea versiune specială.
  • Angajamentele clienților sunt ratate.

Ce zici de celelalte Defecte?

Există defecte cu prioritate medie și scăzută care vor fi identificate și înregistrate de testeri. Acestea trebuie, de asemenea, să fie tratate în mod corespunzător de către echipa de dezvoltare și de asigurare a calității. Astfel, în general este un exercițiu voluminos.

Nu există glonț de argint

Este un fapt binecunoscut că nicio cantitate de testare nu poate descoperi fiecare defect pe care îl are un produs software sau sistemul. Adică, practic, nici nu există un sfârșit al testării, nici produsul nu are defecte.

Cu toate acestea, din Facilitate de întreținere Din punctul de vedere al unui model Competitive și Time To Market (TTM), este necesar să se rupă mentalitatea tipică pentru a descoperi defectele maxime la începutul unui ciclu de lansare, în special identificarea defectelor critice și de severitate ridicată.

Orice sau toate cele de mai sus vor avea un impact negativ asupra afacerii organizației. În acest context, adoptarea „ Testarea timpurie 'Ia o activitate de testare separată va fi benefic pentru managementul general al SDLC pentru un anumit proiect sau lansare.

Scopul efortului de testare timpurie

După ce am înțeles obiectivul testării timpurii în secțiunea anterioară intitulată „ De ce testarea timpurie? ”, Să discutăm acum despre„ Domeniul de aplicare al efortului de testare timpurie ' detaliat.

Întrucât introducem testarea timpurie ca o nouă activitate care trebuie urmărită exclusiv în timpul execuției testării, se recomandă practicarea sferei efortului de testare, așa cum se explică mai jos.

Presupunere:

  • Programul de lansare a întregului proiect sau software este aprobat și pus la dispoziția tuturor părților interesate.
  • Documentul general privind strategia de testare este elaborat, revizuit și aprobat de toate părțile interesate.
  • Caracteristicile prioritare ridicate, medii, scăzute care trebuie testate sunt bine documentate.
  • Planurile de testare și cazurile de testare pentru toate caracteristicile sunt dezvoltate, revizuite și aprobate de către toți factorii interesați.
  • Toate planurile de testare și cazurile de testare sunt încărcate într-un depozit central pentru urmărirea execuției testării.
  • Toate resursele umane, echipamentele de infrastructură și instrumentele sunt disponibile pentru configurarea patului de testare și pentru executarea planurilor de testare.

Ce să testăm devreme?

Figura 4 - Abordare generală a sferei testării timpurii

4. Ce să testați la testarea timpurie

Abordare

  • Să luăm o Exemplu din versiunea XYZ având 3 caracteristici cu prioritate ridicată A, B și C, 10 caracteristici cu prioritate medie și 15 caracteristici minore (sau cu prioritate redusă).
  • Caracteristicile cu prioritate ridicată sunt cele care generează venituri ridicate și / sau conformitate cu standardele și / sau recuperarea concurenților și / sau competența unică și toate acestea.
  • Caracteristicile cu prioritate ridicată implică de obicei unele codificări complexe, adăugând un număr mare de noi linii de cod.
  • Un număr mare de noi linii de cod poate însemna, de asemenea, o probabilitate mare de intersecție a zonelor.
  • De obicei, caracteristicile cu prioritate ridicată și / sau caracteristici care au un număr mare de linii noi de cod sunt cei mai buni candidați pentru testarea timpurie.
  • Nu este necesar să existe un plan de test separat dezvoltat pentru activitatea de testare timpurie.
  • Conducătorii sau testerii QA împreună cu liderii de dezvoltare sau IMM-urile (experți în materie) trebuie să discute și să cadă de acord asupra acoperirii codului / testării pentru această activitate de testare.
  • Identificați cazurile de testare cu prioritate înaltă adecvate și chiar unele cazuri de testare cu prioritate medie dacă credeți că este necesar din fiecare dintre caracteristicile Planurilor de testare A, B și C.
  • Odată identificate caracteristicile și subsetul adecvat de cazuri de testare, asigurați-vă că acestea sunt urmărite folosind instrumentul de urmărire a testelor adoptat de organizație.

Sugestie: Colaborarea este cheia! În timpul activității de testare timpurie, atât echipele de dezvoltare, cât și echipele de asigurare a calității trebuie să colaboreze strâns pentru a se asigura că obiectivele stabilite sunt atinse cu rezultate de calitate.

Începeți și ieșiți din testul timpuriu

Este important ca atât echipa de dezvoltare, cât și echipa QA să facă o brainstorming și să fie de acord cu toate abordările întregii activități de testare timpurie, inclusiv datele de pornire și ieșire, astfel încât toate să fie pe aceeași pagină.

Criterii de intrare pentru Start

  • Procentul finalizării testelor de integrare
  • Numărul de bug-uri deschise
  • Nu există blocanți pentru a începe testul timpuriu

Faza de activitate

  • Urmărirea progresului
  • Numărul de coduri scade în timpul acestei testări
  • Abordarea remedierii erorilor
  • Abordarea verificării erorilor
  • Înregistrați rezultatele testelor

Criterii de ieșire

  • Activități de predare la următoarea fază de testare (de obicei testarea caracteristicilor).
  • Rezolvarea erorilor nerezolvate găsite în timpul testului timpuriu.
  • Rezoluția blocanților, dacă există, pentru următoarea fază a testării.
  • Publică rezultatele testelor timpurii.

Argumente pro şi contra

Fiecare inițiativă sau activitate nouă are propriile sale merite și dezavantaje.

Să explorăm avantajele și dezavantajele acestei abordări de testare.

Pro

  • Ideal pentru modelul Waterfall.
  • Ajută la descoperirea erorilor critice la începutul ciclului de testare.
  • Identificarea erorilor critice la începutul unui ciclu de lansare.
  • Ajută echipa de dezvoltare să stabilizeze codul devreme.
  • Ajută la reducerea la minimum a garanțiilor datorate remedierilor de erori.
  • Ajută echipa de dezvoltare să identifice în detaliu vulnerabilitățile din zonele de intersecție la începutul ciclului de lansare.
  • Echipa de conducere poate lua decizii de afaceri adecvate cu diligența cu privire la erorile critice nerezolvate în acea versiune sau un proiect.
  • Ajută la extindere acoperirea testului și ciclul eficient.
  • Ajută la distribuirea eficientă și eficientă a resurselor de dezvoltare și testare.

Contra

  • Nu este ideal pentru modelul Agile / Scrum. Cu toate acestea, astfel de modele pot adopta Early Test in Sprints cu modificări adecvate.
  • Există șanse de reducere Testarea integrării de către echipa de dezvoltare.

Concluzie

Clienții sau utilizatorii finali cumpără sau adoptă un produs de întreținere sau un sistem sau soluție. Validarea unui software care rulează pe un astfel de sistem sau produse pentru funcționarea acestuia este cerința principală

Componentele cheie ale principiilor testării precum De ce să testezi? Ce este testarea? Ce să testez? Cum se testează? sunt în mare parte bine definite și înțelese. Cu toate acestea, există câteva întrebări persistente care continuă să se sprijine în mintea cititorilor, testerilor, clienților potențiali și managerilor pe concepte precum Testarea timpurie.

Adoptarea testării timpurii ca activitate integrală a programului general de testare pentru orice proiect software sau o versiune benefică imens Organizației de a livra un produs robust sau un sistem calificat.

Ați realizat vreodată importanța testării timpurii în carieră? Simțiți-vă liber să împărtășiți gândurile și experiențele dvs. în secțiunea de comentarii de mai jos !!

Lectură recomandată

^