Introducere: Modul de lucru al echipei LITRIGE se bazează pe un Proces specific de lucru. Noi numim asta un Proces de Testare pe care echipa îl urmărește în activitatea de testare. Procesul de Testare în cadrul echipei LITRIGE: Mai jos este descris un overview al Procesului nostru de testare:

1. Înțelegerea funcționalității produsului:
   1. Se citește și se înțelege documentația produsului (cerințele funcționale ale produsului, caietul de sarcini, manualul tehnic, manualul utilizatorului, standarde folosite în dezvoltarea produsului).
   2.  Oferim suport în crearea documentației de mai sus, la nevoie, prin prisma experienței noastre de 10 ani în domeniu (vă ajutăm să creați cerințele funcționale, manualul utilizatorului sau alte documente necesare pentru descrierea produsului din punct de vedere tehnic și al ușurinței folosirii lui din punct de vedere al utilizatorului).
2. Implementarea de Cazuri/Scenarii de Testare pe baza documentației tehnice:
   1. Pentru fiecare funcționalitate a produsului se creează Scenarii de Testare, care vor fi folosite pentru a valida că acea funcționalitate merge cum ar trebui (conform cu documentele tehnice create inițial).
   2. Scenariile de Testare sunt organizate și structurate în funcție de tipul produsului și nevoile clientului (în funcție de procesul de dezvoltare al produsului, avem scenarii de testare pentru funcționalitățile care se dezvoltă prima dată)
   3. Aceste scenarii sunt salvate în diferite tooluri de specialitate (de exemplu: TestRail, Tuskr, Tosca-qTest, etc.), dar ele pot fi de asemenea ținute și în documente ca Word/Excel în prima instanță.
3. Automatizarea testelor manuale (dacă există această posibilitate pe proiect): 
   1. Se selectează Testele Manuale care pot fi automatizate. Testele Manuale sunt testele care sunt rulate manual de către un Tester; practic, Testerul execută pas cu pas din ce scrie în Cazul/Scenariul de testare prezentat la punctul 2.
   2.  Automatizarea testelor se poate face doar dacă există un framework în care se introduc instrucțiuni pentru a realiza acțiunile manuale efectuate de un tester. De exemplu, pentru o aplicație web sau mobilă, automatizarea funcționalității de “LOGIN” este adesea importantă, deoarece vrem să ne asigurăm că nu există probleme între versiunile de software sau când aceasta va fi lansată publicului larg. De asemenea, automatizarea este utilă pentru că un tester ar trebui să execute de multe ori aceste teste pentru funcționalitatea de “LOGIN”, ceea ce poate dura mai mult timp decât dacă aceste teste ar fi rulate automat, uneori chiar în afara programului de lucru, cum ar fi noaptea sau în weekend.
   3. Se automatizează testele selectate și se verifică dacă testul rulează corect (dacă fiecare pas face ceea ce trebuie).
   4. La finalul rulării testelor automate, va fi generat un raport cu situația testelor (câte sunt PASS, câte sunt FAILED și ce probleme au fost descoperite).
4. Crearea Planului/Planurilor de testare: 
   1.  În funcție de momentul în dezvoltarea produsului, se creează mai multe Planuri de Testare (ce teste vor fi executate la momentul respectiv).
   2. Se creează Planul de rulare a tuturor Testelor (aceasta durează cel mai mult).
   3. Se creează Planul de rulare a Testelor bazat pe diferite funcționalități (de exemplu, în luna aceasta avem implementată funcționalitatea X și o vom testa doar pe aceasta).
   4. Se creează Planul de rulare a testelor de Regresie.
   5. Se creează Planul de rulare a testelor de Sanity. f. Și altele.
5.  Configurarea mediului de testare manuală/automată: 
   1. Pentru a putea rula testele pe un produs, este necesar să se configureze mediile de testare ale acelui produs (de exemplu, pentru o aplicație mobilă, ai nevoie de mai multe modele de telefoane cu diferite versiuni de Android).
   2. Mediul de testare poate fi reconfigurat pentru a se potrivi nevoilor proiectului.
6. Campania de rulare a Testelor (Cazurile/Scenariile de testare) Manuale/Automate și Raportarea defectelor: 
   1. Rularea testelor manuale/automate în funcție de Planul de Testare stabilit cu Managerul de Proiect/ Product Owner.
   2. Raportarea defectelor descoperite pe parcursul rulării testelor - acestea sunt raportate către echipa de proiect/dezvoltare pentru a fi reparate în următoarea versiune de software.
7. Support oferit echipei de Dezvoltare a produsului: 
   1. Oferim suport în reproducerea problemelor găsite - ajutăm echipa de dezvoltare să reproducă problemele pentru a vedea cauza și pentru a le repara.
   2.  Retestarea problemei/defectelor odată ce a apărut un fix pentru aceasta.
8. Generarea unui Raport de Testare: 
   1. Raportul de testare va fi rezultatul campaniei de testare pe o anumită versiune de produs.
   2. Raportul de testare include: i. Numărul de teste rulate pe fiecare funcționalitate. ii. Numărul de teste PASSED. iii. Numărul de teste FAILED cu defectul atașat fiecărui test FAILED. iv. Numărul total de defecte noi descoperite. v. Numărul total de defecte cunoscute nereparate. vi. Numărul total de defecte cunoscute, trecute ca și reparate, dar care încă apar în noua versiune de software.

9. Procesul de Testare de mai sus este repetat la fiecare versiune nouă de software. După acest proces, de obicei, produsul este lansat mai întâi către o parte din clienți/utilizatori, iar apoi, după o scurtă perioadă (de obicei săptămâni), dacă nu s-au găsit probleme majore, este dat către publicul larg.

   La fiecare dintre cei 8 pași, Tester-ul trebuie să aibă cunoștințele necesare pentru a realiza corect și în detaliu sub-pașii care sunt la fiecare etapă în parte