Cum se calculează timpul de testare

... Sau, cu alte cuvinte, cum să calculeze timpul pentru a testa, astfel încât toți au crezut? La urma urmei, de fapt, avem de obicei două goluri. În primul rând - găsiți timp, astfel încât să nu facă greșeli și să aloce resurse în mod corespunzător - cel mai probabil la început să o facă bine încă nu va funcționa. Al doilea obiectiv este mai realist: pentru a conta timpul pentru testare, astfel încât să se dovedească la cineva care aveți nevoie mai multe persoane pe echipa, explica de ce nu aveți timp, etc Destul de ciudat, după doar 50 pentru a face a doua, atunci .. și primul va funcționa!

Să vedem acum cum să numărăm timpul de testare, pe exemple specifice.

Cazul 1: "Iată TK, cât timp va dura pentru a scrie cazuri de testare?"

Să presupunem că un dosar mare vine cu o specificație tehnică bine scrisă (TOR). Ne întrebăm cât timp va dura pentru a scrie scenarii de testare (TC) pentru întregul lucru.

Înainte de a răspunde la această întrebare, ar trebui să știm:

  • Cine va scrie TS?
    • Care este nivelul persoanei. cine va scrie TS: are mai puțină experiență sau mai mult decât tine? În mod evident, dacă are mai puțină experiență, va avea nevoie de mai mult timp. Dacă are cât mai multă experiență ca tine, atunci evaluările tale converg. Dacă o persoană este mai abruptă decât tine, atunci nu este deloc clar de ce vi sa cerut să numărați timpul.
    • Care este nivelul de cunoaștere a tehnologiei? dacă o persoană va fi în măsură să efectueze teste de nivel scăzut, toate bine afla dacă el va înțelege ce se întâmplă cu baza de date, de exemplu?
    • Care este nivelul de cunoaștere a domeniului. Acest lucru este chiar mai important decât nivelul de cunoaștere a tehnologiei, pentru că dacă, de exemplu, necesitatea de a testa unele îngrămădite aplicații financiare, iar noi nu înțelegem deloc ce obligațiuni și opțiuni - o mulțime de timp vor fi cheltuite pentru înțelegerea zona de subiect. Pentru a înțelege fără acest lucru, cât de greu TK, cât de complicat de produs, și în cele din urmă, cât de extinsă și modul în care, în general, trebuie să fie vehicul, este dificil.
  • De ce și pentru cine sunt scrise TS?
    • Pentru tine - dacă încercăm dezvoltarea noastră internă. Avem propriul nostru produs, echipa noastră, și scriem TS pentru produsul nostru.
    • Pentru client. Uneori, clientul comandă numai testarea și, uneori, doar TS. Uneori cere să testeze o dată și apoi să-i lase un artefact, potrivit căruia se poate testa. TS pentru client poate fi mai puțin detaliată și detaliată, dar diferită decât dacă am fi scris TS pentru noi înșine. Deci, noi înșine înțelegem toți termenii de testare, dar, probabil, va trebui să detaliem în TS tot felul de lucruri complicate din zona subiectului. Clientul poate înțelege perfect subiectul, dar poate că nu știe care este validarea formei și va trebui să explice acest lucru.
    • Pentru testul de acceptare - în acest caz, TS este chiar mai dificil de scris decât pentru client, deoarece acesta este testul, rezultatele cărora clientul nu le acceptă, dacă nu dorește. Prin urmare, scriem TS pentru testul de acceptare mult mai formal - nu ar trebui să existe formulări precum "totul funcționează bine", deoarece clientul nu poate accepta nimic și niciodată pentru acel vehicul.
    • Pentru automatizare. Aici trebuie să ne gândim la testare, controlată de date, cum să o automatizăm și așa mai departe.
    • Pentru suflet. În acest caz, dorim doar să înțelegem și nu există nicio solicitare din partea echipei pentru testare.
  • Unde sunt scrise, în ce sistem de testare de management?
    • Este un mediu familiar.
    • Un mediu necunoscut. Într-un mediu necunoscut, bineînțeles, vom avea nevoie de mai mult timp.

Din răspunsurile la toate aceste întrebări depinde cât timp este nevoie pentru a scrie un caz de test pozitiv - T1. De asemenea, merită luată în considerare timpul pentru scrierea unui vehicul negativ (acesta va fi notat ca T-1). Experiența mea spune că TC-urile negative sunt de obicei scrise mai mult - de obicei au nevoie de mai mult. Desigur, există moduri diferite aici, dar mi se pare că cu cât cunoaștem mai bine domeniul, cu atât mai bine înțelegem aplicația, cu atât mai bine înțelegem unde și cum poate cădea, cu atât mai mult vom avea TS negativ. Dacă, de exemplu, aveți trei TS negative, unul negativ, probabil că ați înțeles greșit aplicația. Dacă puteți găsi 500 de TS negative pentru unul pozitiv, aceasta este o treabă bună. Am o corelație între TS pozitiv și negativ - de obicei de la ½ la 1/5.

T. ch. Trebuie să calculam timpul pentru a scrie un TS pozitiv, pentru a estima raportul pozitiv și negativ și a calcula timpul în întregime.

Opțiuni de evaluare:

  • Expert dur. De exemplu, știm că de obicei scriem 5 TS pe o pagină a TK. De obicei, un TC scrie 20 de minute. Sarcina tehnică este de 300 de pagini. 5 x 20 x 300 = 30000 - câte minute vom scrie TS.
    X cazuri de testare pe pagină, T1 minute pe TC, pagini Y (T-1 - TC negativ)
  • Rude deductiv. Să presupunem că avem un plan de proiect, există termene limită, există o echipă. Și noi reprezentăm, ce proporție dintre dezvoltatori și testeri ar trebui să fie în proiect. De exemplu, proiectul timp de șase luni. Dezvoltatorii - cinci (de aceea avem nevoie de doi testeri pentru aceste sase luni). Vedem că scrierea TC va fi de aproximativ un sfert din timpul alocat testării. Acesta este un mod dur, dar rapid de numărare.
    • Testarea durează X din când în când.
    • Scrierea cazurilor de testare Y din când în când pentru testare
  • Inductiv cu experiență. Aceasta este o metodă lentă de evaluare, dar funcționează bine. Aici încercăm să scriem un TS pentru fiecare parte a TK. Faceți-o mai bine cu gradul de detaliu cu care le vom scrie mai departe. Cu toate acestea, este posibil să se facă cel puțin TS la nivel înalt. Poate dura o zi, două, o săptămână, dar va ajuta să înțelegeți cât timp va trece deloc.
    • Vom sparge TK în părți omogene (de exemplu, în funcție de funcțional) și încercați să scrieți TS pentru fiecare parte
    • Ne uităm cât timp a fost cheltuit pentru scrierea TS pentru un anumit număr de pagini din fiecare parte, pornind de la aceasta, calculăm cât timp ar trebui să mergem pentru a scrie TS pentru fiecare parte
    • Adăugăm timpul calculat pentru fiecare parte

      Acum, să încercăm să numere câte ore am trecut despre scrierea pe vehicul (dar rețineți, nu de testare la toate):

      Estimările nu sunt de acord cu noi, dar acest lucru este normal - cel puțin am reușit să calculam aproximativ. Și dacă avem suficient timp pentru a evalua, putem face o evaluare în mai multe moduri.

      Numărătoarea timpului folosind Agile

      Acum, să vorbim despre metodologiile de dezvoltare flexibile, atunci când nu există o sarcină tehnică. Nu este foarte clar cum se evaluează, dar totuși există unele abordări. De exemplu, puteți:

      • mergeți doar prin restante;
      • scrieți TS la nivel înalt;
      • scrieți toate acțiunile din cadrul sprintului și încercați să estimați cât de mult va necesita timp - această abordare va fi discutată mai jos.

      Acum o mică deviere pentru managerii de QA, managerii de proiect. Toți pașii de creare și lansare a cazurilor de testare se pot împărți în următoarele componente:

      Cazul 2: "Iată o bucată de funcționalitate, cât timp va dura pentru a testa?"

      Cât timp va dura pentru a testa această sau o parte a funcționalității? Pentru a afla acest lucru, există diferite moduri:

      Puteți vedea cât durează de obicei să testați funcționalități similare.
    • Puteți să vă uitați la aceeași funcție. Dacă am testat deja acest lucru. Este foarte convenabil! Dacă, desigur, ați înregistrat ultima oară, cât de mult a durat.
    • Evaluarea inferentă - dacă știm cât de mult are loc această funcționalitate în general, funcțională (dacă, de exemplu, știm deja cât de mult timp este nevoie pentru a finaliza regresie), vom vedea doar că această testare funcțională va lua, de exemplu, a cincea parte a timpului.
    • Evaluare inductivă - ne amintim cât timp petrecem pe fiecare vehicul. Ne uităm la acest lucru și înțelegem că avem nevoie de 10-15 TC pentru testarea sa.

      Ce este important să ne amintim în acest caz? Că noua funcționalitate poate necesita din nou timp pentru a pregăti mediul înconjurător. Este important să vă amintiți existența unui coeficient de cunoaștere a sistemului: este nevoie de mai mult timp pentru teste dacă le executați pentru prima dată decât dacă le executați a doua sau a treia oară. Dar, dacă a doua oară vine într-o lună, atunci tot îl îndepărtați, ca și cum pentru prima dată - totuși, este pentru fiecare în felul său.

      Cazul 3: "De ce nu aveți timp să faceți ceva?"

      Apoi, o întrebare foarte frecvente cerut de testere: „Ce faceți cu toții, de ce prevaleaza nimic, de ce aveți nevoie pentru a ajuta cu automatizare de ce nu doriți în fiecare zi, am lansat o nouă versiune - aceasta din urmă stabilește ceva nou nr . "

      Pentru a arăta ceea ce facem, putem scrie pentru fiecare proiect toate sarcinile care se efectuează într-un singur sprint și le scrieți în ziua respectivă: numărați cât timp este cheltuit pentru fiecare activitate în această zi sau în acea zi. Deci puteți vedea sarcina medie, maximă și minimă.

      Un exemplu de astfel de tabel:

      Când am făcut-o, am văzut că sarcina nu poate fi întotdeauna distribuite în mod optim - uneori, de încărcare mare, și, uneori, o jumătate de zi pentru a face nimic. Acest lucru face posibil pentru a trage anumite concluzii și într-un fel eficientizarea procesului, a distribui sarcina - de exemplu, unele lucruri fac în avans, chiar dacă nu este în întregime în concordanță cu logica procesului. De exemplu, dacă la începutul sprint avem o mulțime de timp liber, putem începe deja scris povești de utilizator pentru urmatorul sprint. Deși nu știm structura următoare sprint, dar suntem cel mai probabil în măsură să ghicească că aici acestea sunt cele două sau trei povești cu siguranta va - acestea sunt, de obicei cele mai critice, acestea sunt, de obicei trebuie încă să rescrie, așa că este bun exercițiu.

      Avem încărcătura în ore. Și dacă se dovedește că în fiecare zi ai nevoie de 24 de ore de testare și avem doar doi oameni ... Deci avem nevoie cu siguranță de un al treilea tester!

      Cazul 4.1: "Vom lansa ansamblul vineri și chiar mai devreme - deci cât timp trebuie să testați"?

      În acest caz, procesul de testare este construit după cum urmează:

      1. Test de fum + test de regresie completă x privind numărul de platforme critice + test pentru funcționalitatea de bază pe toate platformele + teste pentru regresia completă pe platforme (a se vedea matricea).
      2. Retestarea: testul de fum + validarea x toate platformele.

      Testele pentru regresia completă pe platforme se efectuează în acest caz în felul următor (Cr, FF, etc., aici - diferite platforme, în acest caz - browsere):

      În conformitate cu această matrice, vedem că pentru fiecare platformă testăm o parte a funcționalității: în cele din urmă se dovedește că am verificat toate funcționalitățile și am testat activitatea pe fiecare platformă. De asemenea, putem schimba această matrice - în cele din urmă se pare că pentru un anumit număr de runde vom verifica în continuare fiecare funcție de pe fiecare platformă. Acesta are un sistem simplu - și poate fi, de fapt, 20 de configurații fără capacitatea de a automatiza testarea lor - desigur, în acest caz, nu avem timp pentru a verifica, și va fi testat de o matrice.

      Ca rezultat, obținem următoarea formulă:

      ΣT = (Tprec + Treg) x (Qmain + 1) + (Tprec + Tbase + Tsmoke) x Qconf + (Tsmoke + Tvalidation) x Qconf x Qreturns

      Qmain - numărul de configurații principale, pe care încercăm totul.
      Qreturns - numărul restituirilor.

      Prin această formulă este clar cât timp vom avea. Pe ea puteți încerca să urmăriți timpul, examinați ce teste durează cel mai mult. De asemenea, va fi clar unde și ce este mai bine să automatizeze - vom înțelege unde automatizarea ne va salva cel mai mult timp.

      Cazul 4.2: "Prea multe teste! Să mergem mai repede.

      Dacă suntem obligați să efectuăm teste mai rapide, putem reduce numărul de teste pe următoarele principii:

      • Ne uităm la priorități:
        • cazuri de încercare - dacă notăm prioritățile vehiculului. Apoi vom lucra numai cu cele mai prioritare TS;
        • povestiri personalizate sau bug-uri. dacă vehiculele noastre sunt atașate de ele.
      • Ne uităm la notele de lansare (notele de lansare), care includ:
        • din punct de vedere funcțional important. fără de care aplicația nu va funcționa și nimeni nu are nevoie de ea;
        • noul funcțional declarat - deoarece acesta este anunțat public, utilizatorii îl vor verifica;
        • corectarea erorilor critice (cel mai probabil, erorile vor fi deja verificate);
        • corecțiile cerute de erori - am afirmat că am corectat ceva și că îl verificăm;
        • problemele cunoscute - paradoxale cum ar părea, dar trebuie neapărat să retestăm acele greșeli pe care le-am declarat erori cu care am lansat produsul. De ce face asta? În primul rând, trebuie să verificați dacă impactul lor este exact la fel cum am descris. În al doilea rând, verificăm dacă funcționează soluția pentru această eroare, pe care o propunem.
      • În loc să reduceți cantitatea de teste, puteți crește comanda.
        • Adăugați programatori - cel mai bine din proiectul propriu. De exemplu, pot scrie generatoare de date și lucruri - totul pentru automatizare sau semi-automatizare. Ei fac bine și responsabilitatea pentru testare nu este încă pe ele - deci nu suferă de faptul că codul lor nu funcționează bine. Din același motiv, puteți cere anumitor programatori să verifice codul altor programatori.
        • Solicitați testeri de la alte proiecte sau din acest proiect, dar faceți altceva.

      În general, procesul de testare real poate fi reprezentat sub forma unui triunghi. Unghiurile acestui triunghi sunt:

      1. Volumul testelor.
      2. Numărul de persoane din echipă.
      3. Termen. pentru care trebuie să efectuați testarea.

      Viteza și calitatea testării depind de aceste trei aspecte - tocmai deasupra acestora trebuie să vă gândiți să vă planificați cu succes munca. De exemplu, în cazul în care ni se cere pentru a testa produsul pentru timpul nerealist de scurt, iar noi nu îndeplinesc, sau să refuze o astfel de muncă (în cazul în care nu doriți să elibereze un produs de calitate scăzută, desigur), sau lucrați cu aspectele de mai sus. Apoi putem:

      1. Reduceți cantitatea de teste.
      2. Creșterea numărului de persoane din echipă.
      3. Cereți mai mult timp pentru testare.

      Ultima metodă este probabil cea mai fiabilă: la urma urmei, oamenii pot oferi echipei necalificate și reducerea cantității de testare poate duce la eliberarea unui produs brut.

      De asemenea, există o modalitate - de a întreba de ce acești termeni. Poate că avem nevoie de o singură funcție pentru un client - atunci vom face o eliberare privată și mai târziu vom testa totul.

      Un alt caz în cele din urmă: finalizarea proiectului deja lansat

      În cazul în care proiectul este deja, dar a primit o solicitare de a modifica, deoarece acestea calculează timpul de testare, dezvoltare și așa mai departe. E. În acest caz, timpul este de obicei, dar înmulțim cu doi, pentru că toți oamenii au toate uitat deja în alte proiecte - aveți nevoie de timp pentru a vă familiariza cu sistemul. Mai mult decât atât, adăugarea poate fi în afara ciclului standard, astfel încât, cu excepția adăugării acestui test, poate fi necesar o regresie completă - apoi se adaugă timp pentru a finaliza regresie.

      Articole similare

      Pagina anterioară

      Pagina următoare