Meniu

Ce să faci când nu este suficient timp pentru testare?

what do when there isn t enough time test

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

O parte din ciclul de testare, îți dai seama de multe ori că nu ai suficient timp pentru a testa? Ați avut totul sub control, pentru început, dar în curând veți ajunge la planul de urgență „Ce trebuie să faceți atunci când nu aveți suficient timp pentru testare?” secțiune.

Am fost și eu acolo și nu este distractiv. :)

M-am gândit la asta mult și greu. Cum poate ceva care a început atât de bine să coboare atât de rău, atât de repede. Și, iată analiza mea.

=> Faceți clic aici pentru seria completă de programe de testare

Ce veți învăța:

Unde s-a dus timpul meu de testare?

Nu este suficient timp pentru testare

întrebări și răspunsuri pentru interviuri pentru suport desktop pentru nivelul 1

În primul rând, de ce se întâmplă acest lucru?Multe motive - dintre care unele sunt:

# 1) Estimare incorectă :

Dacă ați început cu o așteptare inexactă, lucrurile vor eșua. O estimare bună a testului trebuie să ia în considerare următoarele:

  • Timp pentru sarcini pregătitoare - Vorbim despre sarcini precum:
    • Identificarea și punerea la punct a unei suite de regresie
    • Crearea datelor de test
    • Timpul pentru a determina disponibilitatea testului (de exemplu: Testul de fum / sănătate) etc.
  • Întreținerea cazului de testare : Cazurile de testare sunt materiale de utilizare pe termen lung. Sunt siguri că vor suferi actualizări minore în timpul execuției. Este recomandat ca pentru produsele noi să fie alocat până la 30% din timpul de execuție al testului pentru aceste sarcini minore de întreținere. Este posibil ca toate echipele și proiectele să nu aibă nevoie de 30%, dar alocă ceva timp și efort pentru această sarcină.
  • La acest / Testarea exploratorie - Numărul testelor scriptate este un numitor major pentru numerele de estimare a testelor. Cu toate acestea, nicio echipă de testare din această lume nu va nega explorarea software-ului dvs., chiar dacă modelul are un script dominant.
  • Raportare / comunicare - Aceasta include întâlniri de triaj / stand up, actualizarea instrumentelor de gestionare a muncii etc.
  • Factorul de contingență: Standardele recomandă 25-30% tampon la estimările inițiale. Dar echipele rareori își permit. Chiar și atunci, lăsați o mică cameră de respirație, atunci când este posibil.
  • Echipa și capacitățile sale: Dacă aveți o echipă nouă sau dacă utilizează un instrument pentru prima dată, este posibil să trebuiască să vă alocați ceva timp pentru antrenament. Adaptați estimările pe baza echipei cu care lucrați.

Citire recomandată=> Verificați acest lucru pentru mai multe informații despre succesul estimării testelor și metodele

# 2) Construiri instabile și alte probleme tehnice:

  • Eșecul testului de fum / sănătate : Când testele de bază pe AUT eșuează după implementare în mediul QA, echipa QA nu poate face aproape nimic pentru executarea testului. Este adevărat că putem lucra la alte sarcini în timp ce se întâmplă acest lucru, dar tot nu va completa ciclul de testare timp. Deci, acesta este un factor important pentru pierderea timpului.
  • Date de testare indisponibil : Datele similare producției sunt obligatorii pentru fiecare proiect de testare. Nerespectarea la timp a mediului QA este, de asemenea, un alt factor de blocare. Uneori testerii pot rezolva acest lucru până la crearea și gestionarea propriilor date de testare , dar consumă mult timp și s-ar putea să nu fie întotdeauna la punct.
  • Probleme de mediu - Implementările care nu reușesc la construire, serverul continuă să fie expirat, multe alte astfel de probleme îți elimină ciclul de testare. Acest lucru provine probabil din faptul că, unele companii (nu toate) subminează importanța unui mediu bun, live, pentru un QA eficient. De multe ori încearcă să scape de servere cu capacitate redusă și să facă seturi de make-do. Aceasta este într-adevăr o soluție de scurtă durată și nu face favoare nimănui. De fapt, le-ar putea costa calitatea testării și pierderea timpului valoros de testare.

# 3) Lipsa acordului între toate părțile implicate:

Aceasta ar putea fi o problemă rară cu echipele care urmează Agile sau Sigur datorită cercurilor strânse în care lucrează, dar multe echipe încă suferă de dezacord sau comunicare greșită cu privire la momentul în care Dev, Ops și QA ar trebui să primească livrabile unul de la altul. Prin urmare, întârzierile.

Pentru a înțelege subtilitățile comunicării, verificați acest lucru => Cum pot lucra împreună afacerea, dezvoltarea și QA pentru a finaliza proiectul

Acum, că știm problemele, iată câteva modalități de a remedia problema.

Cum pot beneficia testerii suficient timp pentru testare?

# 1) Estimați cu precizie. Când aveți dubii, supraestimați cu o marjă rezonabilă, dar nu subestimați. Nu uitați să efectuați ajustări estimate pe baza echipei, instrumentelor și proceselor dvs. Când ați terminat, căutați deconectarea oficială, astfel încât toată lumea să fie conștientă și să fie ținută la curent.

#Două) Luați în considerare datele istorice - Instrumentul de gestionare a testelor este cel mai bun prieten al tău .

  • Cât a durat ciclurile de test de lansare anterioare?
  • Ce fel de probleme au cauzat întreruperi ciclului de test anterior?
  • Câte probe au avut cele mai multe cazuri de test înainte de a trece?
  • Ce defecte au fost raportate?
  • Ce defecte au determinat întreruperea testării?

# 3) Puneți aceste întrebări și planificați în consecință în timp scurt:

  • Aflați Funcționalitatea importantă este proiectul dvs.?
  • Aflați modulul cu risc ridicat al proiectului?
  • Ce funcționalitate este cea mai vizibilă pentru utilizator?
  • Ce funcționalitate are cel mai mare impact asupra siguranței?
  • Ce funcționalitate are cel mai mare impact financiar asupra utilizatorilor?
  • Ce aspecte ale aplicației sunt cele mai importante pentru client?
  • Ce părți ale codului sunt cele mai complexe și, prin urmare, cele mai supuse erorilor?
  • Ce părți ale aplicației au fost dezvoltate în modul Rush sau Panic?
  • Care cred că dezvoltatorii sunt aspectele cu cel mai mare risc al aplicației?
  • Ce fel de probleme ar cauza cea mai proastă publicitate?
  • Ce fel de probleme ar cauza cele mai multe reclamații legate de serviciul clienți?
  • Ce tipuri de teste ar putea acoperi cu ușurință mai multe funcționalități?

Având în vedere aceste puncte, puteți reduce considerabil riscul de lansare a proiectului sub mai puțin timp.

# 4) Utilizați un instrument de gestionare a testelor. Acest lucru va reduce semnificativ timpul și efortul de pregătire, raportare și întreținere.

=> Pentru lista celui mai popular instrument de management al testelor , verifica aici :

# 5) Nu putem face multe despre construcții / probleme tehnice incorecte, dar singurul lucru care ne poate ajuta este să analizăm rezultatele testelor unitare. Acest lucru ne va oferi o idee dacă construcția a fost sau nu un succes și ce fel de teste au eșuat - deci nu reinventăm roata.

Dacă ale tale Instrumentul de gestionare a testelor acceptă Integrarea CI , aveți acele informații disponibile fără nicio problemă, astfel încât să înțelegeți mai bine stabilitatea aplicației.

# 6) Măsurați-vă productivitatea și progresul des . Nu lăsați rapoartele de stare să fie livrate doar în beneficiul echipelor externe. Asigurați-vă că vă monitorizați îndeaproape obiectivele zilnice și capacitatea de a le atinge.

De asemenea, asigurați-vă că nu intrați în enigma clasică „Velocity vs. Quality”. Pentru că, atunci când raportezi, să zicem, 50 de bug-uri pe zi, s-ar putea să pară că ai fi foarte productiv. Dar dacă majoritatea se întorc ca nevalizi, ai o problemă.

Deci, monitorizează, monitorizează și monitorizează puțin mai mult :)

Concluzie:

În cele din urmă, în ciuda tuturor măsurilor de precauție și a măsurilor, dacă totuși te găsești zdrobit de timp, cere ajutor .

Majoritatea echipelor sunt dispuse să participe la o sesiune de cameră de război pentru a relua lucrurile pe drumul cel bun.

ce poate deschide un fișier .dat

Despre autor: Aceste sfaturi utile de testare sunt furnizate de către membrul echipei STH Swati S.

Acum, care sunt trucurile tale pentru a rămâne la timp și pentru a oferi un serviciu de testare de calitate? De asemenea, ce puncte din articolul de mai sus rezonează cu tine?

Apreciem feedback-ul dvs. și prețuim cititorii. Mulțumesc că ai citit!

=> Vizitați aici pentru seria completă de programe de testare

Lectură recomandată

^