diferite tipuri de tehnici de estimare în testarea Software

estimarea testului Software este o operațiune esențială de gestionare utilizată pentru a determina un interval de timp aproximativ necesar pentru a începe și termina orice proces într-un mediu controlat.

este crucial pentru orice planificare a proiectului să nu depășească limitele de timp, să stabilească bugetele și resursele disponibile. Una dintre cele mai utile SARCINI aici este verificarea resurselor în lumina unui efort care trebuie cheltuit la test.

inginerii de la UTOR folosesc adesea diferite tipuri de tehnici de estimare în timpul testării software-ului. Aceste metode au fost confirmate ca fiind eficiente de către clienții noștri. Prin urmare, vom trece peste ele și vom dezvălui avantajele și dezavantajele lor specifice, astfel încât să fiți informați despre cum să le implementați cel mai bine.

ce este estimarea de Testare Software?

estimarea testului Software este un proces de măsurare și gestionare a duratei și acțiunilor necesare pentru a rula un test complet pe software.

timpul și efortul sunt considerabil simple de calculat pentru sarcini la scară mică. Dar pentru proiecte mai mari. trebuie să existe strategii eficiente, astfel încât să nu se facă greșeli. Dacă sunt subestimate sau supraestimate, resursele de testare pentru astfel de proiecte devin fie insuficiente, fie utilizate în mod abuziv.

Cum Estimează Echipele Resursele De Testare Software?

înainte de începerea testului, există două incertitudini foarte importante pe care totul depinde și trebuie să fie eliminate între tester și client. Acestea includ;

  • care este durata totală estimată a procedurii complete?
  • care este costul total estimat al procedurii în termeni de bani și resurse?

ce se estimează?

timpul, resursele, costul și abilitățile umane sunt de obicei determinate în timpul estimării testării.

timp

eficacitatea unui efort de echipă este de obicei evaluată prin capacitatea de a livra într-un interval de timp stabilit, la sau înainte de termenul limită.

după verificarea duratei standard necesare pentru fiecare secțiune a proiectului la îndemână, managerii de proiect dezvoltă un mijloc de păstrare pentru a programa fiecare proiect.

el se asigură că totul este livrat la timp. Din acest motiv, estimarea timpului este unul dintre factorii esențiali în construirea unei reputații solide în rândul clienților și având un număr bun de clienți fideli.

resurse

înainte ca orice proiect să poată fi demarat, este obligatoriu să verificați resursele disponibile, cele care ar trebui incluse și înlocuitorii recomandați dacă unele nu sunt ușor disponibile. Fără a verifica acest lucru, este foarte probabil ca proiectele să nu fie finalizate înainte de termenul limită.

Cost

la pregătirea pentru orice proces de testare, bugetul estimat trebuie luat în considerare pe deplin pe toate fronturile (atât financiare, cât și nefinanciare).

costul total trebuie luat în considerare pentru a lua în considerare posibilele cheltuieli și pentru a vă asigura că proiectul rămâne în bugetul stipulat al clientului și lucrați la el dacă nu este de până la.

câmpurile menționate sunt toate legate și interdependente de ele însele. Durata pe care o va lua, de asemenea, depinde de instrumentele disponibile și de bugetul dat.

de-a lungul timpului, procedura implicată în estimarea testelor software s-a făcut cu diferite procese, folosind diverse metodologii și instrumente care au avansat cu timpul din același motiv.

integrarea și funcționarea acestor tehnici au făcut și procedura de mediere mult mai ușoară.

tipuri de tehnici de estimare a testelor Software

există multe estimări și tehnici de mediere în general, dar vom analiza doar câteva dintre cele mai populare din lotul acestui articol.

tehnica de evaluare și revizuire a programului (PERT)

în această tehnică, sarcinile sunt împărțite în 3 subcategorii pentru a stabili mai bine timpul necesar pentru finalizare, și anume;

scenariul optimist – O; în acest caz, durata, cheltuielile monetare și resursele legate de proiect sunt presupuse a fi la cele mai înalte niveluri optime. Acest lucru înseamnă că membrii individuali ai echipei de asigurare a calității își desfășoară activitatea în cel mai bun mod colectiv, țin la timp, fără presiune, întorsătură imprevizibilă a evenimentelor sau nevoia de a revizui treaba făcută și de a oferi în continuare o muncă excelentă.

scenariul cel mai probabil – M; aici, toate lucrurile sunt luate în considerare; având în vedere scenariul de lucru familiar și luând în considerare posibilitățile negative și pozitive în minte, elementele sunt estimate cum este cel mai probabil să se întâmple.

scenariul pesimist – P; acesta are în vedere cel mai negativ scenariu care ar putea fi. Media va fi bazată pe presupunerea că va exista, fără îndoială, un rezultat negativ care va fi tratat în fiecare fază a întregii testări.

Pro PERT

  • utilizarea acestei tehnici înseamnă că echipa lucrează cu o estimare care verifică toate decesele și recompensele posibile pe toate fronturile.
  • echipele pot veni cu o evaluare destul de aproape de realitate.
  • pregătește organizațiile pentru orice rezultat posibil al testului de construire atunci când calculează fiecare scenariu imaginabil și se pregătesc în mod adecvat pentru a-l reduce, dacă este necesar.

contra PERT

  • atunci când se confruntă cu un corp mai mare de proiecte de testare, folosind această formă de estimare va consuma mult mai mult timp să se supună.
  • există o mare probabilitate de a avea calcule inexacte apar.
  • valorile utilizate aici nu sunt niciodată constante și ar putea fi întâmpinate cu multe erori, deoarece este doar o estimare până la urmă.

user Case Point (UCP)

ori de câte ori cineva sau ceva folosește și comunică cu aplicația în cauză, entitatea este identificată ca actor. Entitatea menționată este documentată în principal în ponderile neajustabile ale cazurilor de utilizare, care influențează capacitatea procesului.

orice comunicare intermediară va proteja implicarea tuturor de la acționari la indivizi din echipa QA prin diferitele secvențe și obiective definite.

peste zece agenți diferiți afectează cât de complicat este tehnicitatea unui proiect și aproximativ opt iau o taxă complexă asupra mediului. Acest lucru este în concordanță cu constatările lui Gustav Karner.

această metodă de estimare se bazează pe calcularea mai multor variante din așa-numiții actori, ponderile cazurilor utilizatorilor și punctele care afectează procesul, tehnicitatea și alți factori.

în primul rând, pentru a începe acest proces, ei vor trebui să-și verifice complexitățile respective și să afecteze procesul. Apoi, o medie suplimentară se face prin aplicarea formulelor lor de calcul.

după verificarea magnitudinii proiectului, cei implicați determină timpul necesar înainte de finalizarea totală a procesului. Două modalități semnificative de prevenire a acestui lucru sunt;

folosind metoda lui Karner și considerând fiecare caz de testare ca consumând 20 de ore de personal.

folosind timpul record al companiei pentru finalizarea proiectului, în orice caz, pentru a calcula mediile statistice și a ghici durata proiectului curent.

UCP= Unadjustable UCP X Factor de complexitate tehnică X Factor de impact asupra mediului.

Pro UCP

  • în cazul în care trebuie să lucrați în avans și să planificați cu mult timp înainte, atunci această metodă de estimare este probabil mai bună, deoarece se face în etapele inițiale și ajută la tăierea și aprobarea dimensiunilor bugetului.
  • cu ajutorul unor instrumente speciale de management, calculul automat al estimărilor este posibil, economisind mult timp pentru echipa de evaluare și facilitând locul de muncă.

contra UCP:

  • dacă cerințele proiectului nu sunt date în punctele de caz ale utilizatorului, acest lucru face imposibilă utilizarea acestei tehnici, iar echipa QA va trebui să se aprovizioneze pentru o altă metodă.
  • când UCP-urile sunt date și nu sunt suficient de exacte sau explicite, este cel mai probabil să se încheie negativ cu estimări departe de a fi reale, deoarece această metodă depinde nu doar de a da puncte de caz, ci de a oferi puncte de caz clare.

structura defalcării lucrărilor (WBS)

aici tehnica de estimare a valorilor se face prin împărțirea procesului primar în diferite subcategorii. Un calcul predictiv al duratei medii pe fiecare etapă începe treptat cu o lucrare brută asupra celor mai simple ale lotului, apoi absolvind atât dificultatea, cât și nivelul de corectitudine.

după procesul inițial, selectați cea mai mare valoare posibilă la care ați ajuns și adăugați-le și obțineți valoarea finală, estimând efortul și timpul necesar pentru fiecare sarcină.

Pro-urile WBS

  • un avantaj evident al acestei metode este că facilitează identificarea fiecărui minut și a detaliilor necesare în timp ce împarte munca în biți mai mici. Acest lucru înseamnă că lucrarea se face
  • este întotdeauna aprofundată și transparentă, deoarece concluziile sunt tabelate în același scop și o urmărire mai ușoară.

contra de WBS:

  • această natură necesită, de obicei, frecarea minților și a membrilor echipei și a părților interesate pentru a profita de experiența lor externă.
  • modificări în caietul de sarcini și nevoile clientului poate duce la învechite și au nevoie de echipa să se uite în ea și re-evalua în totalitate.

metoda Delphi

metoda Delphi este destul de populară în rândul echipelor de testare la nivel global. Datele de la participanții voluntari sunt colectate și examinate îndeaproape mai multe și, în nici o ordine specială, ajung la o concluzie convenită.

fiecare fază a examinării aduce feedback de date noi sau îmbunătățite, ceea ce adaugă rafinamentului constatărilor finale cu multă încredere meritată.

de obicei, o echipă este formată din nu mai mult de zece persoane care se întâlnesc pentru a discuta caracteristicile critice ale proiectului pe cale să se angajeze și să își exprime opiniile cu privire la Durata posibilă a proiectului.

ulterior, echipa se întâlnește din nou și, de data aceasta, opiniile de la prima întâlnire sunt împărtășite. Acest lucru oferă membrilor un alt unghi de abordare a proiectului. Cu toate acestea, punctele de vedere nu sunt etichetate la suggesters lor.

când membrii echipei trec prin această fază, vor avea o altă discuție unanimă, iar colaționarea opiniilor aduce în considerare noul unghi de percepție.

acest lucru va continua până când toată lumea este de acord pe aceeași pagină. Deși modul obișnuit de a face metoda Delphi, acest formular poate fi optimizat pentru a se potrivi nevoilor și capacităților sale.

Pro DELPHI

  • deoarece nu sunt necesare formule sau echipamente unice aici, este cel mai ușor din lot pentru orice echipă să se supună, tot ce este necesar este specificațiile clientului și bun pentru a merge.
  • estimarea este destul de aproape de precizie, deoarece multe puncte de vedere profesionale sunt luate în considerare în procesul de întâlnire și de partajare a ideilor.

contra DELPHI

  • la fel de ușor cum poate fi să se supună, poate dura o mulțime de timp productiv, deoarece cel mai adesea.
  • este dificil să veniți cu o estimare cuprinzătoare după primul lot de întâlniri și să împărtășiți opinii, așa că de obicei este nevoie de câteva.
  • chiar și după ce a consumat atât de mult timp, rezultatele nu pot fi reciclate. Deci, pentru ca fiecare proiect să fie rulat, procesul este început din nou cu noile cerințe.

pentru a rezuma

această postare pe blog a revizuit patru tipuri de tehnici de estimare în testarea software-ului și cât de impactante sunt acestea în planificarea unui buget rezonabil de testare.

după o estimare reușită, puteți spune cu siguranță abordarea corectă a externalizării proiectelor dvs. către companiile QA?

Iată un articol despre cum să alegeți cea mai bună abordare pentru externalizarea QA.

spuneți-ne care dintre aceste tactici de estimare a testelor ați implementa și care a fost înțelegerea dvs.?

Leave a Reply

Adresa ta de email nu va fi publicată.