Meniu

Testarea software-ului practic Flux de proces QA (Cerințe de lansare)

practical software testing qa process flow

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

O prezentare completă a procesului de testare a software-ului QA de la un capăt la altul:

Notă - Publicăm din nou această postare utilă cu conținut actualizat.

Meseria de profesionist în testarea software-ului nu este una ușoară. Este plin de provocări, la fel de solicitante. Testatorii ar trebui să fie atenți și entuziaști în fiecare etapă a ciclului de viață al aplicației.

Deși există provocări, există și câteva oportunități extraordinare de a învăța și de a explora diferitele aspecte ale metodologiilor de testare, proceselor și, bineînțeles, software-ului în detaliu.

Rolul unui inginer de testare începe foarte devreme. Și chiar de la conceptualizarea proiectului, testerii sunt implicați în discuții cu proprietarul produsului, managerul de proiect și diversele părți interesate.

Cerințe de eliberat

Acest tutorial despre „Procesul de testare a software-ului” vă oferă o prezentare completă a diferitelor faze din STLC, împreună cu provocările implicate și cele mai bune practici pentru a depăși acele provocări într-un mod ușor de înțeles.

Ce veți învăța:

Cerința de lansare - o prezentare generală completă

Ciclul de viață al testării software-ului

De la cerință la eliberare, fiecare fază este explicată clar. Să le aruncăm o privire în detaliu.

# 1) Cerință

Un proiect nu poate decola fără a avea o cerință clară. Aceasta este cea mai crucială fază în care ideile trebuie să fie scrise într-un document bine înțeles și formatat. Dacă faceți parte din proiect în care participați la faza de colectare a cerințelor, atunci considerați-vă norocos.

vreau să testez produse pentru companii

Întrebându-se de ce? Acest lucru se datorează faptului că asistați la un proiect realizat de la zero. Deși există mândrie în a fi de la începuturi, vine și cu unele responsabilități și provocări.

Provocări

Nu ne putem imagina toate cerințele pentru a ne aduna într-o singură ședință. Fii suficient de răbdător.

Se vor întâmpla o mulțime de discuții, dintre care unele pot fi pur și simplu irelevante pentru proiectul dvs., dar chiar și atunci pot conține informații vitale pentru proiectul dvs. Uneori viteza discuțiilor poate depăși capacitățile dvs. de înțelegere sau pur și simplu nu ați acorda atenție proprietarului produsului.

Imaginea de mai jos evidențiază pașii cruciale implicați în colectarea cerințelor:

Cerințe Ciclul de viață

Fiecare informație care este ratată are un impact imens asupra înțelegerii și testării generale a proiectului. Pentru a depăși acest lucru, iată câteva bune practici care ar trebui urmate în această fază.

Cele mai bune practici

  • Ține-ți mintea deschisă și fii atent la fiecare cuvânt al proprietarului produsului.
  • Nu ascultați, ștergeți-vă îndoielile, oricât de mici par să fie.
  • Folosiți întotdeauna caiete pentru păstrarea rapidă a notelor. Ar trebui să utilizați un laptop, numai dacă puteți tasta cu adevărat la o viteză corectă.
  • Repetați propozițiile și clarificați-le din PO care credeți că ați înțeles.
  • Desenați diagrame bloc, text de legătură etc. pentru a clarifica cerințele într-o perioadă ulterioară.
  • Dacă echipele se află în locații diferite, încercați din greu, făcându-l o înregistrare WebEx sau similară. Va fi întotdeauna util atunci când aveți o îndoială după terminarea discuțiilor.

Deși nu există un perete separat ca atare pentru fiecare fază, cerințele se schimbă chiar foarte târziu în dezvoltare. Deci, ideea este să preluăm cea mai mare parte a cerinței și să o documentăm corect.

Odată ce a fost documentat cu toate punctele necesare, distribuiți și discutați toate părțile interesate, astfel încât orice sugestii sau modificări să fie surprinse devreme și înainte de a trece mai departe, toată lumea se află pe aceeași pagină.

# 2) Strategia de testare

Se presupune că testerii vor veni cu o strategie de testare care nu este suficientă doar pentru a testa software-ul mai bine, ci ar trebui să le insufle încredere tuturor părților interesate în ceea ce privește calitatea produsului.

Strategia de testare

Provocări

Cel mai crucial aspect al acestei faze este crearea unei strategii care, atunci când se lucrează, ar trebui să furnizeze un produs software fără erori, durabil și acceptat de utilizatorii săi finali.

Strategiile de testare sunt ceva ce nu veți schimba în fiecare zi. În unele cazuri, trebuie să discutați strategiile de testare și cu clienții. Deci, această parte ar trebui tratată cu o mare importanță.

Cele mai bune practici

  • Iată câteva dintre cele mai bune practici, care, atunci când sunt urmate, vă pot oferi o ușurare deosebită și pot duce la testarea fără probleme.
  • Consultați din nou documentul de cerință. Evidențiați punctele de import în raport cu mediul software-ului țintă.
  • Faceți o listă a mediilor în care software-ul va fi implementat.
  • Mediile pot fi înțelese ca un tip de sisteme de operare sau dispozitive mobile.
  • Dacă Windows este sistemul de operare, listați toate versiunile ferestrei în care veți testa software-ul. Dacă versiunile viz. Windows 7, Windows 10 sau Windows Server (Server) nu sunt încă definite în documentul de cerință, atunci este momentul când acestea ar trebui discutate.
  • Într-o notă similară, obțineți browserele țintă cu versiunile discutate și documentate dacă AUT este un sistem bazat pe web.
  • Faceți o listă cu toate software-urile terță parte de care aplicația va avea nevoie (dacă este necesar / acceptat). Acestea pot include Adobe Acrobat, Microsoft Office, orice programe de completare etc.

Aici ideea din spatele nostru este să păstrăm toate platformele, dispozitivele și software-urile necesare și necesare, conform cărora aplicația noastră va trebui să funcționeze înaintea noastră, astfel încât să poată fi formulată o strategie cuprinzătoare.

Figura de mai jos vă va ajuta să înțelegeți schema strategiei de testare dacă lucrați la un proiect agil:

Strategia de testare

# 3) Planificarea testului

După ce testerii sunt înarmați cu toate informațiile referitoare la AUT, faza de planificare este locul în care strategia este implementată.

La fel ca o strategie de testare, planificarea testelor este, de asemenea, o fază crucială.

Planul de testare

Provocări

Deoarece succesul (sau eșecul) AUT depinde în mare măsură de modul în care au fost efectuate testele, această fază devine un aspect important al întregului ciclu de viață al testului. De ce? Deoarece o parte a testării este definită în această fază.

Pentru a depăși unele provocări, aceste bune practici pot fi cu adevărat utile.

Cele mai bune practici

  • Rețineți întotdeauna, să nu lăsați nici o piatră neîntreruptă atunci când vine vorba de testarea aplicației dvs.
  • Este timpul să formulați o strategie de testare.
  • Creați o matrice a mediului, astfel încât software-ul să fie testat pe toate platformele.
  • De exemplu, Windows 10 + Internet Explorer 11+ Windows Office 2010+.
  • La fel ca browserul Chrome Android 4.2.2+.
  • Dacă aplicația dvs. funcționează cu mai multe baze de date (dacă este documentată), păstrați bazele de date (MySQL, Oracle, SQLServer) în matricea de testare astfel încât să fie prea integrate cu unele teste.
  • Configurați mașinile de testat corespunzător și denumiți-le ca SetUp1, SetUp2 etc.
  • SetUp1 va avea Windows 7+ IE 10+ Office 2007+.
  • SetUp2 poate avea Windows 10+ IE Edge + Office 2013+.
  • SetUp3 poate avea un telefon Android cu fișierul .apk instalat.
  • Felicitări! Configurarea testului dvs. este gata și ați inclus, de asemenea, orice combinație posibilă de platforme pe care aplicația dvs. va funcționa.

# 4) Testare

Găsirea erorilor

În cele din urmă, construcția aplicației dvs. a ieșit și sunteți gata să găsiți erori! Acum este timpul să lucrați la planificarea testelor și să găsiți cât mai multe bug-uri posibil. Vor exista câteva faze între timp dacă lucrați într-un mediu agil, apoi pur și simplu urmați acele metode scrum.

Diagrama de mai jos prezintă clasificarea diferitelor tipuri de testare:

Tipuri de testare

Provocări

Testarea este un proces greoi care în sine este predispus la erori! Găsiți multe provocări în timp ce testați o aplicație. Mai jos sunt prezentate câteva dintre cele mai bune practici de salvat.

Cele mai bune practici

Înveselește-te! Încercați să găsiți defecte în cod. Trebuie să acordați atenție funcționării generale a software-ului.

  • Este întotdeauna recomandabil să priviți aplicația cu un aspect proaspăt, FĂRĂ să treceți prin cazuri de testare.
  • Urmați calea de navigare a software-ului dvs. (AUT).
  • Familiarizați-vă cu AUT.
  • Citiți acum cazurile de testare (Toate) ale unui anumit modul (Poate la alegere).
  • Acum mergeți la AUT și potriviți constatările cu cele menționate în secțiunea așteptată a cazurilor de testare.
  • Ideea din spatele acestui lucru este de a testa fiecare caracteristică menționată pe fiecare platformă acceptată.
  • Notați fiecare deviere oricât de banală pare să fie.
  • Scrieți pașii privind modul în care ajungeți la orice abatere, faceți capturi de ecran, capturați jurnalele de erori, jurnalele serverului și orice altă documentație justificativă care poate dovedi existența defectelor.
  • Nu ezitați să întrebați. Deși aveți documentul de cerință, vor exista momente în care veți avea îndoieli.
  • Contactați dezvoltatorii (dacă aceștia stau lângă dvs. sau sunt la îndemână), înainte de a ajunge la proprietarul produsului. Înțelegeți perspectiva dezvoltatorului cu privire la funcționarea software-ului. Intelege-le. Dacă credeți că această implementare nu este conformă cu cerința, atunci informați managerul de testare.

# 5) Înainte de lansare

Înainte de a lansa orice produs pe piață, trebuie asigurată calitatea produsului. Software-urile sunt dezvoltate o dată, dar sunt de fapt testate până când sunt înlocuite sau eliminate.

Provocări

Software-ul trebuie testat riguros pentru mulți dintre parametrii săi.

Este posibil ca parametrii să nu fie limitați la:

  • Funcționalitate / Comportament.
  • Performanţă.
  • Scalabilitate.
  • Compatibil cu platformele menționate.

Provocarea este, de asemenea, de a prezice rata de succes a unei aplicații care depinde de multe iterații ale testării efectuate.

Cele mai bune practici

  • Asigurați-vă că toate caracteristicile de pe toate platformele sunt testate.
  • Evidențiați zonele care nu sunt testate sau cea care necesită mai multe eforturi de testare.
  • Păstrați o matrice cu toate rezultatele testului înainte de lansare. Matricea de testare va oferi o imagine de ansamblu a stabilității produsului. De asemenea, va ajuta conducerea să ia un apel la datele de lansare.
  • Oferiți contribuția / sugestiile dvs. echipei despre experiențele dvs. în timpul testării produsului.
  • Contribuția dvs., considerându-vă utilizator final, va beneficia în mare măsură de software.
  • Din cauza crizei de timp sau a oricărei alte situații de acest gen, fie ne lipsim unele teste, fie nu ne adâncim în acest sens. Nu ezitați să transmiteți managerului dvs. starea de testare.
  • Prezentați cardul de sănătate al aplicației părților interesate. Cardurile de sănătate ar trebui să conțină un număr de defecte înregistrate, deschise, închise, intermitente, cu severitatea și prioritatea lor.
  • Elaborați un document de lansare și distribuiți acest lucru întregii echipe.
  • Lucrați la documentul de lansare pregătit.
  • Îmbunătățiți zonele sugerate de conducere / echipă.

Imaginea de mai jos arată harta ciclului de viață al lansării software-ului:

Înainte de eliberare

# 6) Eliberare

În cele din urmă, vine momentul în care trebuie să livrăm produsul către utilizatorii săi. Cu toții, ca echipă, am muncit din greu pentru a semna produsul și a permite software-ului să-și ajute utilizatorii.

Provocări

Inginerii de testare a software-ului sunt în primul rând responsabili pentru lansarea oricărui software. Această activitate necesită un flux de lucru orientat spre proces. Iată câteva dintre cele mai bune practici implicate în această fază.

Cele mai bune practici

  • Amintiți-vă întotdeauna, nu lucrați la documentul de lansare la data lansării reale.
  • Planificați întotdeauna activitatea de lansare înainte de data efectivă de lansare.
  • Standardizați documentul conform politicilor companiei.
  • Documentul dvs. de versiune ar trebui să încerce să stabilească așteptări pozitive din partea software-ului.
  • Menționați în document în mod clar toate cerințele software și hardware specifice versiunilor lor.
  • Includeți toate defectele deschise și gravitatea acestora.
  • Nu ascundeți zonele importante afectate din cauza defectelor deschise. Acordați-le un loc în documentul de lansare.
  • Obțineți documentul revizuit și semnat digital (poate diferi în conformitate cu politica companiei).
  • Aveți încredere și expediați documentul de lansare împreună cu software-ul.

Proces de testare QA pe un proiect real - Metoda cascadei

Am primit o întrebare interesantă de la un cititor, Cum se efectuează testarea într-o companie, adică într-un mediu practic?

Cei care tocmai trec de la facultate și încep să caute locuri de muncă au această curiozitate - cum ar fi mediul de lucru real într-o companie?

Aici m-am concentrat asupra procesului efectiv de lucru al Testarea software-ului în companii .

Procesul real de testare în companii

Ori de câte ori primim un proiect nou, există o întâlnire inițială de familiaritate a proiectului. În această întâlnire, discutăm practic cine este clientul? care este durata proiectului și când este livrarea acestuia? Cine sunt toți implicați în proiect, adică manager, lideri tehnici, clienți QA, dezvoltatori, testeri etc.?

Din SRS (specificația cerințelor software) se dezvoltă planul de proiect. Responsabilitatea testerilor este de a crea un plan de testare software din acest SRS și planul de proiect. Dezvoltatorii încep codificarea de la proiectare. Lucrările de proiect sunt împărțite în diferite module, iar aceste module de proiect sunt distribuite între dezvoltatori.

Între timp, responsabilitatea unui tester este de a crea un scenariu de testare și de a scrie cazuri de testare în conformitate cu modulele atribuite. Încercăm să acoperim aproape toate cazurile de testare funcțională din SRS. Datele pot fi menținute manual în unele șabloane de teste Excel sau instrumente de urmărire a erorilor.

Când dezvoltatorii finalizează modulele individuale, aceste module sunt atribuite testerelor. Testarea fumului se efectuează pe aceste module și dacă nu reușesc acest test, modulele sunt reatribuite dezvoltatorilor respectivi pentru o soluție.

Pentru modulele trecute, testarea manuală se efectuează din cazurile de testare scrise. Dacă se găsește o eroare care este atribuită dezvoltatorului modulului și se conectează la instrument de urmărire a erorilor . La remedierea erorilor, un tester efectuează verificarea erorilor și testarea regresiei tuturor modulelor conexe. Dacă eroarea trece de verificare, este marcată ca verificată și marcată ca închisă. În caz contrar, ciclul de erori menționat mai sus se repetă. (Voi acoperi ciclul de viață al erorilor într-o altă postare)

Se efectuează diferite teste pe module individuale și teste de integrare pe integrarea modulelor. Aceste teste includ testarea compatibilității, adică testarea aplicațiilor pe diferite hardware, versiuni ale sistemului de operare, platforme software, diferite browsere etc.

Testarea sarcinii și a stresului este, de asemenea, efectuată conform SRS. În cele din urmă, testarea sistemului se realizează prin crearea unui mediu client virtual. Odată executate toate cazurile de testare, se întocmește un raport de testare și se ia decizia de a elibera produsul!

Pași în cerințele de lansare

Mai jos sunt prezentate detaliile fiecărei etape de testare care se desfășoară în fiecare calitate a software-ului și ciclul de viață al testării specificat de Standardele IEEE și ISO.

# 1) Revizuirea SRS : Revizuirea specificațiilor cerințelor software.

# 2) Obiective sunt setate pentru lansări majore.

# 3) Data țintă planificat pentru lansări.

# 4) Plan detaliat al proiectului este construit. Aceasta include decizia privind specificațiile de proiectare.

# 5) Elaborați planul de testare se bazează pe specificațiile de proiectare.

# 6) Planul de testare: Aceasta include obiective, metodologia adoptată în timpul testării, caracteristicile care trebuie testate și care nu trebuie testate, criteriile de risc, programul de testare, suport multiplataforma și alocarea resurselor pentru testare.

# 7) Specificații de testare: Acest document include detalii tehnice (cerințe software) necesare înainte de testare.

# 8) Scrierea cazurilor de testare

# 9) Dezvoltare: Modulele sunt dezvoltate unul câte unul.

# 10) Legarea instalatorilor: Instalatorii sunt construiți în jurul produsului individual.

cum deschid un fișier eps

#unsprezece) Procedură de construcție : O versiune include instalatorii produselor disponibile - platforme multiple.

# 12) Testare: Test de fum (BVT): Test de bază al aplicației pentru a lua o decizie privind testarea ulterioară.

  • Testarea noilor caracteristici
  • Cross-browser și testarea pe mai multe platforme
  • Testarea stresului și testarea scurgerilor de memorie.

# 13) Raport rezumat test

# 14) Înghețarea codului

  • Nu mai sunt adăugate funcții noi în acest moment.

# 15) Testare: Testarea construcției și regresiei.

# 16) Decizia de a elibera produsul.

# 17) Scenariul post-lansare pentru obiective ulterioare.

Acesta a fost un rezumat al unui proces real de testare într-un mediu de companie.

Concluzie

Slujba unui tester de software este plină de provocări, dar plăcută. Aceasta este pentru cineva care este la fel de pasionat, motivat și plin de entuziasm. Găsirea de defecte la cineva nu este întotdeauna o treabă ușoară! Acest lucru necesită o mulțime de abilități și un ochi de taur asupra defectelor.

Pe lângă toate calitățile, un tester ar trebui să fie și orientat spre proces. La fel ca toate celelalte industrii, proiectele din IT sunt prea lucrate în etape, în care fiecare fază are câteva obiective bine definite. Și fiecare obiectiv are un criteriu de acceptare bine definit. Un inginer de testare trebuie să poarte multe încărcături de calitate software pe umerii săi.

În timp ce lucrează în orice fază a software-ului, testerii ar trebui să urmeze cele mai bune practici și ar trebui să se alinieze la procesul implicat în fazele respective. Urmarea celor mai bune practici și a unui proces bine formulat nu doar că ajută la ușurarea funcționării testerelor, ci și la asigurarea calității software-ului.

Ați făcut parte din oricare dintre fazele de mai sus? Simțiți-vă liber să ne împărtășiți experiențele de mai jos.

Lectură recomandată

^