Introducere

durata de viață a unui tester de asigurare a calității va fi considerată incompletă dacă termenii ‘testarea fumului’, ‘testarea sănătății’ și ‘testarea regresiei’ nu sunt infuzați în acesta. Deși acestea sunt unele utilizate în mod regulat Termeni, există unele concepții greșite comune în jurul lor prea.

înainte de a începe în detalii de fum, bun-simț și de testare de regresie și ceea ce înseamnă de fapt, vă permite să treacă prin unele concepții greșite comune și mituri în jurul lor:

1. testarea fumului și testarea sănătății mintale sunt aceleași și pot fi utilizate în mod interschimbabil : acest lucru nu este adevărat și nu trebuie făcut niciodată, de ce? vom discuta acest lucru în acest articol.
2. testarea sănătății este echivalentă cu testarea acceptării: testarea acceptării se face pentru a se asigura că construirea îndeplinește toate cerințele specificate de client înainte de lansare, în timp ce testarea Sănătății se face pentru a se asigura că produsul este sănătos, rațional pentru testarea mai detaliată. Acestea nu sunt și nu trebuie utilizate interschimbabil.
3. dacă fac testarea fumului, pot sări peste testarea sănătății: Testarea fumului este o testare la nivel foarte înalt, deoarece această testare se face pentru a se asigura că această construcție este potrivită pentru a începe orice alt tip de testare. De exemplu, acest lucru ar putea fi doar un test pentru a asigura construi instalează și apoi testarea bun-simț poate începe. Deși uneori, cazurile de testare a fumului sunt rulate împreună cu cazurile de testare a sănătății, acestea nu trebuie confundate cu unul și același lucru.
4. testarea regresiei nu este legată de testarea fumului sau testarea sănătății: în teorie, testarea sănătății este un subset de testare a regresiei. Unele cazuri de testare de regresie cu prioritate ridicată constituie de obicei un caz de testare a sănătății.
5. dacă intenționez să rulez suita de teste de regresie completă – nu trebuie să rulez niciun test de fum sau un test de sănătate: deși acest lucru poate fi adevărat în unele cazuri, deoarece testarea sănătății este oricum un subset de teste de regresie, este totuși recomandabil să executați mai întâi cazurile de testare a sănătății și apoi să le urmați cu restul cazurilor de testare a regresiei.

în acest articol, vom încerca să clar de mai sus confuzii pentru o dată pentru totdeauna.

în cazul în care doriți să citiți mai multe despre testarea manuală, consultați linkul AICI.

Notă: Pentru că vom folosi termenul ‘software Build’ de multe ori în articol, vă permite să-l definească aici. „Software Build” este un proces de conversie a codului sursă, într-o aplicație de utilizator, după mai multe revizuiri și modificări de cod și crearea de software Build implică mai multe procese cum ar fi „controlul versiunii, calitatea codului & compilare” și software build este, de asemenea, rezultatul acestui proces de construcție. În acest articol, o versiune va fi menționată ca o versiune testabilă a software-ului.

testarea fumului

testarea fumului este o abordare care se realizează de obicei în etapele inițiale de dezvoltare ale ciclului de viață al dezvoltării Software(SDLC) pentru a vă asigura că funcționalitățile de bază ale unui program funcționează bine fără probleme. Acesta este executat înainte de orice teste funcționale detaliate sunt efectuate pe software-ul.

intenția principală a testării fumului nu este de a efectua teste profunde, ci de a verifica dacă funcționalitățile principale sau principale ale programului sau ale software-ului funcționează bine. Testarea fumului își propune să respingă o construcție prost ruptă în etapa inițială, astfel încât echipa de testare să nu piardă timpul în instalarea & testarea aplicației software.

testarea fumului este, de asemenea, numit ca test de verificare a construi.

să vedem un exemplu simplu în care vi se oferă o aplicație de e-mail pentru testare. Funcțiile importante ar fi conectarea la aplicația de e-mail, compunerea unui e-mail și trimiterea acestuia, nu? Și, în cazul în care e-mailul nu este trimis, are sens să testați alte funcționalități precum schițe, mesaje șterse, arhive Etc? Aceasta înseamnă că va trebui să renunțați la construcție fără validare suplimentară. Aceasta se numește testarea fumului.

obiectivul principal al testării fumului este de a testa zonele critice și nu aplicația completă.

când se efectuează testarea fumului

• când dezvoltatorii oferă o versiune nouă echipei QA. O construcție proaspătă aici înseamnă când construcția are noi modificări făcute de dezvoltatori.
• atunci când un nou modul este adăugat la funcționalitatea existentă.

automatizare& testarea fumului:

De obicei, acesta este tipul de testare care este executat înainte de cazuri reale de testare de automatizare poate rula. Pentru organizațiile care au construit testarea continuă, testarea fumului este echivalentă cu instalarea cu succes a construcției pentru rularea cazurilor de testare sau executarea primului caz de testare. Deci, acesta nu este un tip de testare care este automatizat în mod deliberat, dar dacă automatizarea testului este pusă în aplicare, automatizarea testului poate rula cu succes numai după ce software-ul a trecut testarea fumului. Sau altfel, primul caz de testare care execută ar putea eșua.

testarea bun-simț

testarea bun-simț este un fel de testare efectuate pentru a verifica dacă un produs software funcționează corect atunci când un nou modul sau funcționalitate devine puse în aplicare la un produs existent. Testarea Sanity este o tehnică de testare software care face o evaluare rapidă a calității versiunii software pentru a determina dacă este eligibilă pentru alte runde de testare sau nu.

testarea bun-simț este de obicei efectuată după ce a primit o versiune de software destul de stabilă sau, uneori, atunci când o versiune de software ar fi putut suferi modificări minore în cod sau funcționalitate. Acesta decide dacă testarea de la un capăt la altul a unui produs software trebuie efectuată în continuare sau nu.

testarea bun-simț este, de asemenea, o testare la nivel de suprafață, care ajută în a decide dacă construi software-ul este suficient de bun pentru a trece la următorul nivel de testare.

de ce efectuați testarea Sanității

• pentru a verifica și valida conformitatea funcționalităților și caracteristicilor nou adăugate în codul existent.
• pentru a se asigura că modificările introduse nu afectează alte funcționalități existente ale produsului.
• pentru a decide testarea ulterioară poate fi reportată sau nu.

când se efectuează testarea Sanității

• Build este primit după multe regresii sau dacă există o modificare minoră a codului.
• build-ul este primit după remedierea erorilor.
• chiar înainte de implementarea pe producție.

Automation& testarea sănătății:

având în vedere că testarea sănătății este considerată ca un subset al testării regresiei, acestea sunt cazurile de testare care pot fi automatizate. O abordare recomandată este de a executa aceste cazuri de testare înainte de a rula suita completă de teste de regresie. Beneficiul este că, dacă există erori în cazurile de testare a sănătății, atunci erorile pot fi raportate mai devreme decât mai târziu.

testarea regresiei

testarea regresiei este verificarea „remedierilor de erori sau a oricăror modificări ale cerinței” și asigurarea faptului că acestea nu afectează alte funcționalități ale aplicației. Testarea regresiei este eficientă în automatizare și se efectuează de obicei după ce au fost făcute unele modificări în construirea software-ului după modificări ale cerințelor sau remedieri de erori.

odată ce testarea bun-simț a funcționalității modificate este finalizată, toate caracteristicile afectate ale aplicației necesită testare completă. Aceasta se numește testare de regresie.ori de câte ori remedieri de erori se face în software-ul existent, unele scenarii de testare trebuie să fie executate, pentru a verifica remedieri de erori. Pe lângă acestea, echipa QA trebuie să verifice și zonele afectate, pe baza modificărilor codului. În testarea regresiei, toate aceste scenarii de testare vor trebui executate, pentru a avea grijă de funcționalitățile conexe.

când se efectuează testarea de regresie

• după modificarea Codului în funcție de modificările necesare
• după ce unele funcții noi sunt adăugate la aplicație
• după ce unele remedieri de erori sunt încorporate în construcție

automatizare& testarea regresiei:

cazurile de testare a regresiei sunt de fapt cazurile de testare ideale pentru automat. De obicei, atunci când o organizație începe automatizarea, acestea sunt cazurile de testare care sunt automatizate mai întâi. Dacă testarea regresiei este o activitate care necesită mult timp pentru testerii dvs. și aceleași cazuri de testare se repetă de mai multe ori, atunci este timpul să începeți să vă gândiți și la automatizare.

dacă sunteți în căutarea unui instrument care vă poate ajuta să începeți călătoria dvs. de automatizare, atunci trebuie să vă asigurați că alegeți instrumentul potrivit. Un instrument care vă poate oferi, de asemenea, ROI pe eforturile investite. Avem ghidul care vă poate ajuta acolo:

10 Points to Help You Choose the Right Test Automation Tool

Differences Between Smoke vs Sanity vs Regression Testing

puncte cheie

• testarea fumului și a sănătății ajută echipa QA să economisească timp testând rapid pentru a vă asigura dacă o aplicație funcționează corect sau nu. De asemenea, se asigură că produsul este eligibil pentru teste suplimentare. În timp ce testarea regresiei ajută la creșterea încrederii cu privire la calitatea software-ului după o anumită schimbare. Mai ales, că modificările de cod nu afectează zonele conexe.

• testarea fumului se face atât de echipa dev, cât și de echipa QA și poate fi luată ca un subset de teste riguroase. Întrucât ambele Sanity & testarea regresiei se face numai de către echipa QA. De asemenea, testarea sănătății poate fi considerată ca un subset de testare a acceptării.

• testarea fumului este executată în stadiul inițial al SDLC, pentru a verifica funcționalitățile de bază ale unei aplicații. Întrucât Sanity & testarea regresiei se face în etapa finală a SDLC, pentru a verifica principalele funcționalități ale unei aplicații.

• Conform cerinței de testare& disponibilitatea timpului, echipa QA poate fi nevoită să execute Sanity, Smoke& teste de regresie pe construirea software-ului lor. În astfel de cazuri, testele de fum sunt executate mai întâi, urmate de testarea sănătății & apoi pe baza disponibilității timpului este planificată testarea regresiei.

în practică, toate echipele QA trebuie să facă teste de fum, Sănătate și regresie. Toate aceste tipuri de testare au un număr predefinit de cazuri de testare care sunt executate de mai multe ori. Această execuție repetitivă le face, de asemenea, un candidat ideal pentru automatizarea testelor. Când căutați automatizare, vi se recomandă să utilizați un instrument care vă oferă ROI pe automatizare din etapele inițiale. Testsigma este un astfel de instrument.