Ciclul de viață defect - Așa cum puteți ști acum că execuția testului este faza în care testatorul ar efectua efectiv scripturile de testare. Procesul de execuție a scripturilor de testare variază de la o companie la alta și poate fi diferit și în diferite proiecte din cadrul aceleiași companii.
De câteva zile există instrumente disponibile pentru executarea testelor, instrumente precum - Quality Center, Microsoft Visual Studio și așa mai departe. Procesul de execuție efectiv al fiecărei etape pentru a compara rezultatul real și cel așteptat rămâne același pentru testerul funcțional, indiferent de instrumentele utilizate.
- Ce se întâmplă dacă comportamentul real nu este egal cu cel așteptat?
Când un tester constată că rezultatul testării efective nu este egal cu rezultatul scontat, un defect este înregistrat.
- Cum să înregistrați un defect?
Există multe instrumente disponibile acum câteva zile, unele dintre instrumentele de înregistrare a defectelor sunt ClearQuest de la IBM, Centrul de calitate HP, instrumente open source precum ciclul de viață al defectelor în JIRA ș.a.
Există unele dintre câmpurile obligatorii care sunt comune în diferite instrumente de înregistrare a defectelor, aceste câmpuri sunt:
- Ciclul de viață al defectelor Descriere
- Rezumatul ciclului de viață al defectelor
- Defect autentificat de
- Defect atribuit
- Defecțiune Severitate
- Prioritate cu defecte
- Instantanee suplimentare
- Număr de eliberare / Nume
Ciclul de viață defect
Ciclul de viață al defectelor începe de la înregistrarea unui nou defect. De fiecare dată când este înregistrat un defect, acesta trece în starea „Nou”.
Tester - Noul defect
Cui să atribuie un nou defect?
Un Tester poate atribui un defect unui dezvoltator sau unui avans de dezvoltare. Această decizie de atribuire a defectelor variază de la proiect la proiect. În unele locuri de muncă, există un ciclu de viață al defectului, care să-l atribuie direct unui dezvoltator respectiv, iar în unele locuri, defectul este atribuit mai întâi unui avânt dev, iar plumb dev, la rândul său, îl atribuie unui dezvoltator.
Defect Assignment (nou) - Dezvoltator pentru ciclul de viață al defectelor
Defect alocare (nou) - Dev Leadà Dezvoltator
Analiza defectelor
Dezvoltatorul va analiza defectul pentru a verifica dacă acesta este reproductibil. Aici cea mai importantă contribuție din partea testerului este includerea tuturor detaliilor necesare în defect. Rezumatul defectelor, descrierea detaliată a defectelor sunt câmpurile care ajută părțile interesate să înțeleagă defectul dintr-o singură dată. Rezumatul defectelor ar trebui să aibă întotdeauna doar informațiile la nivel înalt ale defectului. În același timp, ar trebui să aibă suficiente informații pentru a descrie imaginea generală a defectului într-o singură linie.
Descrierea defectelor este locul în care este de așteptat ca testerul să includă toate informațiile necesare, cum ar fi Mediu, Scenariu, Datele de testare utilizate, Rezultatul așteptat, Rezultatul real, Referința la fișiere / date și referința la instantaneu.
Iată o scurtă privire de ansamblu a diferitelor elemente din Descrierea detaliată a defectelor -
Mediu inconjurator
Mediu de testare în care a fost găsit defectul. Adesea, proiectele au mai multe medii de testare în care echipa de testare efectuează teste. De exemplu - AT (mediu de testare a ansamblului), PT (mediu de testare a produsului), UAT (mediu de testare a acceptării utilizatorului) și așa mai departe. Scopul de a avea diverse medii este acela că oferă flexibilitate în cadrul echipei de dezvoltare și testare pentru a avea codul implementat pe oricare dintre mediile disponibile pentru a începe testarea la timp.
Există momente în care testul Produs (denumit și test de sistem) și testarea UAT se suprapun, prin urmare, având mai multe medii este obligatoriu să continuăm testarea în paralel.
Există cazuri în care echipa de dezvoltare are nevoie de un mediu suplimentar pentru a depana problemele raportate de echipa de testare. De asemenea, echipa de dezvoltare are un mediu dedicat pentru sarcina de testare a unității.
Prin urmare, cu mai multe medii, trebuie menționat în defect un mediu anume în care s-a găsit problema.
Scenariu
Scenariul este setul de etape efectuate de tester care a dus la un defect. Aici este de așteptat ca un tester să menționeze toți pașii pe care dezvoltatorul îi poate efectua pentru a reproduce defectul. Adesea, există momente în care defectul este raportat de către tester, dar dezvoltatorul nu este în măsură să reproducă același lucru și, prin urmare, defectul este respins. Acest lucru se poate întâmpla din cauza etapelor incorecte / a celor lipsă menționate în descriere. Pașii clari ajută toată lumea să înțeleagă defectul și să-l reproducă fără a avea dependența de a ajunge la un tester pentru a obține inputuri. Un scenariu bine documentat are ușor de citit, ușor de înțeles și pași care trebuie urmați pentru a reproduce defectul.
Date de testare
Se presupune că un tester menționează datele utilizate în timpul fluxului de testare care a dus la o problemă. Aceste informații oferă dezvoltatorului o șansă de a utiliza datele similare pentru a reproduce defectul și pentru a găsi cauza rădăcină pentru același lucru.
Există câteva scenarii în care un tester găsește un defect folosind date specifice, dar aceeași problemă nu este reproductibilă folosind date similare. Acest lucru se poate întâmpla din cauza corupției datelor, prin urmare, introducerea datelor oferă o șansă de a afla cauza principală a defectului. Un dezvoltator ar putea să nu coboare la nivelul codului, dacă este cazul corupția datelor. Acest tip de defect poate fi transformat în defect de date.
Rezultatul așteptat și actual
Acesta este punctul culminant al câmpului de descriere detaliat în care un tester dovedește că eroarea întâlnită este într-adevăr un defect. Menționarea clară a rezultatului așteptat face ca lucrurile să fie clare pentru fiecare deținător de părți să considere eroarea ca fiind un defect. Imaginați-vă că un defect este înregistrat cu toate detaliile, dar nu specifică rezultatul scontat al scenariului!
De obicei, un tester introduce doar rezultatul scontat poate fi într-o linie sau două, dar este foarte important să menționăm sursa rezultatului așteptat. Sursa aici referire la documentul în care este menționat rezultatul așteptat. Acesta ar putea fi un document de cerință sau o referință pentru storyboard.
Referire la fișiere / date
Uneori, defectul implică generarea de fișiere sau de intrare ca fișier. În acest tip de scenarii, se presupune că testerul furnizează informații despre fișierul care a fost folosit și care a cauzat problema în aplicație. Aceste fișiere pot fi atașate folosind instrumentul de gestionare a defectelor sau se poate furniza referința pentru aceleași. Aceste locații de referință ar trebui să fie accesibile de toate părțile interesate.
Referire la instantaneu
Instantaneele joacă un rol foarte important atunci când doriți să le arătați mesajul de eroare de întrerupere a paginii, așa cum este afișat pe ecran sau când doriți să afișați detaliile de navigare pe ecran. Snapshot oferă o idee rapidă despre defectul întâlnit, ecranul pe care a fost găsit defectul, datele utilizate pe ecran și așa mai departe. Fiecare instrument de gestionare a defectelor are dispoziții pentru a atașa instantaneele. Uneori, testerul poate atașa și foile de calcul Excel sau documente word.
Acestea au fost diferitele componente ale înregistrării defectelor și a celor mai bune practici pentru fiecare dintre ele. Revenind la ciclul de viață al defectelor, odată ce defectul este atribuit unui dezvoltator, acesta îl va analiza folosind datele furnizate în elementul defectului. Dacă în conformitate cu analiza, problema înregistrată este într-adevăr un defect, dezvoltatorul va „deschide” defectul pentru a lucra la remedierea acestuia.
Cursuri recomandate
- Servicii Web în pachetul de instruire Java
- Instruire în dezvoltarea jocului în C ++
- Pregătire completă de hacking etic
- Vegas Pro 13 Cursuri de instruire
Nou - Deschis
Un defect în starea deschisă arată că este în placa de dezvoltare și dezvoltatorii lucrează la remedierea acestuia. În cazul în care analiza află că problema înregistrată nu este un defect, acest lucru se poate întâmpla atunci când există un decalaj de înțelegere în comportamentul preconizat al sistemului. Dacă analiza spune că defectul este nevalid, dezvoltatorul va respinge defectul. Terminologia este „respinsă” sau „Revenire la testare”.
Nou - Reveniți la testare.
Cum trebuie să valideze testerul dacă defectul a fost într-adevăr un defect nevalid?
Acesta este scenariul în care un document cu cerințe precise ajută pe toți cei din echipă să ajungă la concluzia dacă defectul înregistrat a fost unul invalid sau valid. Referirea la documentele de cerință ajută testerul și dezvoltatorul să ajungă la aceeași concluzie și ușurează cu adevărat procesul de discuție.
Există scenarii în care corectitudinea documentelor de proiectare și a cerințelor este pusă la îndoială în timp ce se referă aceste documente în timp de discuții cu defecte, în astfel de momente, revenirea la Business Analyst este considerată cea mai bună opțiune pentru a clarifica interogările.
Ca o bună practică, documentele de cerință și de proiectare ar trebui să fie întotdeauna la zi pentru a le face referire fără ambiguități.
În starea „Deschis”, echipa de dezvoltare lucrează la remedierea defectului, odată ce defectul este remediat, starea se schimbă la „Gata pentru implementare”.
Deschis - Pregătit pentru implementare
Implementarea este procesul în care modificările sunt încărcate pe server, astfel încât echipa de testare să poată lucra la versiunea fixă a codului. De obicei, fiecare proiect are o echipă de implementare separată pentru această sarcină.
Deci, la nivel înalt, o echipă software constă în principal din aceste 3 grupuri -
- Dezvoltare
- Ciclul de viață defect în testare
- Desfășurare (sau uneori numită echipă Build)
Odată ce compilarea este implementată și defectul este din nou disponibil pentru testare, acesta este atribuit unui tester adecvat pentru sarcina de testare.
Defect atribuit - test de conducere.
Conducere de test - tester individual.
Defect atribuit - Tester individual.
În unele locuri de muncă, defectul este mai întâi atribuit testului de plumb și, la rândul său, îl atribuie testerului individual, însă în unele locuri, defectul este direct atribuit testerului care l-ar testa sau celui care a ridicat defectul.
Starea de aici se schimbă din Ready pentru implementare - Testare SIT gata.
Acum defectul este în placa testerului. Echipa de testare va valida defectul și există 2 posibilități, fie remedierea ar funcționa corect, fie aceeași problemă este întâlnită din nou. În funcție de rezultatul defectului se poate trece la următoarele stări -
Testare SIT gata - închis
Testare Ready SIT - redeschideți
În ambele scenarii de mai sus, testatorul trebuie să adauge comentariile testării efectuate. Aceasta include menționarea scenariilor testate și a datelor utilizate. În cazul în care defectul este redeschis, testerul trebuie să furnizeze pașii exacti care au condus din nou la eroare.
Redeschiderea stării este aceeași cu starea defectului „Nou”.
Odată ce defectul este redeschis, va urma din nou același ciclu.
Provocări defecte ale ciclului de viață
- Decizia privind severitatea defectelor - acesta este unul dintre subiectele comune de discuții (de multe ori se luptă) în rândul dezvoltatorilor de testatori v / s.
- Defectul nu este reproductibil în sistemul dezvoltatorului.
- Defect ridicat pe scenariul care nu este menționat în cerințe și documente de proiectare.
- Se găsește defect, dar același lucru nu poate fi ridicat, întrucât apariția scenariului în mediul de producție nu este posibilă.
Cum trebuie să depășească un tester peste provocări?
- Severitatea este direct proporțională cu impactul cauzat de defect, în cazul în care testerul nu poate continua din cauza defectului, acesta este cu siguranță marcat cu cea mai mare severitate.
- Dacă există o soluție de rezolvare pentru a continua testarea, aceasta trebuie marcată ca o gravitate medie. De asemenea, pe lângă luarea în considerare a impactului testării ulterioare a ciclului de viață a defectelor, severitatea poate fi decisă și luând în considerare situația în care un modul întreg eșuează, în acest caz, chiar dacă testarea unui alt modul poate fi efectuată, dar severitatea la modulul actual este ridicată. deci defectul trebuie marcat cu cea mai mare severitate.
- Dacă un defect nu este reproductibil în sistemul dezvoltatorului, există șanse ca mediul de dezvoltare și test să nu fie sincronizat. Un defect reproductibil în sistemul de testare este întotdeauna considerat ca un defect valid.
- Există situații în care un defect este înregistrat luând în considerare scenariul general de afaceri, dar scenariul direct nu este menționat în cerințele sau documentul de proiectare. Se consideră întotdeauna o cea mai bună practică să ia în considerare scenariile reale de afaceri în loc să urmezi doar pașii testului. Comunicarea cu analiștii de afaceri și alți părți interesate de produse joacă un rol important în înregistrarea unor astfel de defecte.
- Există scenarii în care un tester constată un decalaj în logica afacerii în faza de testare. Găsirea unor astfel de lacune este din nou considerată un mare avantaj pentru un tester. Lacunele de proiectare sunt gestionate de obicei prin îmbunătățiri.
- Îmbunătățire - Dacă un comportament trebuie modificat în faza de testare a ciclului de viață al software-ului, se creează o îmbunătățire care poate fi luată în versiunea curentă sau următoare, luând în considerare calendarul și lățimea de bandă a echipelor de dezvoltare și testare.
- Există câteva scenarii pe care un tester le-ar putea testa în timpul testării ad-hoc, care ar putea fi de fapt scenarii invalide, având în vedere posibilitatea apariției lor în producție.
Cine este cel mai bun prieten al testerului?
Unde trebuie să meargă un tester în caz de ambiguitate? Răspunsul depinde de tipul de interogare, în cazul în care o întrebare se referă la cerințe, este recomandabil să discutați în primul rând în cadrul echipei pentru a înțelege corect sistemul, poate fi consultând membrii seniori. Următorul punct de contact ar trebui să fie analiștii de afaceri.
Dacă întrebarea se referă la procesul de testare, este recomandabil să se ajungă la testul de plumb sau la managerul de testare.
Dacă întrebarea se referă la înțelegerea tehnicilor aplicației, membrul echipei de dezvoltare ar putea fi persoana potrivită.
Întrucât testarea este un proces care necesită o înțelegere generală a sistemului, comunicarea ajută un tester să obțină un răspuns rapid la întrebări, depinde doar de a pune întrebări corecte persoanelor potrivite. Evită să pui întrebări la momentul potrivit poate duce la un defect la scurgerea în mediul de producție.
Cât de important este rolul unui tester în compania de astăzi?
Există proiecte în care echipa de testare este la fel de importantă ca și echipa de dezvoltare, iar în unele scenarii, există mai multă dependență de echipa de test decât de echipa de dezvoltare. Scenariul ulterior este rar, dar există la unele locuri de muncă. Acest lucru s-a întâmplat de-a lungul timpului și ar putea fi pentru o anumită perioadă de timp în care echipa de dezvoltare nu are prea multă experiență în comparație cu echipa de testare. Există persoane care înțeleg fluxul general și funcționalitatea mai bune decât majoritatea celorlalți membri ai echipei. Un astfel de individ ar putea face parte din echipa de testare / dezvoltare. Acesta este unul dintre factorii care decide dependența de o echipă / individ pentru proiectul specific.
Care este calea carierei pentru un tester?
O persoană poate dura ceva timp pentru a înțelege procesul general de testare, domeniul și alte sarcini pe care este de așteptat să le lucreze în viața de zi cu zi. Pe baza acestei înțelegeri, este recomandabil să luăm decizia de a explora alte domenii pe care un tester ar putea să le adopte. Există întotdeauna oportunități în proces de automatizare a diverselor fluxuri. Crearea utilităților mici poate ajuta echipa într-un mod mare. Dacă un tester se pricepe la programare, este considerat un mare plus. Aceasta deschide oportunități pentru roluri de automatizare. Testarea performanței este, de asemenea, una dintre piesele de carieră pentru testeri. Analist de afaceri este o altă opțiune. Cunoștințe de domeniu bune, cu abilități de comunicare bune sunt seturile de abilități necesare pentru a fi analisti de afaceri. Testarea deschide multe oportunități pentru testatori de a lucra pe diverse domenii, instrumente, procese și așa mai departe. Depinde doar de o persoană care să ridice și să înceapă să se adâncească în interiorul uneia dintre zonele de testare. Există multe certificări specifice diferitelor instrumente pentru a fi specializate într-una din domeniile de testare. A avea certificarea furnizorului standard reprezintă un avantaj pentru a stimula cariera, însă certificatul singur nu vă poate ajuta pe termen lung, dacă nu este combinat cu experiența de muncă corectă.
Articole recomandate
Iată câteva articole care vă vor ajuta să obțineți mai multe detalii despre Testarea software, așa că treceți doar prin link.
- 6 Cele mai uimitoare întrebări pentru interviuri de testare software
- Cariere în testare software
- Cum să obții o creștere mai bună a carierei în activitatea de testare software