Ministerul Educației, Culturii și Cercetării

Universitatea Tehnică a Moldovei

Facultatea Calculatoare, Informatică și Microelectronică
Departamentul Ingineria Software și Automatică

Raport
Lucrarea de laborator nr.6
Disciplina: Testarea Software.
Tema: Descrierea efectiva si eficienta a defectelor.

Efectuat:st.gr. TI-172 Turculet Victor

Verificat: asistent universitar Rusu Cristian

Chișinău 2020

Scopul lucrării:
 Obținerea deprinderilor de descriere efectivă și eficientă a defectelor.

Obiectivele lucrării:
Efectuarea rapoartelor ce descriu 3 defecte.

Mersul lucrării:

Data: 30.04.2020
Produs: Ceas Versiunea 10.1.20.11
Dispozitiv: Samsung s10 OS Android 11
Severitate: Critic
Nume Secrieru Andrei

Rezumat: Adaugarea unei noi alarme.

Descriere: La încercarea utilizatorului să adauge o alarma nouă, acesta nu se salvează

și revine la lista cu timerele existente.

Precondiții: Trebuie să fie intrat în aplicație.

Pași prin care se reproduce:

1. Accesarea aplicației
2. Adăugarea unui nou timer
3. Îndeplinirea condițiilor
4. Salvarea timerului

Rezultatul actual: Timerul nu se salvează și se revine la lista actuala cu timere.

Rezultatul așteptat: Să fie afișat timerul nou.

 Data: 01.05.2020
Produs: Grand Auto Versiunea 1.0
Dispozitiv: - OS -
Severitate: Minor Prioritate Joasa
Nume Secrieru Andrei

Rezumat: Nu apare greșeală la înregistrare

Descriere: În cazul în care un utilizator încearca să se înregistreze pe site , la

îndeplinirea incorecta a spațiilor ( parolă incorectă , email incorect etc ) , nu este se
notifică utilizatorul despre greșeala efectuată.

Precondiții: Utilizatorul nu îndeplinește corect spațiile

Pași prin care se reproduce:

1. Accesarea paginei
2. Accesarea paginei de înregistrare
3. Îndeplinirea formularului
4. Accesarea butonului Submit
5.
Rezultatul actual: Reapare formularul de înregistrare fara notificări.

Rezultatul așteptat: Să notifice utilizatorul despre greșeală efectuată la înregistrare.

 Data: 03.05.2020
Produs: MAIBank Versiunea 2.1.5
Dispozitiv: Xiaomi OS Android 8
Severitate: Critic Prioritate Înaltă
Nume Secrieru Andrei

Rezumat: Aplicația se blochează

Descriere: În cazul în care utilizatorul nu are conexiune iar după ce restabilește

conexiunea aplicația refuza să funcționeze.

Precondiții: Dispozitivul nu are conexiune la internet

Pași prin care se reproduce:

1. Accesarea aplicației
2. Navigare
3. Apare eroarea ca nu este conexiune la internet
4. Utilizatorul se conectează la internet
5. Aplicația nu recunoaște că utilizatorul s-a conectat la internet
6. Aplicația se blochează
7.
Rezultatul actual: Aplicația se blochează

Rezultatul așteptat: Se face reconectare

Întrebări de control
1.
Ciclul de viață a unui defect poate include următoarele stări:
1. Nou (New): Când un defect este înregistrat și afișat pentru prima dată i se atribuie starea NOU;
2. Asignat (Assigned): După ce testerul a afișat defectul, liderul de echipă aprobă faptul că defectul
este autentic și îl atribuie dezvoltatorului respectiv sau echipei de dezvoltatori. Defectul primește
statutul ASIGNAT;
3. Deschis (Open): În acestă stare dezvoltatorul începe analiza defectului și lucrează la corectarea
lui;
4. Corectat (Fixed): Când dezvoltatorul a efectuat modificările necesare în cod și a verificat
modificările atunci defectului i se poate atribui statutul CORECTAT și este transmis echipei de
testare;
5. Retestare în așteptare (Pending retest): După remedierea defectului, dezvoltatorul transmite
codul modificat pentru retestare testerului. Aici codul este în așteptarea sfârșitului celorlalte teste.
Prin urmare, statutul său este în așteptarea retestării.
6. Retestare (Retest): La această etapă testerul retestează codul modificat pentru a verifica dacă
defectul a fost corectat sau nu.
7. Verificat (Verified): După retestare dacă defectul nu mai este prezent în software, se aprobă că
defectul este corectat și modifică starea în "verificat".
8. Redeschis (Reopen): Dacă defectul rămâne prezent după ce dezvoltatorul a modificat codul
testerul redeschide defectul atribuindu-i statutul ”Redeschis” și se reiau pașii de la început;
9. Închis (Closed): Dacă defectul nu se mai reproduce după ce dezvoltatorul a modificat codul
testerul îi atribuie statutul ”Închis”;
10. Dublat (Duplicate): Dacă defectul se repetă de două ori sau două defecte au aceiași descriere
atunci i se atribuie statutul ”Dublat”;
11. Respins (Rejected): Dacă dezvoltatorul consideră că defectul nu este autentic, el îl respinge.
12. Amânat (Deffered): Defectul cu statutul ”Amânat” va fi corectat în următoarele versiuni, aceasta
se poate întâmpla din mai multe motive, spre exemplu prioritatea acestuia este joasă și nu
afectează funcționalitățile principale ale produsului.
13. Nu este defect (Not a bug): Acest statut se atribuie defectelor atunci când ele nu de fapt nu
modifică funcționalitățile softului, de exemplu schimbarea culorii unui text sau poziția unui buton
pe ecran.

2.
Rapoartele defectelor sunt printre cele mai importante rezultate obținute din teste. Ele sunt la fel
de importante ca și planul de test și au un impact mai mare asupra calității produsului decât celelalte
rezultate ale testării. Merită efortul de a învăța cum se scriu rapoarte efective ale defectelor.
Rapoartele efective ale defectelor vor:
 Reduce numărul defectelor întoarse de la faza de dezvoltare;
 Mări viteza corectării erorilor;
 Ridica credibilitatea testului;
 Îmbunătăți legătura dintre testare și dezvoltare;
De ce unii testeri obțin un răspuns mult mai bun de la dezvoltatori decât alții? O parte din
răspunsul la această întrebare o reprezintă raportul defectelor. Urmând câteva reguli simple putem să
deschidem calea spre un mediu mult mai productiv. Obiectivul nu este să scriem un raport al
defectelor
perfect, dar unul efectiv, care redă un mesaj corect, face lucrul plăcut și ușurează procesul pentru
fiecare.
Accentul trebuie pus pe două aspecte ale raportului defectelor:
1) Descriere
2) Rezumat
Mai întâi, să aruncăm o privire la punctele esențiale pentru scrierea unor rapoarte efective.

Descrierea defectelor:
Iată câteva puncte-cheie pentru a fi siguri că raportul defectelor scris va fi unul efectiv.
1. Consistență – Spune clar, dar pe scurt.
2. Acuratețe – Este acesta un defect sau o greșeală a utilizatorului, neînțelegere, etc?
3. Neutralitate – Doar fapte. Fără înfrumusețări. Fără umor. Fără emoții.
4. Precizie – Concret, care este problema?
5. Izolare – Ce a fost făcut pentru a izola problema?
6. Generalizare – Ce a fost făcut pentru a înțelege cît de generală este problema?
7. Reproducere – Cum poate fi reprodusă problema (pașii concreți)?
8. Impact – Care este impactul asupra clientului? Care este impactul pentru testare?
9. Depanare – De ce este nevoie pentru a ușura depanarea? (urmărire, descărcare, log-uri, acces
imediat, etc.)
10. Evidență – Ce documentație demonstrează existența erorii?
Nu doar capacitățile tehnice bune de scriere duc la rapoarte efective ale defectelor. Este mai
important să te asiguri că ai pus întrebările corecte și ai răspuns corect la întrebări. Aceasta este cheia
care asigură că au fost acoperite punctele esențiale care vor aduce un beneficiu maxim.
Concluzii:

Rapoartele defectelor sunt printre cele mai importante rezultate obținute din teste. Ele sunt la
de importante ca și planul de test și au un impact mai mare asupra calității produsului decât celelalte
rezultate ale testării. Rapoartele efective ale defectelor vor: reduce numărul defectelor întoarse de la
faza de dezvoltare; mări viteza corectării erorilor; ridica credibilitatea testului; îmbunătăți legătura
dintre echipa de testare și dezvoltare.