Ministerul Educației, Culturii și Cercetării al Republicii Moldova

Universitatea Tehnică a Moldovei

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

Raport
Disciplina: Clitatea Software

Tema: Specificații eroare

A efectuat: st. gr. TI-171 Teleatnic Alina

A verificat: Lungu Mihail

Chișinău 2020
 Scopul :
1. Identificarea abaterilor al site-ului web : https://loving-hermann-
e2094b.netlify.app/contact.html;
2. Înregistrarea erorilor în Jira;
3. Fiecare eroare trebuie să conțină câmpurile de prioritate și severitate setate;
4. Toate câmpurile trebuie să fie completate cu informații corecte și valide aplicate proiectului.
Precondiții:
1. Utilizatorul este adăugat la un proiect în Jira (CAL);
2. Utilizatorul trebui să aibă primul domeniu al site-ului web:
https://loving-hermann-e2094b.netlify.app/contact.html
Specificații teoretice:
În timp ce definiția unei erori poate varia ușor, un lucru este clar: pentru a preveni marea
varietate de probleme care pot apărea înainte, în timpul sau după lansarea unui produs, companiile și
persoanele fizice trebuie să fie proactive în a se asigura că aplicațiile lor sunt îndeplinind standardele
înalte ale consumatorilor de astăzi. 
Cum se clasifică varietatea de erori software?
Organizăm erorile după tip (vizual, conținut, utilizare) și severitate (critic, ridicat, scăzut):
Critică: prevenirea unei funcții de bază a aplicației sau a site-ului web, cauzează o posibilă
pierdere de venit pentru compania care rulează aplicația sau site-ul web - de exemplu, o blocare a
aplicației sau „imposibilitatea de conectare”
Înalt: impact grav asupra experienței utilizatorului, dar nu împiedică funcționarea aplicației sau
a site-ului web
Scăzut: impact minim asupra experienței utilizatorului
Vizual: utilizatorul poate îndeplini o sarcină, dar interfața pare greșită, de obicei din cauza
problemelor de design receptiv, CSS, HTML sau cadru de aspect
Conținut: date lipsă, imagini sau linkuri rupte
Utilizare: îmbunătățiri ale caracteristicilor și funcțiilor existente care ar face produsul mai ușor
și mai intuitiv de utilizat
Cum găsești aceste bug-uri?
Testare funcțională : verificarea faptului că toate funcțiile funcționează din perspectiva
utilizatorului
Test Smoke: testarea pieselor funcționale de bază ale software-ului înainte de a trece la
următoarea etapă de testare
Sanity Test: confirmarea faptului că modificările de cod nu au creat noi probleme
 Test de compatibilitate: testare pe dispozitive sau medii
Test de regresie : o versiune mai aprofundată a unui test de fum
Test de acceptare a utilizatorului: testare cu utilizatorii reali ai unei aplicații pentru a se asigura
că funcționalitatea este așa cum era de așteptat, fără prejudecăți ale testării interne
Testare exploratorie : testare fără scripturi care permite testatorilor libertatea de a merge pe mai
multe căi diferite - poate mai puțin obișnuite sau intuitive - pentru a identifica erori care altfel ar
aluneca prin crăpăturile unui test scriptat (testul IO oferă o varietate de tipuri de test explorator,
enumerate mai jos)
Test rapid: un test care este conceput pentru a prinde numai bug-uri cu prioritate ridicată și
poate fi finalizat în doar (2) ore
Test focalizat: testarea unei caracteristici specifice a secțiunii unei aplicații
Test de acoperire: testarea dacă aplicația dvs. va funcționa pe dispozitive de dimensiuni diferite
ale ecranului, browsere diferite, pe mai multe versiuni de iOS sau pe diferite dispozitive Android
Test de utilizare : colectarea de feedback de la utilizatori cu privire la ușurința și intuitivitatea
utilizării unei aplicații
Test personalizat: cel mai versatil și mai larg tip de test, permițându-vă să extrageți diferite
componente din fiecare dintre testele pe care le oferim pentru a oferi un domeniu de aplicare mai larg.
Testarea beta : testarea pre-lansării
Testare cutie neagră : testare fără cunoștințe despre modul în care software-ul a fost pus la
punct[1];

Figura 1. 1 Elementele unui Bug

Efectuarea lucrării:
Deschiderea și crearea raportului unui bug:

Figura 1.2 Deschiderea unui bug

Updatarea unui bug:

Figura 1.3 Update a bug

Descriere bug:

Figura 1.4 Descrierea unui bug(exemplu bug deschis)

 Concluzii:
În lucrarea dată au fost identificate abaterile site-ului web : https://loving-hermann-
e2094b.netlify.app/contact.html, și apoi au fost înregistra în Jira. Pentru fiecare eroare au fost
specificate câmpurile obligatorii și toate câmpurile au fost completate cu informații corecte și valide
pentru proiect. Erorile au fost adăugate pe board-ul Sprint-ului curent (Lab1_Lab2_Sprint).
 Bibliografia
1. https://test.io/blog/what-defines-a-software-bug/
Anexe

Anexa 1

Figura 1.5 Bug Deschis 1

Anexa 2

Figura 1.6 Bug Deschis 2

 Anexa 3

Figura 1.7 Bug Deschis 3

Anexa 4

Figura 1.8 Bug Deschis 4

 Anexa 5

Figura 1.9 Bug Deschis 5

Anexa 6

Figura 1.10 Bug Deschis 6

 Anexa 7

Figura 1.11 Bug Deschis 7

Anexa 8

Figura 1.12 Bug Deschis 8

 Anexa 9

Figura 1.13 Bug Deschis 9

Anexa 10

Figura 1.14 Bug Deschis 10