Testarea fumului vs. Testarea sănătății: Diferența cu exemplele

smoke testing vs sanity testing

Explorați în detaliu diferențele dintre testarea fumului și testarea sănătății cu exemple:

În acest tutorial, vom învăța ce este Testarea sănătății și Testarea fumului în Testarea software-ului. De asemenea, vom învăța diferențele cheie dintre testarea sănătății și a fumului cu exemple simple.

De cele mai multe ori ne confundăm între semnificația Testării sănătății și Testarea fumului. În primul rând, aceste două testări sunt foarte „ diferit ”Și sunt efectuate în diferite etape ale unui ciclu de testare.

Ce veți învăța:

• Testarea sănătății
• Experienta mea
• Sanity Testing Vs Regression Testing
• Strategie pentru testarea aplicațiilor mobile
• Masuri de precautie
• Testarea fumului
• Exemple de testare a fumului
  • # 1) Testarea acceptării
  • # 2) Testarea integrării
  • # 3) Testarea sistemului
• Importanța în metodologia SCRUM
• Testul de fum împotriva testelor de acceptare
• Ciclul de testare a fumului
• Cine ar trebui să efectueze testul de fum?
• De ce ar trebui să automatizăm testele de fum?
• Avantaje și dezavantaje
• Diferența dintre testarea fumului și a sănătății
  • TESTAREA FUMULUI
  • TESTAREA SĂNĂTĂȚII
• Lectură recomandată

Testarea sănătății

Testarea sănătății se face atunci când, în calitate de QA, nu avem suficient timp pentru a rula toate cazurile de testare, fie că este vorba Testarea funcțională , UI, OS sau testare browser.

Prin urmare, aș defini,

„Sanity Testing ca o execuție de test care se face pentru a atinge fiecare implementare și impactul acesteia, dar nu în profunzime sau în profunzime, poate include teste funcționale, UI, versiune etc., în funcție de implementare și impactul acesteia.”

Nu intrăm cu toții într-o situație în care trebuie să ne semnăm într-o zi sau două, dar versiunea pentru testare nu este încă lansată?

cum se scrie un eșantion de plan de testare

Ah, da, pun pariu că și dumneavoastră trebuie să vă confruntați cu această situație cel puțin o dată în experiența dvs. de testare software. Ei bine, m-am confruntat foarte mult, deoarece proiectele mele erau în mare parte agile și uneori ni se cerea să le livrăm în aceeași zi. Hopa, cum aș putea testa și elibera versiunea într-o perioadă de ore?

Uneori mă înnebuneam, deoarece chiar dacă era o funcționalitate mică, implicația ar putea fi extraordinară. Și ca cireașă pe tort, uneori clienții pur și simplu refuză să acorde timp suplimentar. Cum aș putea finaliza întregul test în câteva ore, să verific fiecare funcționalitate, Gandaci și să-l eliberezi?

Răspunsul la toate aceste probleme a fost foarte simplu, adică nimic altceva decât utilizarea Strategia Sanity Testing.

Când facem acest test pentru un modul sau funcționalitate sau un sistem complet, Testează cazurile pentru executare sunt selectate astfel încât să atingă toate piesele importante ale acestora, adică testarea largă, dar superficială.

Uneori testarea se face chiar aleatoriu, fără cazuri de testare. Dar amintește-ți, Testul de sănătate ar trebui să se facă numai atunci când alergați în scurt timp, nu folosiți niciodată acest lucru pentru lansările obișnuite. Teoretic, această testare este un subset de Testarea regresiei .

Experienta mea

Din cei peste 8 ani de carieră în testarea software-ului, am lucrat timp de 3 ani Metodolog agil y și a fost momentul în care am folosit cel mai mult un test de sănătate.

Toate versiunile mari au fost planificate și executate într-un mod sistematic, dar uneori, versiunile mici au fost solicitate să fie livrate cât mai curând posibil. Nu am avut mult timp să documentăm cazurile de testare, să executăm, să facem documentația erorilor, să facem regresia și să urmăm întregul proces.

Prin urmare, următoarele sunt câteva dintre indicațiile cheie pe care obișnuiam să le urmez în astfel de situații:

# 1) Așezați-vă cu managerul și echipa de dezvoltatori atunci când discută despre implementare, deoarece trebuie să lucreze rapid și, prin urmare, nu ne putem aștepta să ne explice separat.

Acest lucru vă va ajuta, de asemenea, să vă faceți o idee despre ce urmează să implementeze, ce domeniu va afecta etc., acesta este un lucru foarte important de făcut, uneori pur și simplu nu ne dăm seama de implicații și dacă există vreo funcționalitate existentă va fi împiedicat (în cel mai rău caz).

#Două) Deoarece vă lipsesc timpul, până când echipa de dezvoltare lucrează la implementare, puteți nota cazurile de testare aproximativ în instrumente precum Evernote etc. Dar asigurați-vă că le scrieți undeva, astfel încât să le puteți adăuga ulterior la instrumentul cazului de testare.

# 3) Păstrați-vă gata testul conform implementării și, dacă credeți că există semnalizări roșii, cum ar fi crearea anumitor date, dacă un banc de testare va dura timp (și este un test important pentru lansare), ridicați imediat aceste semnalizări și informați managerul sau PO despre blocajul rutier.

Doar pentru că clientul dorește cât mai curând, nu înseamnă că un QA va fi lansat chiar dacă este pe jumătate testat.

# 4) Faceți un acord cu echipa și managerul dvs. că, din cauza reducerii timpului, veți comunica erorile doar echipei de dezvoltare și procesul formal de adăugare, marcarea erorilor pentru diferite etape în instrumentul de urmărire a erorilor se va face mai târziu pentru a economisi timp .

# 5) Când echipa de dezvoltare testează la sfârșit, încercați să le împerecheați (numită împerechere dev-QA) și efectuați o rundă de bază pe configurarea lor în sine, acest lucru va ajuta la evitarea înainte și înapoi a construcției dacă implementarea de bază eșuează .

# 6) Acum că aveți versiunea, testați mai întâi regulile de afaceri și toate cazurile de utilizare. Puteți păstra teste precum validarea unui câmp, navigare etc. pentru mai târziu.

# 7) Indiferent de erorile pe care le-ați găsi, notați-le pe toate și încercați să le raportați împreună dezvoltatorilor decât să raportați individual, pentru că le va fi ușor să lucreze la o grămadă.

# 8) Dacă aveți o cerință pentru ansamblu Test de performanta sau Testarea stresului sau încărcării, apoi asigurați-vă că aveți un cadru de automatizare adecvat pentru același lucru. Deoarece este aproape imposibil să le testezi manual cu un test de sănătate.

# 9) Aceasta este cea mai importantă parte și, într-adevăr, ultimul pas al strategiei de testare a sănătății - „Când redactați e-mailul de lansare sau documentul, menționați toate cazurile de testare pe care le-ați executat, erorile găsite cu un marker de stare și dacă a rămas ceva neatestat menționează-l cu motivele ' Încercați să scrieți o poveste clară despre testarea dvs. care să transmită tuturor despre ceea ce a fost testat, verificat și ceea ce nu a fost.

Am urmat acest lucru religios când foloseam acest test.

Permiteți-mi să vă împărtășesc propria experiență:

# 1) Lucram la un site web și obișnuia să afișeze anunțuri pop-up bazate pe cuvinte cheie. Agenții de publicitate obișnuiau să plaseze suma licitată pentru anumite cuvinte cheie care aveau un ecran conceput pentru aceleași. Valoarea implicită a ofertei se afișa ca 0,25 USD, pe care ofertantul o putea chiar modifica.

Mai era un loc în care apărea această ofertă implicită și putea fi schimbată și la altă valoare. Clientul a venit cu o cerere de a schimba valoarea implicită de la 0,25 USD la 0,5 USD, dar a menționat doar ecranul evident.

În timpul discuției noastre de brainstorming, am uitat (?) De celălalt ecran, deoarece nu a fost folosit prea mult în acest scop. Dar, în timp ce testam când am rulat cazul de bază al ofertei de 0,5 USD și am verificat cap la cap, am constatat că cronjob-ul pentru același lucru eșua, deoarece la un loc găsea 0,25 USD.

Am raportat acest lucru echipei mele și am făcut schimbarea și am livrat-o cu succes în aceeași zi.

#Două) În cadrul aceluiași proiect (menționat mai sus), ni s-a cerut să adăugăm un câmp de text mic pentru note / comentarii pentru licitare. A fost o implementare foarte simplă și ne-am angajat să o livrăm în aceeași zi.

Prin urmare, așa cum s-a menționat mai sus, am testat toate regulile de afaceri și cazurile de utilizare din jurul său și când am făcut unele teste de validare, am constatat că, atunci când am introdus o combinație de caractere speciale, cum ar fi, pagina sa prăbușit.

Ne-am gândit la asta și ne-am dat seama că ofertanții reali nu vor folosi în niciun caz astfel de combinații. Prin urmare, am lansat-o cu o notă bine elaborată despre această problemă. Clientul a acceptat asta ca o eroare, dar a fost de acord cu noi să o implementăm mai târziu, deoarece a fost o eroare severă, dar nu una anterioară.

# 3) Recent, lucram la un proiect de aplicație mobilă și aveam obligația de a actualiza ora de livrare afișată în aplicație conform fusului orar. Nu era doar să fie testat în aplicație, ci și pentru serviciul web.

În timp ce echipa de dezvoltare lucra la implementare, am creat scripturile de automatizare pentru testarea serviciului web și scripturile DB pentru schimbarea fusului orar al articolului de livrare. Acest lucru mi-a salvat eforturile și am putea obține rezultate mai bune într-o perioadă scurtă de timp.

Sanity Testing Vs Regression Testing

Mai jos sunt câteva diferențe între cele două:

Strategie pentru testarea aplicațiilor mobile

Trebuie să vă întrebați de ce menționez în mod specific despre aplicațiile mobile aici?

Motivul este că versiunea de sistem de operare și browser pentru aplicațiile web sau desktop nu variază prea mult și mai ales dimensiunile ecranului sunt standard. Dar cu aplicațiile mobile, dimensiunea ecranului, rețeaua mobilă, versiunile sistemului de operare etc. afectează stabilitatea, aspectul și, pe scurt, succesul aplicației dvs. mobile.

Prin urmare, o formulare strategică devine critică atunci când efectuați această testare pe o aplicație mobilă, deoarece un eșec vă poate cauza probleme mari. Testarea trebuie făcută inteligent și cu precauție.

Iată câteva indicații care vă vor ajuta să efectuați cu succes această testare pe o „aplicație mobilă”:

# 1) În primul rând, analizați impactul versiunii sistemului de operare asupra implementării împreună cu echipa dvs.

Încercați să găsiți răspunsuri la întrebări precum, comportamentul va fi diferit între versiuni? Implementarea va funcționa sau nu cu cea mai mică versiune acceptată? Vor exista probleme de performanță pentru implementarea versiunilor? Există vreo caracteristică specifică a sistemului de operare care ar putea afecta comportamentul implementării? etc.

#Două) În nota de mai sus, analizați și modelele de telefon, adică există funcții ale telefonului care vor avea impact asupra implementării? Este implementarea schimbării comportamentului cu GPS? Se schimbă comportamentul de implementare cu camera telefonului? etc. Dacă constatați că nu există niciun impact, evitați testarea pe diferite modele de telefoane.

# 3) Dacă nu există modificări ale UI pentru implementare, vă recomand să păstrați testarea UI cu cea mai mică prioritate, puteți informa echipa (dacă doriți) că UI nu va fi testată.

# 4) Pentru a vă economisi timp, evitați testarea pe rețele bune, deoarece este evident că implementarea va funcționa așa cum era de așteptat pe o rețea puternică. Aș recomanda să începeți cu testarea pe o rețea 4G sau 3G.

# 5) Această testare trebuie făcută în mai puțin timp, dar asigurați-vă că efectuați cel puțin un test de teren, cu excepția cazului în care este vorba de o simplă modificare a UI.

# 6) Dacă trebuie să testați o matrice de sisteme de operare diferite și versiunea lor, v-aș sugera să o faceți într-un mod inteligent. De exemplu, alegeți cea mai mică, medie și cea mai recentă pereche de versiune de sistem de operare pentru testare. Puteți menționa în documentul de lansare că nu toate combinațiile sunt testate.

# 7) Pe o linie similară, pentru testul de sănătate al implementării UI, utilizați dimensiuni mici, medii și mari ale ecranului pentru a economisi timp. De asemenea, puteți utiliza un simulator și un emulator.

Masuri de precautie

Testarea sănătății se efectuează atunci când alergați în scurt timp și, prin urmare, nu vă este posibil să rulați fiecare caz de testare și, cel mai important, nu vi se acordă suficient timp pentru a vă planifica testarea. Pentru a evita jocurile de vina, este mai bine să luați măsuri de precauție.

În astfel de cazuri, lipsa comunicării scrise, documentația de testare și ratele sunt destul de frecvente.

Pentru a vă asigura că nu cădeați pradă acestui lucru, asigurați-vă că:

• Nu acceptați niciodată o versiune pentru testare până când nu vi se oferă o cerință scrisă împărtășită de client. Se întâmplă ca clienții să comunice modificările sau implementările noi verbal sau în chat sau printr-un simplu liner într-un e-mail și se așteaptă ca noi să tratăm acest lucru ca pe o cerință. Obligați clientul să vă ofere câteva puncte de funcționalitate de bază și criterii de acceptare.
• Notați întotdeauna cazurile de testare și erorile dvs. dacă nu aveți suficient timp pentru a le scrie cu atenție. Nu le lăsați niciodată fără acte. Dacă există ceva timp, împărtășiți-l cu conducătorul sau echipa dvs., astfel încât, dacă lipsește ceva, să-l poată indica cu ușurință.
• Dacă dvs. și echipa dvs. nu aveți timp, asigurați-vă că erorile sunt marcate în starea corespunzătoare într-un e-mail? Puteți trimite prin e-mail lista completă de bug-uri către echipă și faceți ca dezvoltatorii să le marcheze corespunzător. Păstrați întotdeauna mingea în terenul celuilalt.
• Daca ai Cadrul de automatizare gata, folosiți asta și evitați să faceți Teste manuale , astfel, în mai puțin timp puteți acoperi mai mult.
• Evitați scenariul „eliberarea în 1 oră”, cu excepția cazului în care sunteți 100% sigur că veți putea livra.
• Nu în ultimul rând, așa cum s-a menționat mai sus, redactați un e-mail de lansare detaliat care să comunice ceea ce este testat, ce este lăsat deoparte, motive, riscuri, ce bug-uri sunt rezolvate, ce sunt „mai târziu” etc.

În calitate de QA, ar trebui să judecați care este cea mai importantă parte a implementării care trebuie testată și care sunt părțile care pot fi lăsate în afara sau testate de bază.

Chiar și într-un timp scurt, planificați o strategie despre cum doriți să faceți și veți putea obține cele mai bune în intervalul de timp dat.

Testarea fumului

Testarea fumului nu este o testare exhaustivă, ci este un grup de teste care sunt executate pentru a verifica dacă funcționalitățile de bază ale acelei construcții funcționează bine așa cum era de așteptat sau nu. Acesta este și ar trebui să fie întotdeauna primul test care se face pe orice versiune „nouă”.

Când echipa de dezvoltare lansează o versiune pentru QA pentru testare, este evident că nu este posibil să testați întreaga versiune și să verificați imediat dacă oricare dintre implementări are erori sau dacă vreuna dintre funcționalitățile de lucru este întreruptă.

Având în vedere acest lucru, cum se va asigura un QA că funcționalitățile de bază funcționează bine?

Răspunsul la aceasta va fi efectuarea unui Testarea fumului .

Odată ce testele sunt marcate ca teste de fum (în suita de teste), doar atunci construcția este acceptată de QA pentru testarea aprofundată și / sau regresia. Dacă oricare dintre testele de fum eșuează, versiunea este respinsă și echipa de dezvoltare trebuie să rezolve problema și să lanseze o nouă versiune pentru testare.

Teoretic, testul de fum este definit ca testare la nivel de suprafață pentru a certifica că construcția furnizată de echipa de dezvoltare echipei QA este pregătită pentru teste ulterioare. Această testare este, de asemenea, efectuată de echipa de dezvoltare înainte de a elibera construcția echipei QA.

Această testare este utilizată în mod normal în testarea integrării, testarea sistemului și testarea nivelului de acceptare. Nu tratați niciodată acest lucru ca un substitut pentru testul final final pentru a încheia complet . Acesta cuprinde atât teste pozitive, cât și negative, în funcție de implementarea construcției.

Exemple de testare a fumului

Acest test este utilizat în mod normal pentru integrare, acceptare și Testarea sistemului .

În cariera mea de QA, am acceptat întotdeauna o construcție numai după ce am efectuat un test de fum. Deci, să înțelegem ce este un test de fum din perspectiva tuturor acestor trei testări, cu câteva exemple.

# 1) Testarea acceptării

Ori de câte ori o versiune este lansată în QA, testul de fum sub forma unui Testarea de acceptare ar trebui făcut.

În acest test, primul și cel mai important test de fum este de a verifica funcționalitatea de bază a implementării. În acest fel, ar trebui să verificați toate implementările pentru acea versiune specială.

Să luăm următoarele exemple ca implementări realizate într-o versiune pentru a înțelege testele de fum pentru acestea:

• Am implementat funcționalitatea de conectare pentru a permite driverelor înregistrate să se conecteze cu succes.
• Am implementat funcționalitatea tabloului de bord pentru a afișa rutele pe care trebuie să le execute astăzi un driver.
• Am implementat funcționalitatea pentru a afișa un mesaj adecvat dacă nu există rute pentru o anumită zi.

În versiunea de mai sus, la nivelul de acceptare, testul de fum va însemna să verifice dacă cele trei implementări de bază funcționează bine. Dacă oricare dintre aceste trei este rupt, atunci QA ar trebui să respingă construcția.

# 2) Testarea integrării

Această testare se face de obicei atunci când modulele individuale sunt implementate și testate. În Testarea integrării la nivel, această testare este efectuată pentru a vă asigura că toate funcțiile de integrare de bază și de la capăt la cap funcționează bine așa cum era de așteptat.

Poate fi integrarea a două module sau a tuturor modulelor împreună, prin urmare complexitatea testului de fum va varia în funcție de nivelul de integrare.

Să luăm în considerare următoarele exemple de implementare a integrării pentru această testare:

• Implementarea integrării modulelor de rută și oprire.
• Am implementat integrarea actualizării stării sosirii și reflectă același lucru pe ecranul opririlor.
• Implementarea integrării preluării complete până la modulele de funcționalitate de livrare.

În această construcție, testul de fum nu numai că va verifica aceste trei implementări de bază, ci și pentru a treia implementare, câteva cazuri se vor verifica și pentru integrarea completă. Ajută foarte mult să aflăm problemele care sunt introduse în integrare și cele care au trecut neobservate de echipa de dezvoltare.

# 3) Testarea sistemului

După cum sugerează și numele, la nivel de sistem, testarea fumului include teste pentru cele mai importante și utilizate frecvent fluxuri de lucru ale sistemului. Acest lucru se face numai după ce sistemul complet este gata și testat, iar acest test pentru nivelul de sistem poate fi denumit test de fum înainte de testarea de regresie.

Înainte de a începe regresia sistemului complet, caracteristicile elementare de la capăt la cap sunt testate ca parte a testului de fum. Suita de testare a fumului pentru sistemul complet cuprinde cazuri de testare de la capăt la cap, pe care utilizatorii finali le vor folosi foarte frecvent.

Acest lucru se face de obicei cu ajutorul instrumentelor de automatizare.

Importanța în metodologia SCRUM

În zilele noastre, proiectele urmează cu greu metodologia Waterfall în implementarea proiectului, în mare parte toate proiectele urmând Agile și SCRUM numai. Comparativ cu metoda tradițională a cascadei, Testarea fumului este apreciată în SCRUM și Agile.

Am lucrat 4 ani în SCRUM . Și, după cum știm că în SCRUM, sprinturile au o durată mai scurtă și, prin urmare, este extrem de important să se facă această testare, astfel încât construcțiile eșuate să poată fi raportate imediat echipei de dezvoltare și fixate și ele.

qa întrebări și răspunsuri la interviu pdf

Următoarele sunt câteva la pachet despre importanța acestor teste în SCRUM:

• Din sprintul de două săptămâni, repriza este alocată QA-ului, dar uneori versiunile QA sunt întârziate.
• În sprinturi, este mai bine pentru echipă ca problemele să fie raportate într-un stadiu incipient.
• Fiecare poveste are un set de criterii de acceptare, prin urmare testarea primelor 2-3 criterii de acceptare este egală cu testarea fumului pentru acea funcționalitate. Clienții resping livrarea dacă un singur criteriu eșuează.
• Imaginați-vă ce se va întâmpla dacă echipa de dezvoltare va livra versiunea în 2 zile și vor mai rămâne doar 3 zile pentru demonstrație și veți întâlni un eșec de funcționalitate de bază.
• În medie, un sprint are povești cuprinse între 5-10, prin urmare, atunci când este dată construirea, este important să vă asigurați că fiecare poveste este implementată așa cum era de așteptat înainte de a accepta construirea în testare.
• Când sistemul complet urmează să fie testat și regresat, un sprint este dedicat activității. O săptămână poate puțin mai puțin pentru a testa întregul sistem, prin urmare este foarte important să verificați cele mai de bază funcționalități înainte de a începe regresia.

Testul de fum împotriva testelor de acceptare

Testarea fumului este direct legată de testarea acceptării construcției (BAT).

În BAT, facem același test - pentru a verifica dacă versiunea nu a eșuat și dacă sistemul funcționează bine sau nu. Uneori, se întâmplă ca atunci când este creată o versiune, să apară unele probleme și când este livrată, versiunea nu funcționează pentru QA.

Aș spune că BAT face parte dintr-o verificare a fumului, deoarece dacă sistemul eșuează, cum puteți, în calitate de QA, să acceptați construcția pentru testare? Nu doar funcționalitățile, sistemul în sine trebuie să funcționeze înainte ca QA să continue testarea în profunzime.

Ciclul de testare a fumului

Următorul diagramă explică ciclul de testare a fumului.

Odată ce o versiune este implementată într-un QA, ciclul de bază urmat este că, dacă testul de fum trece, construirea este acceptată de echipa QA pentru testare ulterioară, dar dacă nu reușește, construirea este respinsă până când problemele raportate sunt remediate.

Ciclul de testare

Cine ar trebui să efectueze testul de fum?

Nu întreaga echipă este implicată în acest tip de testare pentru a evita pierderea de timp a tuturor QA-urilor.

Testarea fumului este realizată în mod ideal de către conducătorul QA, care decide în funcție de rezultat dacă va transmite echipa pentru testarea ulterioară sau o va respinge. Sau, în absența potențialului, QA-urile pot efectua și ele aceste teste.

Uneori, când proiectul este unul la scară largă, un grup de QA poate efectua, de asemenea, acest test pentru a verifica dacă există showstoppers. Dar acest lucru nu este așa în cazul SCRUM, deoarece SCRUM este o structură plană, fără lideri sau manageri și fiecare tester are propriile responsabilități față de poveștile sale.

Prin urmare, QA-urile individuale efectuează acest test pentru poveștile pe care le dețin.

De ce ar trebui să automatizăm testele de fum?

Această testare este primul test care se face pe o versiune lansată de echipa (e) de dezvoltare. Pe baza rezultatelor acestei testări, se efectuează teste suplimentare (sau compilarea este respinsă).

Cel mai bun mod de a face acest test este să folosiți un instrument de automatizare și să programați suita de fum pentru a rula când se creează o nouă versiune. Poate te gândești de ce ar trebui „Automatizați suita de testare a fumului”?

Să analizăm următorul caz:

Să presupunem că sunteți la o săptămână distanță de eliberare și din totalul de 500 de cazuri de testare, suita dvs. de testare a fumului cuprinde 80-90. Dacă începeți să executați manual toate aceste 80-90 de cazuri de testare, imaginați-vă cât timp veți lua? Cred că 4-5 zile (minim).

Dar dacă utilizați automatizarea și creați scripturi pentru a rula toate aceste 80-90 de cazuri de testare, atunci în mod ideal, acestea vor fi rulate în 2-3 ore și veți avea rezultatele cu dvs. instantaneu. Nu ți-a salvat timpul prețios și ți-a oferit rezultate despre construcție mult mai puțin timp?

Cu 5 ani în urmă, testam o aplicație de proiecție financiară, care lua informații despre salariu, economii etc. și îți proiecta impozitele, economiile, profiturile în funcție de regulile financiare. Odată cu aceasta, am avut personalizare pentru țările care depind de țară și de regulile fiscale utilizate pentru a se modifica (în cod).

Pentru acest proiect, am avut 800 de cazuri de testare și 250 au fost cazuri de testare a fumului. Cu ajutorul seleniului, am putea automatiza și obține cu ușurință rezultatele celor 250 de cazuri de testare în 3-4 ore. Nu numai că ne-a salvat timpul, ci ne-a arătat cât mai curând posibil despre showstoppers.

Prin urmare, dacă nu este imposibil de automatizat, luați ajutorul automatizării pentru aceste teste.

Avantaje și dezavantaje

Să analizăm mai întâi avantajele, deoarece are multe de oferit în comparație cu puținele sale dezavantaje.

Avantaje:

• Ușor de executat.
• Reduce riscul.
• Defectele sunt identificate într-un stadiu incipient.
• Economisește eforturi, timp și bani.
• Se execută rapid dacă este automatizat.
• Riscuri și probleme de integrare minimă.
• Îmbunătățește calitatea generală a sistemului.

Dezavantaje:

• Această testare nu este egală cu sau nu înlocuiește testarea funcțională completă.
• Chiar și după ce testul de fum trece, este posibil să găsiți bug-uri showstopper.
• Acest tip de testare este cel mai potrivit dacă puteți automatiza altfel se petrece mult timp pentru executarea manuală a cazurilor de testare, în special în proiecte de mari dimensiuni cu aproximativ 700-800 de cazuri de testare.

Testarea fumului ar trebui să se facă cu siguranță la fiecare versiune, deoarece evidențiază eșecurile majore și stopurile într-o etapă foarte timpurie. Acest lucru se aplică nu numai noilor funcționalități, ci și integrării modulelor, soluționării problemelor și improvizației. Este un proces foarte simplu de realizat și de a obține rezultatul corect.

Această testare poate fi tratată ca punctul de intrare pentru testarea funcțională completă a funcționalității sau a sistemului (în ansamblu). Dar înainte de asta, echipa QA ar trebui să fie foarte clară cu privire la ce teste trebuie făcute ca teste de fum . Această testare poate minimiza eforturile, economisi timp și îmbunătăți calitatea sistemului. Deține un loc foarte important în sprinturi, deoarece timpul în sprinturi este mai mic.

Această testare se poate face atât manual, cât și cu ajutorul instrumentelor de automatizare. Dar cel mai bun și preferat mod este de a utiliza instrumente de automatizare pentru a economisi timp.

Diferența dintre testarea fumului și a sănătății

De cele mai multe ori ne confundăm între semnificația Testării sănătății și Testarea fumului. În primul rând, aceste două testări sunt foarte „ diferit ”Și efectuate în diferite etape ale unui ciclu de testare.

Urmează o reprezentare schematică a diferențelor lor:

TESTAREA FUMULUI

• Această testare a avut loc în hardware testarea practicii de pornire a unei piese noi de hardware pentru prima dată și considerarea ei un succes dacă nu ia foc și fum. În industria software-ului, această testare este o abordare superficială și largă prin care sunt testate toate domeniile aplicației fără a intra prea adânc.
• Un test de fum este scriptat, fie folosind un set scris de teste, fie un test automat
• Un test de fum este conceput pentru a atinge fiecare parte a aplicației într-un mod superficial. Este superficial și larg.
• Acest test este efectuat pentru a se asigura dacă funcțiile cele mai importante ale unui program funcționează, dar nu se deranjează cu detaliile mai fine. (Cum ar fi verificarea construcției).
• Această testare este o verificare normală a stării de sănătate a construirii unei aplicații înainte de a o testa pentru a testa în profunzime.

TESTAREA SĂNĂTĂȚII

• Un test de sănătate este un test de regresie îngust care se concentrează pe unul sau câteva domenii de funcționalitate. Testarea sănătății este de obicei îngustă și profundă.
• Acest test este de obicei fără script.
• Acest test este utilizat pentru a determina dacă o mică secțiune a aplicației funcționează în continuare după o modificare minoră.
• Această testare este o testare superficială, este efectuată ori de câte ori o testare superficială este suficientă pentru a dovedi că aplicația funcționează conform specificațiilor. Acest nivel de testare este un subset de testare de regresie.
• Aceasta este pentru a verifica dacă sunt sau nu îndeplinite cerințele, verificând toate caracteristicile în primul rând.

Sper că sunteți clar cu privire la diferențele dintre aceste două tipuri de testare software vaste și importante. Simțiți-vă liber să ne împărtășiți gândurile în secțiunea de comentarii de mai jos !!

Lectură recomandată

• Cele mai bune instrumente de testare software 2021 (Instrumente de automatizare a testelor de calitate)
• Diferența dintre Desktop, Client Server Testing și Web Testing
• Testarea funcțională Vs testarea nefuncțională
• Descărcare eBook Descărcare Primer
• Testarea alfa și testarea beta (un ghid complet)
• Ghid de testare a portabilității cu exemple practice
• Tipuri de testare software: diferite tipuri de testare cu detalii
• Testarea funcțională vs. Testarea performanței: ar trebui să se facă simultan?