Ispitivanje dima vs ispitivanje razuma: Razlika s primjerima

smoke testing vs sanity testing

Detaljno istražite razlike između ispitivanja dima i ispitivanja razuma: primjeri:

U ovom uputstvu naučit ćemo što je ispitivanje razuma i testiranje dima u softverskom ispitivanju. Jednostavnim primjerima naučit ćemo i ključne razlike između testiranja zdrave pameti i dima.

Većinu se puta zbunimo između značenja ispitivanja zdrave ispravnosti i ispitivanja dima. Prije svega, ova dva testiranja su način “ drugačiji ”I izvode se tijekom različitih faza ciklusa ispitivanja.

Što ćete naučiti:

• Ispitivanje razuma
• Moje iskustvo
• Ispitivanje ispravnosti protiv regresijskog ispitivanja
• Strategija za testiranje mobilnih aplikacija
• Mjere opreza
• Ispitivanje dima
• Primjeri ispitivanja dima
  • # 1) Ispitivanje prihvatljivosti
  • # 2) Integracijsko testiranje
  • # 3) Testiranje sustava
• Važnost u SCRUM metodologiji
• Test dima u odnosu na ispitivanje prihvatljivosti
• Ciklus ispitivanja dima
• Tko treba izvesti test dima?
• Zašto bismo trebali automatizirati testove dima?
• Prednosti i nedostatci
• Razlika između ispitivanja dima i razuma
  • ISPITIVANJE DIMA
  • ISPITIVANJE SANITETE
• Preporučena literatura

Ispitivanje razuma

Ispitivanje ispravnosti vrši se kada kao QA nemamo dovoljno vremena za pokretanje svih testnih slučajeva, bilo da je to slučaj Ispitivanje funkcionalnosti , UI, OS ili testiranje preglednika.

Stoga bih definirao,

'Ispitivanje ispravnosti ispitivanja kao izvršavanje testa koje se provodi kako bi se dodirnula svaka implementacija i njezin utjecaj, ali ne temeljito ili dubinski, može uključivati ​​funkcionalno, korisničko sučelje, verziju itd. Testiranje, ovisno o provedbi i njezinom učinku.'

Ne padnemo li svi u situaciji kada se moramo odjaviti za dan ili dva, ali verzija za testiranje još uvijek nije objavljena?

najbolji DVD ripper za Windows 7

Ah da, kladim se da ste se i vi morali susresti s ovom situacijom barem jednom u svom iskustvu testiranja softvera. Pa, suočio sam se s tim puno jer su moji projekti bili uglavnom agilni i ponekad su od nas tražili da ih isporučimo isti dan. Ups, kako bih mogao testirati i otpustiti gradnju u roku od nekoliko sati?

Znao sam ponekad poludjeti, jer čak i ako je to bila mala funkcionalnost, implikacije bi mogle biti ogromne. I kao šlag na torti, klijenti ponekad jednostavno odbiju dati dodatno vrijeme. Kako bih mogao izvršiti cijelo testiranje za nekoliko sati, provjeriti svaku funkcionalnost, Bube i otpustiti ga?

Odgovor na sve takve probleme bio je vrlo jednostavan, tj. Ništa drugo osim korištenja Strategija ispitivanja razuma.

Kada provodimo ovo testiranje modula ili funkcionalnosti ili cjelovitog sustava, Test slučajevi za izvršenje odabrani su tako da će dodirnuti sve važne dijelove istog tj. široko, ali plitko ispitivanje.

Ponekad se testiranje vrši nasumično, bez test slučajeva. Ali upamtite, Test zdrave razumnosti treba provoditi samo kad vam ponestaje vremena, nikada to nemojte koristiti za redovna izdanja. Teoretski, ovo je ispitivanje podskup Ispitivanje regresije .

Moje iskustvo

Od svoje 8+ godina karijere u testiranju softvera, 3 godine sam radio u Agilan metodolog y i to je bilo vrijeme kada sam uglavnom koristio test zdravice.

Sva velika izdanja planirana su i izvršena na sustavan način, ali ponekad se tražilo da se mala izdanja dostave što je prije moguće. Nismo dobili puno vremena za dokumentiranje testnih slučajeva, izvršavanje, izradu dokumentacije o programskim pogreškama, regresiju i praćenje cijelog postupka.

Stoga slijede neka od ključnih uputa koje sam slijedio u takvim situacijama:

# 1) Sjednite s upraviteljem i razvojnim timom dok razgovaraju o provedbi jer moraju brzo raditi i stoga ne možemo očekivati ​​da nam objasne odvojeno.

To bi vam također pomoglo da steknete predodžbu o tome što će oni primijeniti, na koje će to područje utjecati itd., Ovo je vrlo važno učiniti, jer ponekad jednostavno ne shvaćamo implikacije i postoji li neka postojeća funkcionalnost bit će ometena (u najgorem slučaju).

#dva) Kako vam nedostaje vremena, dok razvojni tim bude radio na implementaciji, možete primijetiti test slučajeve otprilike u alatima kao što je Evernote itd. Ali pazite da ih negdje napišete kako biste ih mogli kasnije dodati u alat za test slučajeve.

# 3) Pripremite testnu stanicu prema implementaciji, a ako smatrate da postoje crvene zastavice poput nekih specifičnih podataka, ako će testnoj površini trebati vremena (a to je važan test za izdanje), odmah podignite te zastavice i obavijestite svog upravitelja ili PO o zapori na cesti.

Samo zato što klijent želi što prije, ne znači da će se QA objaviti čak i ako je napola testiran.

# 4) Dogovorite se sa svojim timom i upraviteljem da ćete zbog vremenskog ograničenja programske greške priopćavati samo razvojnom timu, a formalni postupak dodavanja, označavanje programskih pogrešaka za različite faze u alatu za praćenje bugova obavit će se kasnije kako biste uštedjeli vrijeme .

# 5) Kada razvojni tim testira na njihovom kraju, pokušajte se upariti s njima (naziva se uparivanje dev-QA) i napravite osnovni krug na samom njihovom postavljanju, što će pomoći izbjegavanju gradnje ako i osnovna implementacija ne uspije. .

# 6) Sad kad imate verziju, prvo testirajte poslovna pravila i sve slučajeve upotrebe. Testove poput provjere valjanosti polja, navigacije itd. Možete zadržati za kasnije.

# 7) Kakve god greške pronašli, zabilježite sve i pokušajte ih zajedno prijaviti programerima, a ne pojedinačno, jer će im biti lako raditi gomilu.

# 8) Ako imate zahtjev za cjelokupnim Ispitivanje performansi ili testiranje naprezanja ili opterećenja, a zatim provjerite imate li odgovarajući okvir za automatizaciju za isti. Budući da je gotovo nemoguće ručno ih testirati zdravim testom.

# 9) Ovo je najvažniji dio i zapravo posljednji korak vaše strategije provjere razuma - „Kada izrađujete e-poruku o izdanju ili dokument, spomenite sve probne slučajeve koje ste izvršili, programske pogreške pronađene markerom statusa i ako je nešto ostalo neprovjereno spomenuti s razlozima ' Pokušajte napisati svježu priču o svom testiranju koja će svima prenijeti ono što je testirano, provjereno, a što nije.

To sam religiozno slijedio dok sam koristio ovo testiranje.

Dopustite mi da podijelim svoje iskustvo:

# 1) Radili smo na web mjestu i ono se koristilo za iskakanje oglasa na temelju ključnih riječi. Oglašivači su davali ponude za određene ključne riječi kojima je zaslon dizajniran za iste. Zadana vrijednost ponude nekad je bila prikazana kao 0,25 američkih dolara, što bi ponuditelj mogao čak i promijeniti.

Bilo je još jedno mjesto na kojem se prikazivala ova zadana ponuda, a mogla bi se promijeniti i na drugu vrijednost. Klijent je došao sa zahtjevom za promjenu zadane vrijednosti s 0,25 na 0,5 dolara, ali spomenuo je samo očigledan zaslon.

Tijekom naše diskusije o mozganju, zaboravili smo (?) Na ovaj drugi zaslon jer nije korišten puno u tu svrhu. No dok sam testirao kada sam pokrenuo osnovni slučaj ponude od 0,5 dolara i provjerio kraj do kraja, otkrio sam da cronjob za isti nije uspio jer je na jednom mjestu pronašao 0,25 dolara.

To sam prijavio svom timu, a mi smo unijeli promjenu i uspješno je dostavili istog dana.

#dva) U okviru istog projekta (gore spomenutog) zatraženo je da dodamo malo tekstualno polje za bilješke / komentare za nadmetanje. Bila je to vrlo jednostavna implementacija i obvezali smo se da ćemo je isporučiti isti dan.

Stoga sam, kao što je gore spomenuto, testirao sva poslovna pravila i slučajeve upotrebe oko njih, a kada sam proveo provjeru valjanosti, otkrio sam da se kada sam upisao kombinaciju posebnih znakova, stranica srušila.

Razmislili smo i zaključili da stvarni ponuditelji ni u kojem slučaju neće koristiti takve kombinacije. Stoga smo ga objavili s dobro izrađenom bilješkom o tom pitanju. Klijent je to prihvatio kao grešku, ali se složio s nama da ćemo je kasnije primijeniti jer je to ozbiljna greška, ali ne i prethodna.

# 3) Nedavno sam radio na projektu mobilne aplikacije i imali smo zahtjev da ažuriramo vrijeme isporuke prikazano u aplikaciji prema vremenskoj zoni. Nije se trebalo testirati samo u aplikaciji već i za web uslugu.

Dok je razvojni tim radio na implementaciji, stvorio sam skripte za automatizaciju za testiranje web usluga i DB skripte za promjenu vremenske zone stavke isporuke. To je spasilo moje napore i mogli bismo postići bolje rezultate u kratkom trajanju.

Ispitivanje ispravnosti protiv regresijskog ispitivanja

Slijedi nekoliko razlika između njih dvoje:

Strategija za testiranje mobilnih aplikacija

Sigurno se pitate zašto ovdje posebno spominjem mobilne aplikacije?

Razlog je taj što se inačice OS-a i preglednika za web ili desktop aplikacije ne razlikuju puno, a posebno su veličine zaslona standardne. Ali s mobilnim aplikacijama, veličina zaslona, ​​mobilna mreža, verzije OS-a itd. Utječu na stabilnost, izgled i ukratko na uspjeh vaše mobilne aplikacije.

Stoga formulacija strategije postaje kritična kada ovo testiranje provodite na mobilnoj aplikaciji, jer jedan neuspjeh može vas dovesti u velike probleme. Testiranje se mora obaviti pametno i s oprezom.

Slijedi nekoliko uputa koje će vam pomoći da ovo testiranje uspješno izvedete na 'mobilnoj aplikaciji':

# 1) Prije svega, analizirajte utjecaj verzije OS-a na implementaciju sa svojim timom.

Pokušajte pronaći odgovore na pitanja poput, hoće li se ponašanje razlikovati u različitim verzijama? Hoće li implementacija raditi na najnižoj podržanoj verziji ili ne? Hoće li biti problema s izvedbom za implementaciju verzija? Postoji li neka specifična značajka OS-a koja bi mogla utjecati na ponašanje implementacije? itd.

#dva) Na gornjoj bilješci, analizirajte i modele telefona, tj. Postoje li neke značajke telefona koje će utjecati na implementaciju? Je li provedba promjene ponašanja pomoću GPS-a? Mijenja li se ponašanje implementacije s kamerom telefona? itd. Ako utvrdite da nema utjecaja, izbjegavajte testiranje na različitim modelima telefona.

# 3) Ako ne postoje promjene korisničkog sučelja za implementaciju, preporučio bih da testiranje korisničkog sučelja ostane na najmanjem prioritetu, možete obavijestiti tim (ako želite) da korisničko sučelje neće biti testirano.

# 4) Kako biste uštedjeli vrijeme, izbjegavajte testiranje na dobrim mrežama jer je očito da će implementacija funkcionirati kako se očekuje na jakoj mreži. Preporučio bih da započnete s testiranjem na 4G ili 3G mreži.

# 5) Ovo bi se ispitivanje trebalo obaviti za manje vremena, ali pobrinite se da napravite barem jedan terenski test, osim ako se radi o pukoj promjeni korisničkog sučelja.

# 6) Ako morate testirati matricu različitih OS-a i njihove verzije, predlažem da to učinite na pametan način. Na primjer, za testiranje odaberite parove najniže, srednje i najnovije verzije OS-a. U izdanju možete spomenuti da nije testirana svaka kombinacija.

# 7) Na sličnoj liniji, za test razumnosti implementacije korisničkog sučelja, koristite male, srednje i velike veličine zaslona kako biste uštedjeli vrijeme. Također možete koristiti simulator i emulator.

Mjere opreza

Ispitivanje ispravnosti vrši se kad vam nedostaje vremena, pa vam nije moguće pokrenuti svaki testni slučaj, a što je najvažnije nemate dovoljno vremena da isplanirate svoje testiranje. Da bi se izbjegle igre krivnje, bolje je poduzeti mjere predostrožnosti.

U takvim slučajevima nedostatak pisane komunikacije, ispitne dokumentacije i propuštanja vrlo su česti.

Kako biste bili sigurni da nećete postati žrtvom ovoga, osigurajte sljedeće:

• Nikada ne prihvaćajte verziju za testiranje dok vam se ne da pismeni zahtjev koji klijent dijeli. Dogodi se da klijenti promjene ili nove implementacije komuniciraju usmeno ili u chatu ili jednostavnom linku u e-poruci i očekuju da to tretiramo kao zahtjev. Prisilite svog klijenta da pruži neke osnovne točke funkcionalnosti i kriterije prihvaćanja.
• Uvijek napravite grube bilješke o svojim test slučajevima i greškama ako nemate dovoljno vremena da ih uredno napišete. Nikada ih nemojte ostavljati bez dokumenata. Ako postoji malo vremena, podijelite ga sa svojim vođom ili timom, tako da ako nešto nedostaje mogu to lako istaknuti.
• Ako vam i vašem timu nedostaje vremena, pobrinite se da su pogreške označene u odgovarajućem stanju u e-poruci? Kompletnom popisu programskih pogrešaka možete poslati tim i natjerati razvojne programere da ih prikladno označe. Uvijek držite loptu na terenu drugog.
• Ako imate Okvir za automatizaciju spremni, upotrijebite to i izbjegavajte raditi Ručno ispitivanje , na taj način u manje vremena možete pokriti više.
• Izbjegavajte scenarij 'puštanja za 1 sat', osim ako niste 100% sigurni da ćete moći isporučiti.
• I posljednje, ali ne najmanje važno, kao što je gore spomenuto, izradite detaljnu e-poštu s informacijama o onome što je testirano, što je izostavljeno, razlozima, rizicima, koje su pogreške riješene, što je 'Kasnije' itd.

Kao osiguranje kvalitete trebali biste prosuđivati ​​koji je najvažniji dio implementacije koji treba testirati i koji su dijelovi koji se mogu izostaviti ili osnovno testirati.

Čak i u kratkom vremenu planirajte strategiju o tome kako želite i moći ćete postići najbolje u datom vremenskom okviru.

Ispitivanje dima

Testiranje dima nije iscrpno testiranje, ali to je skupina testova koji se izvršavaju kako bi se provjerilo rade li osnovne funkcije te određene građe u redu kako se očekivalo ili ne. Ovo je i uvijek bi trebao biti prvi test koji se provodi na bilo kojoj 'novoj' gradnji.

Kada razvojni tim pusti gradnju QA-u na testiranje, očito nije moguće testirati cjelokupnu gradnju i odmah provjeriti ima li u bilo kojoj od implementacija grešaka ili je neispravna radna funkcionalnost.

U svjetlu ovoga, kako će QA osigurati da osnovne funkcionalnosti rade u redu?

Odgovor na to bit će izvođenje a Ispitivanje dima .

Jednom kada su testovi označeni kao testovi dima (u paketu testova), QA tek tada prihvaća izgradnju za dubinsko testiranje i / ili regresiju. Ako bilo koje od ispitivanja dima ne uspije, gradnja se odbija, a razvojni tim treba riješiti problem i pustiti novu gradnju na testiranje.

Teoretski, test dima definiran je kao ispitivanje na površini kako bi se potvrdilo da je izrada koju razvojni tim pruža QA timu spremna za daljnje ispitivanje. Ovo testiranje također provodi razvojni tim prije nego što izradu prepusti QA timu.

Ovo se ispitivanje obično koristi u integracijskom testiranju, testiranju sustava i ispitivanju razine prihvatljivosti. Nikada to nemojte tretirati kao zamjenu za stvarno testiranje od kraja do kraja . Sadrži i pozitivne i negativne testove, ovisno o izvedbi gradnje.

Primjeri ispitivanja dima

Ovo se ispitivanje obično koristi za integraciju, prihvaćanje i Ispitivanje sustava .

U svojoj QA karijeri uvijek sam prihvaćao građu tek nakon što sam obavio test dima. Dakle, shvatimo što je test dima iz perspektive sva ova tri ispitivanja, s nekoliko primjera.

# 1) Ispitivanje prihvatljivosti

Kad god se neka konstrukcija pusti u QA, test dima u obliku Ispitivanje prihvaćanja treba obaviti.

U ovom je testu prvi i najvažniji test dima provjera osnovne očekivane funkcionalnosti implementacije. Ovako, trebali biste provjeriti sve implementacije za tu određenu izgradnju.

Uzmimo sljedeće primjere kao implementacije izvedene u gradnji da bismo razumjeli testove dima za one:

• Implementirana je funkcionalnost prijave kako bi se registriranim upravljačkim programima omogućila uspješna prijava.
• Implementirana je funkcija nadzorne ploče kako bi se prikazale rute koje vozač treba izvršiti danas.
• Implementirana je funkcionalnost prikazivanja odgovarajuće poruke ako za određeni dan ne postoje rute.

U gornjoj verziji, na razini prihvaćanja, test dima značit će provjeriti rade li osnovne tri izvedbe u redu. Ako je bilo koja od ove tri pokvarena, QA bi trebao odbiti izradu.

# 2) Integracijsko testiranje

Ovo se ispitivanje obično vrši kada se pojedinačni moduli implementiraju i testiraju. U Ispitivanje integracije ovo se ispitivanje provodi kako bi se osiguralo da sve osnovne integracije i end-to-end funkcionalnosti rade u redu kako se očekivalo.

To može biti integracija dva modula ili svih modula zajedno, stoga će složenost testa dima varirati ovisno o razini integracije.

Razmotrimo sljedeće primjere implementacije integracije za ovo testiranje:

• Provedena integracija modula rute i stajališta.
• Implementirana je integracija ažuriranja statusa dolaska i odražava se na zaslonu zaustavljanja.
• Provedena integracija kompletnih modula za preuzimanje do isporuke.

U ovoj će verziji test dima ne samo provjeriti ove tri osnovne implementacije, već će za treću implementaciju nekoliko slučajeva provjeriti i potpunu integraciju. Puno pomaže otkriti probleme koji se uvode u integraciju i one koje razvojni tim nije prošao.

# 3) Testiranje sustava

Kao što i samo ime sugerira, ispitivanje dima na razini sustava uključuje testove za najvažnije i najčešće korištene tijekove rada sustava. To se radi tek nakon što kompletan sustav bude spreman i testiran, a ovo testiranje na razini sustava može se nazvati i testiranjem dima prije regresijskog ispitivanja.

što je mrežni sigurnosni kod

Prije početka regresije cjelokupnog sustava ispituju se osnovne značajke s kraja na kraj kao dio testa na dim. Paket za testiranje dima za cjelokupni sustav sastoji se od testnih slučajeva od kraja do kraja koje će krajnji korisnici vrlo često koristiti.

To se obično radi uz pomoć alata za automatizaciju.

Važnost u SCRUM metodologiji

Danas projekti gotovo ne slijede Waterfall metodologiju u provedbi projekata, uglavnom svi projekti slijede Agile i OLOŠ samo. U usporedbi s tradicionalnom metodom slapa, testiranje dima visoko cijeni SCRUM i Agile.

Radio sam 4 godine u SCRUM-u . A kao što znamo da su u SCRUM-u sprintovi kraćeg trajanja, pa je stoga izuzetno važno obaviti ovo testiranje, tako da se neuspjele gradnje mogu odmah prijaviti razvojnom timu i popraviti.

Slijede neke oduzeti o važnosti ovog testiranja u SCRUM-u:

• Izvan sprinta u dva tjedna, poluvrijeme se dodjeljuje QA-u, ali ponekad se izrade QA odgađaju.
• U sprintu je za momčad najbolje da se problemi prijave u ranoj fazi.
• Svaka priča ima skup kriterija prihvatljivosti, stoga je testiranje prva 2-3 kriterija prihvaćanja jednako testiranju te funkcionalnosti na dim. Kupci odbijaju isporuku ako jedan kriterij ne uspije.
• Zamislite samo što će se dogoditi ako vam je razvojni tim isporučio građu u roku od 2 dana, a preostala su samo 3 dana za demonstraciju i naiđete na osnovni kvar funkcionalnosti.
• U prosjeku, sprint ima priče u rasponu od 5 do 10, stoga je prilikom izrade važno osigurati da se svaka priča implementira prema očekivanjima prije prihvaćanja izrade u testiranje.
• Kada se cjelokupni sustav treba testirati i regresirati, aktivnost je posvećena sprintu. Dvanaest dana možda malo manje za testiranje cijelog sustava, stoga je vrlo važno provjeriti najosnovnije funkcionalnosti prije početka regresije.

Test dima u odnosu na ispitivanje prihvatljivosti

Ispitivanje dima izravno je povezano s ispitivanjem prihvatljivosti zgrade (BAT).

U BAT-u radimo isto testiranje - kako bismo provjerili nije li izrada zakazala i funkcionira li sustav u redu ili ne. Ponekad se dogodi da se prilikom izrade neke građe uvode neki problemi, a kada se isporuči, izrada ne funkcionira za QA.

Rekao bih da je BAT dio provjere dima, jer ako sustav zakaže, kako možete kao QA prihvatiti gradnju za testiranje? Ne samo funkcionalnosti, sam sustav mora raditi prije nego što QA nastavi s dubinskim ispitivanjem.

Ciklus ispitivanja dima

Sljedeći dijagram toka objašnjava ciklus ispitivanja dima.

Jednom kada je gradnja raspoređena na QA, slijedi osnovni ciklus da, ako test dima prođe, QA tim prihvati gradnju na daljnje ispitivanje, ali ako ne uspije, gradnja se odbija dok se ne riješe prijavljeni problemi.

Ispitni ciklus

Tko treba izvesti test dima?

Nije cijeli tim uključen u ovu vrstu testiranja kako bi se izbjeglo gubljenje vremena svih QA-a.

Testiranje dima idealno provodi QA voditelj koji na temelju rezultata odlučuje hoće li predati izradu timu na daljnje testiranje ili će je odbiti. Ili u nedostatku vodstva, sami QA-i također mogu izvršiti ovo testiranje.

Ponekad, kada je projekt velikog opsega, skupina osiguranja kvalitete također može izvršiti ovo testiranje kako bi provjerila ima li prodavača. Ali to nije slučaj u slučaju SCRUM-a, jer je SCRUM ravna struktura bez potencijalnih klijenata ili menadžera, a svaki ispitivač ima svoje odgovornosti prema svojim pričama.

Stoga pojedinačni QA-i provode ovo testiranje za priče koje posjeduju.

Zašto bismo trebali automatizirati testove dima?

Ovo je testiranje prvo testiranje koje je izvedeno na izradi koju je izdao razvojni tim. Na temelju rezultata ovog ispitivanja, provodi se daljnje testiranje (ili je gradnja odbijena).

Najbolji način za ovo testiranje je korištenje alata za automatizaciju i planiranje izvođenja dimnog paketa kada se kreira nova gradnja. Možda razmišljate zašto bih 'Automatizirati paket za testiranje dima'?

Pogledajmo sljedeći slučaj:

Recimo da vas dijeli tjedan dana od vašeg izdanja, a od ukupno 500 testnih slučajeva, vaš paket za testiranje dima sadrži 80-90. Ako započnete ručno izvršavati sve ove 80-90 ispitne slučajeve, zamislite koliko će vam vremena trebati? Mislim 4-5 dana (minimalno).

Ali ako koristite automatizaciju i kreirate skripte za pokretanje svih ovih 80-90 testnih slučajeva, u idealnom slučaju, oni će se pokrenuti za 2-3 sata i rezultate ćete odmah imati sa sobom. Nije li vam uštedjelo dragocjeno vrijeme i dalo vam rezultate o ugrađivanju puno manje vremena?

Prije pet godina testirao sam aplikaciju za financijsku projekciju koja je uzimala podatke o vašoj plaći, štednji itd. I projicirala vaše poreze, štednju i dobit, ovisno o financijskim pravilima. Uz to smo imali prilagodbu za zemlje koje ovise o zemlji i njezinim poreznim pravilima koji su se mijenjali (u kodu).

Za ovaj sam projekt imao 800 slučajeva, a 250 slučajeva za dim. Korištenjem selena mogli bismo lako automatizirati i dobiti rezultate tih 250 test slučajeva u 3-4 sata. To nam je ne samo uštedjelo vrijeme već nam je što prije pokazalo što se tiče prodavača.

Stoga, osim ako je nemoguće automatizirati, uzmite pomoć automatizacije za ovo ispitivanje.

Prednosti i nedostatci

Pogledajmo prvo prednosti jer on nudi mnogo toga u usporedbi s nekoliko nedostataka.

Prednosti:

• Jednostavno za izvođenje.
• Smanjuje rizik.
• Defekti se prepoznaju u vrlo ranoj fazi.
• Štedi napore, vrijeme i novac.
• Radi brzo ako je automatizirano.
• Najmanje integracijskih rizika i problema.
• Poboljšava ukupnu kvalitetu sustava.

Mane:

• Ovo ispitivanje nije jednako niti je zamjena za cjelovito funkcionalno ispitivanje.
• Čak i nakon što test dima prođe, možda ćete pronaći bugove showstoppera.
• Ova vrsta testiranja je najprikladnija ako možete automatizirati, jer se puno vremena troši na ručno izvršavanje testnih slučajeva, posebno u velikim projektima koji imaju oko 700-800 testnih slučajeva.

Testiranje dima svakako bi trebalo provesti na svakoj gradnji, jer ukazuje na velike kvarove i izložbene prostore u vrlo ranoj fazi. To se odnosi ne samo na nove funkcionalnosti, već i na integraciju modula, rješavanje problema i improvizaciju. Izvođenje i dobivanje točnog rezultata vrlo je jednostavan postupak.

Ovo testiranje može se tretirati kao ulazna točka za cjelovito funkcionalno testiranje funkcionalnosti ili sustava (kao cjeline). Ali prije toga, QA tim bi trebao biti vrlo jasan o tome koje testove treba provesti kao testove dima . Ovo testiranje može umanjiti napore, uštedjeti vrijeme i poboljšati kvalitetu sustava. Drži vrlo važno mjesto u sprintima jer je vrijeme u sprintima manje.

Ovo se ispitivanje može obaviti ručno i uz pomoć alata za automatizaciju. Ali najbolji i preferirani način je korištenje alata za automatizaciju kako biste uštedjeli vrijeme.

Razlika između ispitivanja dima i razuma

Većinu se puta zbunimo između značenja ispitivanja zdrave ispravnosti i ispitivanja dima. Prije svega, ova dva testiranja su način “ drugačiji 'I izvodi se tijekom različitih faza ciklusa ispitivanja.

Slijedi shematski prikaz njihovih razlika:

ISPITIVANJE DIMA

• Ovo ispitivanje je nastalo u hardver testiranje prakse prvog uključivanja novog hardverskog dijela i smatrajući ga uspjehom ako se ne zapali i ne zapuši. U softverskoj industriji ovo je testiranje plitki i širok pristup kojim se ispituju sva područja aplikacije bez predubokog uvođenja.
• Test dima se skriptira, bilo pomoću pisanog niza testova ili automatiziranog testa
• Test dima dizajniran je da letimično dodirne svaki dio aplikacije. Plitko je i široko.
• Ovo se ispitivanje provodi kako bi se osiguralo rade li najvažnije funkcije programa, ali se ne zamaraju finim detaljima. (Kao što je provjera verzije).
• Ovo je testiranje uobičajena zdravstvena provjera za izradu aplikacije prije nego što je položite na dubinsko testiranje.

ISPITIVANJE SANITETE

• Test zdrave ispravnosti je uski regresijski test koji se usredotočuje na jedno ili nekoliko područja funkcionalnosti. Ispitivanje razumnosti obično je usko i duboko.
• Ovaj test obično nije skriptiran.
• Ovim se testom utvrđuje da mali dio aplikacije i dalje radi nakon manje promjene.
• Ovo testiranje je površno testiranje, provodi se kad god je letimično ispitivanje dovoljno da se dokaže da aplikacija funkcionira prema specifikacijama. Ova razina testiranja podskup je regresijskog ispitivanja.
• Ovim se želi provjeriti ispunjavaju li se zahtjevi ili ne, provjeravajući sve značajke po širini.

Nadam se da su vam jasne razlike između ove dvije goleme i važne vrste testiranja softvera. Slobodno podijelite svoje misli u odjeljku za komentare ispod !!

Preporučena literatura

• Najbolji alati za testiranje softvera 2021. (Alati za automatizaciju ispitivanja kvalitete)
• Razlika između testiranja radne površine, klijentskog poslužitelja i web testiranja
• Funkcionalno ispitivanje vs nefunkcionalno testiranje
• Preuzimanje e-knjige za testiranje primera
• Alfa testiranje i beta testiranje (cjelovit vodič)
• Vodič za ispitivanje prenosivosti s praktičnim primjerima
• Vrste testiranja softvera: različite vrste ispitivanja s pojedinostima
• Funkcionalno testiranje protiv testiranja izvedbe: treba li to istodobno?