PROIECT DE ABSOLVIRE

SOFTWARE DEVELOPMENT ACADEMY

​

NUME STUDENT: SCURTU IONELA

GRUPA : 69

PARTEA TEORETICĂ

• Explicați ce înseamnă requirements.

​

Specificații clare și verificabile ale funcționalităților, performanțelor, securității și altor atribute ale software-ului care trebuie testate.

​

• Explicați ce este un test condition.

Un test condition este o situație specifică sau un aspect distinct al software-ului care poate fi supus testării. Acesta identifică ce anume trebuie verificat pentru a evalua funcționalitatea sau un atribut al aplicației.

• Explicați ce este un test case și la ce folosește

​

Un test case (caz de testare) este un set specific de acțiuni executate asupra software-ului, având date de intrare precise și rezultate așteptate definite, cu scopul de a verifica o anumită funcționalitate sau un aspect al aplicației.

Un test case este folosit pentru a valida dacă software-ul funcționează corect în condiții specifice și dacă îndeplinește cerințele definite.

​

• Explicați care este scopul unui test plan

​

Scopul principal al unui test plan (plan de testare) este de a defini strategia, obiectivele, resursele și calendarul activităților de testare pentru un anumit proiect software. Acesta servește ca un document de ghidare centralizat pentru echipa de testare și pentru toate părțile interesate, asigurând o abordare structurată și controlată a procesului de testare.

• Enumerati statusurile pe care poate sa le aibă rularea unui test case

Rularea unui test case poate avea următoarele statusuri principale:

1.Passed (Trecut/Succes): Testul a fost executat, iar rezultatul obținut corespunde exact cu rezultatul așteptat.

2.Failed (Eșuat): Testul a fost executat, iar rezultatul obținut nu corespunde cu rezultatul așteptat, indicând un defect sau o problemă în software.

3.Blocked (Blocat): Testul nu a putut fi executat din cauza unei dependințe nerezolvate (de exemplu, o altă funcționalitate nu este implementată, datele de testare necesare lipsesc, mediul de testare nu este configurat corect).

4.Skipped (Sărit/Ignorat): Testul a fost intenționat omis de la execuție, de obicei din motive justificate (de exemplu, funcționalitatea nu este relevantă pentru iterația curentă, testul este duplicat, testul este instabil).

5.Pending (În așteptare): Testul nu a fost încă executat. Acesta este statusul inițial al unui test case înainte de a fi rulat.

6.In Progress (În curs de execuție): Testul este în prezent în proces de rulare.

​

• Enumerati statusurile pe care poate sa le aibă un defect.

Statusurile ciclului de viață al unui defect:

• New: Defect nou înregistrat.
• Open: Defect valid, în așteptare de rezolvare.
• Assigned: Defect alocat unui dezvoltator.
• In Progress: Dezvoltatorul lucrează la rezolvare.
• Fixed: Dezvoltatorul a implementat o soluție.
• Pending Verification: Soluția așteaptă testarea QA.
• Verified: QA a confirmat rezolvarea defectului.
• Closed: Defect rezolvat și închis.
• Rejected: Defect considerat invalid.
• Duplicate: Defect identic cu altul existent.
• Deferred: Rezolvare amânată.
• Reopened: Defectul nu a fost rezolvat corect și a fost redeschis.
• Generează Rezumatul Audio

​

• Explicați care este diferenta intre priority și severity 

Priority (prioritate) se referă la urgența cu care un defect sau o cerință trebuie rezolvată sau implementată. Este o decizie de business, influențată de impactul asupra utilizatorilor, termenelor limită ale proiectului și valorii pentru afacere.

Severity (severitate) se referă la impactul tehnic pe care un defect îl are asupra funcționalității sau stabilității software-ului. Descrie cât de grav afectată este aplicația de acel defect.

​

• Explicați ce este un raport și specificati diferenta intre test status report și test completion report

Un raport prezintă informații și concluzii despre testare.

Test Status Report: Raport periodic ce arată stadiul actual al testării (progres, rezultate parțiale, probleme).

Test Completion Report: Raport final la încheierea testării, ce rezumă tot procesul (obiective, rezultate finale, calitatea software-ului).

 Enumerati etapele procesului de testare

Procesul de testare software include de obicei următoarele etape:

1. Planificarea și Controlul Testării : Definirea obiectivelor, strategiei, resurselor și calendarului testării; monitorizarea și controlul activităților.
2. Analiza Cerințelor : Înțelegerea cerințelor software-ului pentru a identifica ce trebuie testat.
3. Proiectarea Testelor : Crearea și specificarea cazurilor de testare, a datelor de testare și a mediului de testare necesar.
4. Implementarea Testelor: Pregătirea și configurarea mediului de testare, crearea scripturilor de testare și organizarea cazurilor de testare.
5. Execuția Testelor : Rularea cazurilor de testare conform planului.
6. Evaluarea Criteriilor de Ieșire și Raportarea Testelor : Verificarea dacă obiectivele testării au fost atinse, analizarea rezultatelor testelor și generarea rapoartelor de testare.
7. Închiderea Activităților de Testare : Finalizarea documentației de testare, evaluarea lecțiilor învățate și arhivarea rezultatelor testării.

​

• Explicati diferenta intre retesting și regression testing

Retesting: Te concentrezi pe un defect specific care a fost găsit și apoi reparat. Execuți din nou testele care au eșuat din cauza acelui defect, pentru a confirma că problema a dispărut. Este o verificare directă a soluției implementate.

Regression Testing: După ce s-a făcut o modificare în program (fie că s-a reparat un defect, s-a adăugat o funcționalitate nouă sau s-a schimbat ceva), vrei să te asiguri că această schimbare nu a stricat ceva ce funcționa deja bine. Execuți un set de teste pe funcționalitățile existente pentru a verifica dacă nu au apărut probleme noi, neintenționate.

• Explicati diferenta intre functional testing si non-functional testing

Functional Testing se concentrează pe ce face software-ul. Verifică dacă fiecare funcționalitate a aplicației funcționează conform cerințelor specificate. Răspunde la întrebarea: "Funcționează corect această caracteristică?". Exemple includ testarea login-ului, a adăugării de produse în coș, a procesării plății etc.

Non-Functional Testing se concentrează pe cum funcționează software-ul. Evaluează aspecte care nu sunt direct legate de funcționalitățile specifice, ci mai degrabă de calitatea experienței utilizatorului și de performanța sistemului. Răspunde la întrebări precum: "Cât de rapid este?", "Este sigur?", "Este ușor de utilizat?". Exemple includ testarea performanței, a securității, a uzabilității, a fiabilității etc.

 Enumerati tehnicile de testare și grupati-le în    categoria corespunzătoare

Black-Box Testing:

1. Boundary Value Analysis: Testează limitele datelor de intrare/ieșire.
2. Equivalence Partitioning: Testează grupuri de date care ar trebui tratate similar.
3. Decision Table Testing: Testează combinații de condiții și acțiuni.
4. State Transition Testing: Testează schimbările de stare ale sistemului.
5. Use Case Testing: Testează scenarii complete de utilizare.
6. Domain Analysis: Explorează domeniul aplicației pentru teste relevante.
7. Syntax Testing: Testează formatul corect al datelor de intrare.

​

Experience-Based Testing:

1. Error Guessing: Testerul anticipează erori bazat pe experiență.
2. Exploratory Testing: Testare simultană de învățare, proiectare și execuție.
3. Checklist-Based Testing: Testare ghidată de liste de aspecte de verificat.

White-Box Testing:

1. Statement Coverage: Asigură că fiecare linie de cod este executată.
2. Branch Coverage: Asigură că toate ramurile de decizie sunt testate.
3. Path Coverage: Asigură că toate căile de execuție sunt testate.
4. Condition Coverage: Asigură că toate condițiile logice sunt testate.
5. Function Coverage: Asigură că toate funcțiile sunt apelate.
6. Basis Path Testing: Identifică și testează un set minim de căi independente.
7. Data Flow Testing: Examinează cum sunt procesate datele în cod.
8. Mutation Testing: Introduce modificări în cod pentru a testa eficiența testelor.

PARTEA PRACTICA

LISTA DE REQUIREMENT-URI PENTRU TRENDYOL

USER STORY-URI PENTRU FUNCȚIONALITĂȚILE PRINCIPALE

TEST CONDITIONS

​

R2 – Selectare produs și comandă

1. Accesare pagină produs și vizualizare informații.
2. Adăugare produs în coș.
3. Modificare cantitate produs în coș.
4. Accesare pagină checkout.
5. Alegere metodă de plată.
6. Completare date de livrare.
7. Finalizare comandă + email de confirmare.

R14 – Încărcarea rapidă a pagini

1. Home page se încarcă < 0,5s pe Wi-Fi.
2. Pagina produsului se încarcă < 0,5s pe Wi-Fi.
3. Coșul se încarcă < 0,5s pe Wi-Fi.
4. Checkout-ul se încarcă < 0,5s pe Wi-Fi.
5. Home page se încarcă < 0,5s pe 4G.
6. Pagina produsului se încarcă < 0,5s pe 4G.
7. Coșul se încarcă < 0,5s pe 4G.
8. Pagina se modifică corect pe diferite dispozitive (mobil, tabletă, laptop).

 TEST CASE-URI

DETALIEREA TEST CASE-URILOR

EXECUTIA TEST CASE-URILOR

IN URMA TESTARI AU FOST DESCOPERITE 5 BUG-URI

MATRICEA DE TRASABILITATE

CONCLUZI GENERALE

• În urma testării site-ului, majoritatea funcționalităților sunt implementate corect, însă au fost identificate 5 bug-uri legate de viteza de încărcare pe conexiuni mai lente și de aranjarea incorectă a elementelor pe pagină. Aceste probleme ar putea afecta experiența utilizatorului, mai ales pe dispozitive mobile sau cu conexiuni 4G. Recomandăm rezolvarea acestor bug-uri înainte de lansare, pentru a asigura o experiență optimă.