smoke testing vs sanity testing
Utforsk forskjellene mellom røykprøving og sunnhetstesting i detalj med eksempler:
I denne opplæringen vil vi lære hva som er Sanity Testing og Smoke Testing i Software Testing. Vi vil også lære nøkkelforskjellene mellom sunnhet og røykprøving med enkle eksempler.
De fleste ganger blir vi forvirret mellom betydningen av Sanity Testing og Smoke Testing. Først og fremst er disse to testene måte “ annerledes ”Og utføres i forskjellige stadier av en testsyklus.
Hva du vil lære:
- Sanity Testing
- Min erfaring
- Sanity Testing Vs Regression Testing
- Strategi for mobilapptesting
- Forebyggende tiltak
- Røykprøving
- Eksempler på røykprøving
- Viktighet i SCRUM-metodikk
- Smoke Test Vs Build Acceptance Testing
- Røykprøvesyklus
- Hvem skal utføre røykprøven?
- Hvorfor skal vi automatisere røykprøver?
- Fordeler og ulemper
- Forskjellen mellom røyk og sunnhetsprøving
- Anbefalt lesing
Sanity Testing
Sanity Testing gjøres når vi som en kvalitetssikring ikke har tilstrekkelig tid til å kjøre alle testsakene, det være seg Funksjonell testing , UI, OS eller nettlesertesting.
Derfor vil jeg definere,
'Sanity Testing som en testutførelse som gjøres for å berøre hver implementering og dens innvirkning, men ikke grundig eller grundig. Den kan omfatte funksjonell, UI, versjon osv. Testing, avhengig av implementeringen og dens innvirkning.'
Får vi ikke alle en situasjon når vi må logge av om en dag eller to, men bygningen for testing fremdeles ikke frigjøres?
hvordan åpne dat-fil i pdf
Ah ja, jeg vedder på at du også må ha møtt denne situasjonen minst en gang i programvaretestopplevelsen. Vel, jeg møtte det mye fordi prosjektet (e) mine var mest smidige og til tider ble vi bedt om å levere det samme dag. Ups, hvordan kunne jeg teste og frigjøre bygningen i løpet av noen timer?
Jeg pleide å være nøtt til tider, for selv om det var en liten funksjonalitet, kunne implikasjonen være enorm. Og som en prikken over i-en, nekter klienter bare å gi ekstra tid. Hvordan kunne jeg fullføre hele testingen på få timer, verifisere alle funksjoner, Feil og slippe den?
Svaret på alle slike problemer var veldig enkelt, dvs. ingenting annet enn å bruke Sanity Testing strategi.
Når vi gjør denne testen for en modul eller funksjonalitet eller et komplett system, blir Test saker for henrettelse er valgt slik at de vil berøre alle viktige biter og stykker av det samme, dvs. bred men grunne tester.
Noen ganger blir testingen til og med utført tilfeldig uten testtilfeller. Men husk, Fornuftstest bør bare gjøres når du har kort tid, aldri bruk denne til dine vanlige utgivelser. Teoretisk sett er denne testen en delmengde av Regresjonstesting .
Min erfaring
I løpet av 3 år jobbet jeg i programvaretesting i over 8 år Agile metodolog y og det var tiden da jeg for det meste brukte en sunnhetsprøve.
Alle de store utgivelsene ble planlagt og utført på en systematisk måte, men til tider ble små utgivelser bedt om å bli levert så snart som mulig. Vi fikk ikke mye tid til å dokumentere testsakene, utføre, gjøre feildokumentasjonen, gjøre regresjonen og følge hele prosessen.
Følgende er noen av de viktigste tipsene jeg pleide å følge under slike situasjoner:
#1) Sitt med lederen og utviklerteamet når de diskuterer implementeringen fordi de må jobbe raskt, og derfor kan vi ikke forvente at de skal forklare oss hver for seg.
Dette vil også hjelpe deg med å få en ide om hva de skal implementere, hvilket område vil det påvirke osv. Dette er en veldig viktig ting å gjøre fordi vi til tider rett og slett ikke er klar over implikasjonene og om noen eksisterende funksjonalitet kommer til å bli hemmet (i verste fall).
#to) Når du har lite tid, kan du, når utviklingsgruppen jobber med implementeringen, notere testtilfellene omtrent i verktøy som Evernote osv. Men sørg for at du skriver dem et sted slik at du kan legge dem senere til testcase-verktøyet.
# 3) Hold testbedet klart i henhold til implementeringen, og hvis du føler at det er noen røde flagg, som noe spesifikk dataoppretting hvis en testbed vil ta tid (og det er en viktig test for utgivelsen), så løft flaggene umiddelbart og informer lederen din eller PO om veisperringen.
Bare fordi klienten ønsker så raskt som mulig, betyr det ikke at en kvalitetssikring vil slippe selv om den er halvtestet.
# 4) Gjør en avtale med teamet ditt og lederen om at på grunn av tidsklemme vil du bare kommunisere feilene til utviklingsteamet, og den formelle prosessen med å legge til, og markere feilene for forskjellige stadier i feilsporingsverktøyet vil bli gjort senere for å spare tid .
# 5) Når utviklingsteamet tester på slutten, kan du prøve å parre med dem (kalt dev-QA-parring) og gjøre en grunnleggende runde på selve oppsettet, dette vil bidra til å unngå frem og tilbake i bygningen hvis den grunnleggende implementeringen mislykkes. .
# 6) Nå som du har bygget, tester du forretningsreglene og alle brukssakene først. Du kan beholde tester som validering av et felt, navigering osv. Til senere.
# 7) Uansett hvilke feil du finner, noter dem alle og prøv å rapportere dem sammen til utviklerne i stedet for å rapportere hver for seg, fordi det vil være enkelt for dem å jobbe med en haug.
# 8) Hvis du har et krav til helheten Ytelsestesting eller stress- eller lasttesting, og sørg for at du har et riktig automatiseringsrammeverk for det samme. Fordi det er nesten umulig å teste disse manuelt med en fornuftstest.
# 9) Dette er den viktigste delen, og faktisk det siste trinnet i din tilregnelighetsteststrategi - “Når du utarbeider utgivelses-e-postmeldingen eller dokumentet, nevn alle testtilfellene du utførte, feilene ble funnet med en statusmarkør og hvis noe var igjen uprøvd nevn det med årsakene ' Prøv å skrive en skarp historie om testingen som vil formidle alle om hva som er testet, verifisert og hva som ikke har vært.
Jeg fulgte dette religiøst da jeg brukte denne testen.
La meg dele min egen erfaring:
#1) Vi jobbet på et nettsted, og det pleide å popup-annonser basert på nøkkelordene. Annonsørene pleide å legge inn bud på bestemte søkeord som hadde en skjerm designet for det samme. Standardbudverdien ble tidligere vist som $ 0,25, som budgiveren til og med kunne endre.
Det var ett sted til der dette standardbudet pleide å vises, og det kunne også endres til en annen verdi. Klienten kom med en forespørsel om å endre standardverdien fra $ 0,25 til $ 0,5, men han nevnte bare den åpenbare skjermen.
Under brainstorming-diskusjonen glemte vi (?) Denne andre skjermen fordi den ikke ble brukt mye til det formålet. Men mens jeg testet da jeg kjørte det grunnleggende tilfellet av at budet var $ 0,5 og sjekket fra slutt til slutt, fant jeg ut at cronjobben for det samme sviktet fordi det på et sted fant 0,25 dollar.
Jeg rapporterte dette til teamet mitt, og vi gjorde endringen og leverte den med hell samme dag.
#to) Under det samme prosjektet (nevnt ovenfor) ble vi bedt om å legge til et lite tekstfelt for notater / kommentarer for budgivning. Det var en veldig enkel implementering, og vi forpliktet oss til å levere den samme dag.
Derfor, som nevnt ovenfor, testet jeg alle forretningsreglene og bruk saker rundt det, og da jeg gjorde noen valideringstester, fant jeg ut at når jeg skrev inn en kombinasjon av spesialtegn som, siden krasjet.
Vi tenkte over det og fant ut at de faktiske budgiverne i alle fall ikke vil bruke slike kombinasjoner. Derfor ga vi det ut med et godt utarbeidet notat om problemet. Klienten aksepterte det som en feil, men ble enige med oss om å implementere det senere fordi det var en alvorlig feil, men ikke en tidligere feil.
# 3) Nylig jobbet jeg med et mobilapp-prosjekt, og vi hadde et krav om å oppdatere leveringstidspunktet som vises i appen i henhold til tidssonen. Det skulle ikke bare testes i appen, men også for nettjenesten.
Mens utviklingsteamet arbeidet med implementeringen, opprettet jeg automatiseringsskriptene for testing av webtjenesten og DB-skriptene for å endre tidssonen til leveringsvaren. Dette reddet innsatsen min, og vi kunne oppnå bedre resultater innen kort varighet.
Sanity Testing Vs Regression Testing
Nedenfor er noen forskjeller mellom de to:
S. Nei | Regresjonstesting | Sanity Testing |
---|---|---|
7 | Denne testen er til tider planlagt for uker eller til og med måned (er). | Dette strekker seg stort sett over 2-3 dager maks. |
1 | Regresjonstesting er gjort for å bekrefte at hele systemet og feilrettinger fungerer bra. | Sanity testing utføres tilfeldig for å verifisere at hver funksjonalitet fungerer som forventet. |
to | Hver minste del regreserer i denne testen. | Dette er ikke en planlagt testing, og gjøres bare når det er en tidsklemme. |
3 | Det er en godt forseggjort og planlagt testing. | Dette er ikke en planlagt testing, og gjøres bare når det er en tidsklemme. |
4 | En passende utformet pakke med testtilfeller blir opprettet for denne testingen. | Det er ikke alltid det er mulig å lage testsaker; et grovt sett med testtilfeller opprettes vanligvis. |
5 | Dette inkluderer grundig verifisering av funksjonalitet, brukergrensesnitt, ytelse, nettleser / OS-testing osv. Dvs. at alle aspekter av systemet regres. | Dette inkluderer hovedsakelig verifisering av forretningsregler, funksjonalitet. |
6 | Dette er en bred og dyp testing. | Dette er en bred og grunne testing. |
Strategi for mobilapptesting
Du lurer på hvorfor jeg nevner spesifikt om mobilapper her?
Årsaken er at OS- og nettleserversjon for nett- eller stasjonære apper ikke varierer mye, og spesielt skjermstørrelsene er standard. Men med mobilapper påvirker skjermstørrelsen, mobilnettverket, OS-versjonene osv. Stabiliteten, utseendet og kort sagt suksessen til mobilappen din.
Derfor blir en strategiformulering kritisk når du utfører denne testen på en mobilapp, fordi en feil kan gi deg store problemer. Testingen må gjøres smart og med forsiktighet også.
Følgende er noen tips som hjelper deg med å utføre denne testen med suksess på en 'mobilapp':
#1) Først av alt, analyser innvirkningen av OS-versjonen på implementeringen sammen med teamet ditt.
Prøv å finne svar på spørsmål som, vil oppførselen være forskjellig på tvers av versjoner? Vil implementeringen fungere på den laveste støttede versjonen eller ikke? Vil det være ytelsesproblemer for implementering av versjoner? Er det noen spesifikke funksjoner i operativsystemet som kan påvirke oppførselen til implementeringen? etc.
#to) På ovennevnte analyse, analyser for telefonmodellene også, dvs. er det noen funksjoner i telefonen som vil påvirke implementeringen? Er implementeringen av atferdsendring med GPS? Endres implementeringsatferden med telefonens kamera? osv. Hvis du finner ut at det ikke er noen innvirkning, kan du unngå å teste på forskjellige telefonmodeller.
# 3) Med mindre det er noen UI-endringer for implementeringen, vil jeg anbefale å holde UI-testing på minst mulig prioritet, kan du informere teamet (hvis du vil) om at UI ikke blir testet.
# 4) For å spare tid, unngå testing på gode nettverk fordi det er åpenbart at implementeringen kommer til å fungere som forventet på et sterkt nettverk. Jeg vil anbefale å starte med testing på et 4G- eller 3G-nettverk.
# 5) Denne testingen skal utføres på kortere tid, men sørg for at du gjør minst en feltprøve med mindre det bare er en endring av brukergrensesnittet.
# 6) Hvis du må teste for en matrise med forskjellige operativsystemer og deres versjon, vil jeg foreslå at du gjør det på en smart måte. Velg for eksempel de laveste, mellomstore og de nyeste OS-versjonsparene for testing. Du kan nevne i utgivelsesdokumentet at ikke alle kombinasjoner er testet.
# 7) Bruk en liten, middels og stor skjermstørrelse for å spare tid for UI-implementering fornuftstest. Du kan også bruke en simulator og emulator.
Forebyggende tiltak
Sanity Testing utføres når du har kort tid, og det er derfor ikke mulig for deg å kjøre hver eneste testtilfelle, og viktigst av alt får du ikke nok tid til å planlegge testingen. For å unngå skyldspillene, er det bedre å ta forholdsregler.
I slike tilfeller er mangel på skriftlig kommunikasjon, testdokumentasjon og glipp ganske vanlig.
For å sikre at du ikke blir offer for dette, må du sørge for at:
- Aldri godta et build for testing før du ikke får et skriftlig krav som deles av klienten. Det hender at klienter kommuniserer endringer eller nye implementeringer muntlig eller i chat eller en enkel 1 liner i en e-post og forventer at vi behandler det som et krav. Tving klienten til å gi noen grunnleggende funksjonalitetspoeng og akseptkriterier.
- Skriv alltid tøffe notater om testtilfellene og feilene dine hvis du ikke har tilstrekkelig tid til å skrive dem pent. La aldri disse papirløse. Hvis det er litt tid, kan du dele den med lederen eller teamet ditt, slik at hvis noe mangler, kan de enkelt påpeke det.
- Hvis du og teamet ditt har kort tid, må du sørge for at feilene er merket i riktig tilstand i en e-post? Du kan sende den komplette listen over bugs til teamet og få devsene til å merke dem på riktig måte. Hold alltid ballen i den andres bane.
- Hvis du har Automatiseringsrammeverk klar, bruk det og unngå å gjøre Manuell testing , på den måten på kortere tid kan du dekke mer.
- Unngå scenariet 'slipp på 1 time' med mindre du er 100% sikker på at du vil være i stand til å levere.
- Sist men ikke minst, som nevnt ovenfor, utarbeider du en detaljert utgivelses-e-post som kommuniserer hva som er testet, hva som er utelatt, årsaker, risiko, hvilke feil som er løst, hva som er 'Latered' osv.
Som kvalitetssikring bør du bedømme hva som er den viktigste delen av implementeringen som må testes, og hva er delene som kan utelates eller basistestes.
Selv på kort tid, planlegg en strategi for hvordan du vil gjøre, og du vil være i stand til å oppnå det beste i den gitte tidsrammen.
Røykprøving
Røykprøving er ikke uttømmende testing, men det er en gruppe tester som utføres for å verifisere om de grunnleggende funksjonene til den aktuelle bygningen fungerer som forventet eller ikke. Dette er og bør alltid være den første testen som gjøres på en hvilken som helst ‘ny’ bygning.
Når utviklingsteamet frigjør en build til QA for testing, er det åpenbart ikke mulig å teste hele builden og verifisere umiddelbart om noen av implementeringene har feil eller om noen av arbeidsfunksjonalitetene er brutt.
På bakgrunn av dette, hvordan vil en kvalitetssikring sørge for at de grunnleggende funksjonene fungerer bra?
Svaret på dette vil være å utføre en Røykprøving .
Når testene er merket som Røykprøver (i testpakken) bestått, blir først byggingen akseptert av QA for grundig testing og / eller regresjon. Hvis noen av røyktestene mislykkes, avvises bygningen, og utviklingsteamet må fikse problemet og frigjøre et nytt bygg for testing.
Teoretisk sett er røykprøven definert som testing på overflatenivå for å sertifisere at bygningen som ble gitt av utviklingsteamet til QA-teamet er klar for videre testing. Denne testingen blir også utført av utviklingsteamet før bygningen frigis til QA-teamet.
Denne testen brukes vanligvis i integrasjonstesting, systemtesting og akseptantnivåtesting. Aldri behandle dette som en erstatning for den faktiske fullstendige testen . Den består av både positive og negative tester, avhengig av implementeringen av bygningen.
Eksempler på røykprøving
Denne testen brukes normalt til integrering, aksept og Systemtesting .
I min karriere som kvalitetssikring godtok jeg alltid et bygg først etter at jeg hadde utført en røykprøve. Så la oss forstå hva som er en røykprøve fra perspektivet til alle disse tre testene, med noen eksempler.
# 1) Akseptprøving
Hver gang en utgave frigjøres til QA, må røykprøve i form av en Akseptprøving burde gjøres.
I denne testen er den første og viktigste røykprøven å verifisere den grunnleggende forventede funksjonaliteten til implementeringen. Som dette, bør du bekrefte alle implementeringene for den aktuelle bygningen.
La oss ta følgende eksempler som implementeringer utført i et bygg for å forstå røykprøvene for de:
- Implementerte påloggingsfunksjonaliteten slik at de registrerte driverne kan logge på.
- Implementerte dashbordfunksjonaliteten for å vise rutene som en sjåfør skal utføre i dag.
- Implementerte funksjonaliteten for å vise en passende melding hvis det ikke finnes ruter for en gitt dag.
I ovennevnte versjon, på akseptansnivå, vil røykprøven bety å verifisere at de tre grunnleggende implementeringene fungerer bra. Hvis noen av disse tre er ødelagte, bør kvalitetssikringen avvise bygningen.
# 2) Integrasjonstesting
Denne testingen gjøres vanligvis når de enkelte modulene er implementert og testet. I Integrasjonstesting nivå, blir denne testingen utført for å sikre at all grunnleggende integrasjon og ende til slutt-funksjonalitet fungerer som forventet.
Det kan være integrasjonen av to moduler eller alle modulene sammen, og derfor vil kompleksiteten i røykprøven variere avhengig av integrasjonsnivået.
La oss se på følgende eksempler på implementering av integrasjon for denne testen:
- Implementerte integrasjonen av rute- og stoppmoduler.
- Implementerte integrasjonen av ankomststatusoppdatering og gjenspeiler det samme på stoppskjermen.
- Implementerte integrasjonen av fullstendig henting til leveringsfunksjonalitetsmodulene.
I denne versjonen vil røykprøven ikke bare verifisere disse tre grunnleggende implementeringene, men for den tredje implementeringen vil noen få tilfeller også verifisere for fullstendig integrasjon. Det hjelper mye å finne ut hvilke spørsmål som blir introdusert i integrering og de som ikke ble lagt merke til av utviklingsteamet.
# 3) Systemtesting
Som navnet antyder, inkluderer røykprøving på systemnivå tester for de viktigste og mest brukte arbeidsflytene i systemet. Dette gjøres først etter at det komplette systemet er klart og testet, og denne testen for systemnivå kan også kalles røykprøving før regresjonstesting.
Før du starter regresjonen av det komplette systemet, blir de grunnleggende end-to-end-funksjonene testet som en del av røykprøven. Røykprøvesuiten for det komplette systemet består av end-to-end testtilfeller som sluttbrukerne kommer til å bruke veldig ofte.
Dette gjøres vanligvis ved hjelp av automatiseringsverktøy.
Viktighet i SCRUM-metodikk
I dag følger prosjektene knapt Waterfall-metoden i prosjektgjennomføring, for det meste følger alle prosjektene Agile og SKRUM kun. Sammenlignet med den tradisjonelle fossemetoden, tar Smoke Testing hilsen i SCRUM og Agile.
Jeg jobbet i 4 år i SCRUM . Og som vi vet at i SCRUM har sprintene kortere varighet, og det er derfor ekstremt viktig å gjøre denne testingen, slik at de mislykkede byggene umiddelbart kan rapporteres til utviklingsteamet og fikses også.
Følgende er noen ta bort om viktigheten av denne testingen i SCRUM:
- Ut av den fjortende sprinten tildeles halvtid til QA, men til tider blir byggingen til QA forsinket.
- I spurter er det best for teamet at problemene rapporteres på et tidlig stadium.
- Hver historie har et sett med akseptkriterier, og derfor er testing av de første 2-3 akseptkriteriene lik røykprøving av den funksjonaliteten. Kunder avviser leveransen hvis et enkelt kriterium mislykkes.
- Tenk deg hva som vil skje hvis det er to dager som utviklingsteamet leverte deg bygningen, og det er bare 3 dager igjen av demoen, og du støter på en grunnleggende funksjonsfeil.
- I snitt har en sprint historier som spenner fra 5-10, og derfor er det viktig å sørge for at hver historie blir implementert som forventet, før du godtar byggingen i testing.
- Når hele systemet skal testes og regres, er en sprint viet til aktiviteten. I fjorten dager, kanskje litt mindre for å teste hele systemet, er det derfor veldig viktig å verifisere de mest grunnleggende funksjonene før du starter regresjonen.
Smoke Test Vs Build Acceptance Testing
Smoke Testing er direkte relatert til Build Acceptance Testing (BAT).
I BAT gjør vi den samme testen - for å verifisere om build ikke har mislyktes, og at systemet fungerer bra eller ikke. Noen ganger hender det at når en build blir opprettet, blir noen problemer introdusert, og når den leveres, fungerer build ikke for QA.
Jeg vil si at BAT er en del av en røykkontroll, fordi hvis systemet svikter, hvordan kan du som kvalitetssikring godta byggingen for testing? Ikke bare funksjonalitetene, men selve systemet må fungere før kvalitetssikringen fortsetter med dybdetesting.
Røykprøvesyklus
Følgende flytskjema forklarer Smoke Testing Cycle.
Når en build er distribuert til en QA, er den grunnleggende syklusen som følges at hvis røykprøven består, blir builden akseptert av QA-teamet for videre testing, men hvis den mislykkes, avvises builden til de rapporterte problemene er løst.
Test syklus
Hvem skal utføre røykprøven?
Ikke hele teamet er involvert i denne typen tester for å unngå tidssvinnet til alle kvalitetssikringene.
Røykprøving utføres ideelt av QA-lederen som bestemmer ut fra resultatet om den skal overføre bygningen til teamet for videre testing eller avvise den. Eller i fravær av ledelsen, kan også QA’ene utføre denne testen.
Noen ganger, når prosjektet er i stor skala, kan en gruppe QA også utføre denne testen for å se etter eventuelle showstoppere. Men dette er ikke tilfellet med SCRUM, fordi SCRUM er en flat struktur uten ledere eller ledere, og hver tester har sitt eget ansvar overfor historiene sine.
Derfor utfører individuelle kvalitetssikringsselskaper denne testen for historiene de eier.
Hvorfor skal vi automatisere røykprøver?
Denne testingen er den første testen som gjøres på en build som er gitt ut av utviklingsteamet (e). Basert på resultatene av denne testingen, blir ytterligere testing gjort (eller byggingen avvises).
Den beste måten å gjøre denne testingen på er å bruke et automatiseringsverktøy og planlegge at røykpakken skal kjøre når en ny versjon blir opprettet. Du tenker kanskje hvorfor skulle jeg “Automatisere røykprøvesuiten”?
La oss se på følgende tilfelle:
La oss si at du er en uke unna løslatelse, og av de totalt 500 testtilfellene består røykprøvesuiten av 80-90. Hvis du begynner å utføre alle disse 80-90 testtilfellene manuelt, tenk deg hvor lang tid du vil ta? Jeg tror 4-5 dager (minimum).
Men hvis du bruker automatisering og lager skript for å kjøre alle disse 80-90 testtilfellene, vil disse ideelt sett kjøres på 2-3 timer, og du vil ha resultatene med deg umiddelbart. Sparte det ikke din dyrebare tid og ga deg resultatene om innbyggingen mye kortere tid?
For 5 år siden testet jeg en app for økonomisk projeksjon, som tok innspill om lønn, sparing osv., Og projiserte skatt, sparing, fortjeneste avhengig av de økonomiske reglene. Sammen med dette hadde vi tilpasning for land som er avhengig av landet og dets skatteregler som ble brukt til å endre (i koden).
For dette prosjektet hadde jeg 800 test tilfeller og 250 var røyk test tilfeller. Ved bruk av selen kunne vi enkelt automatisere og få resultatene av de 250 testtilfellene på 3-4 timer. Det sparte ikke bare vår tid, men viste oss ASAP om showstopperne.
Derfor, med mindre det er umulig å automatisere, ta hjelp av automatisering for denne testingen.
Fordeler og ulemper
La oss først se på fordelene, siden det har mye å tilby sammenlignet med de få ulempene.
Fordeler:
- Lett å utføre.
- Reduserer risikoen.
- Mangler ble identifisert på et veldig tidlig stadium.
- Sparer innsats, tid og penger.
- Kjører raskt hvis det er automatisert.
- Minst integrasjonsrisiko og problemer.
- Forbedrer den generelle kvaliteten på systemet.
Ulemper:
- Denne testen er ikke lik eller erstatning for fullstendig funksjonell testing.
- Selv etter at røykprøven er bestått, kan du finne showstopper-insekter.
- Denne typen testing er best egnet hvis du kan automatisere annet, det blir brukt mye tid på å manuelt utføre testsakene, spesielt i store prosjekter som har rundt 700-800 testsaker.
Røykprøving bør absolutt gjøres på alle bygg, da det påpeker de store feil og showstoppere på et veldig tidlig stadium. Dette gjelder ikke bare for nye funksjoner, men også for integrering av moduler, fikse problemer og improvisasjon også. Det er en veldig enkel prosess å utføre og få riktig resultat.
Denne testen kan behandles som inngangspunkt for fullstendig funksjonstesting av funksjonalitet eller system (som helhet). Men før det, QA-teamet bør være veldig tydelig på hvilke tester som skal gjøres som røykprøver . Denne testingen kan minimere innsatsen, spare tid og forbedre kvaliteten på systemet. Det har en veldig viktig plass i sprint da tiden i sprint er mindre.
Denne testingen kan gjøres både manuelt og også ved hjelp av automatiseringsverktøy. Men den beste og foretrukne måten er å bruke automatiseringsverktøy for å spare tid.
Forskjellen mellom røyk og sunnhetsprøving
De fleste ganger blir vi forvirret mellom betydningen av Sanity Testing og Smoke Testing. Først og fremst er disse to testene måte “ annerledes ”Og utført i forskjellige stadier av en testsyklus.
intervjuspørsmål på html5 og css3
S. Nei | Røykprøving | Sanity Testing |
---|---|---|
1 | Røykprøving betyr å verifisere (grunnleggende) at implementeringene som er gjort i en bygning fungerer bra. | Sanity testing betyr å verifisere at funksjoner, bugs osv. Som nylig er lagt til, fungerer bra. |
to | Dette er den første testen på den første byggingen. | Gjort når bygningen er relativt stabil. |
3 | Gjort på alle bygg. | Gjort på stabile bygg etter regresjon. |
Følgende er en skjematisk fremstilling av deres forskjeller:
RØYKTESTING
- Denne testen har sitt utspring i maskinvare teste praksis for å slå på et nytt stykke maskinvare for første gang og vurdere det som en suksess hvis det ikke tar fyr og røyk. I programvareindustrien er denne testingen en grunne og bred tilnærming der alle applikasjonsområdene testes uten å komme for dypt inn.
- En røykprøve er skriptet, enten ved hjelp av et skriftlig sett med tester eller en automatisert test
- En røykprøve er designet for å berøre alle deler av applikasjonen på en kort måte. Det er grunt og bredt.
- Denne testen utføres for å sikre om de viktigste funksjonene til et program fungerer, men ikke bry seg med de finere detaljene. (Som byggverifisering).
- Denne testingen er en normal helsekontroll av applikasjonen før du tar den for å teste grundig.
SANITY TESTING
- En fornuftstest er en smal regresjonstest som fokuserer på ett eller noen få funksjonsområder. Sanity Testing er vanligvis smal og dyp.
- Denne testen er vanligvis ikke skrevet.
- Denne testen brukes til å fastslå at en liten del av applikasjonen fortsatt fungerer etter en mindre endring.
- Denne testingen er kortvarig testing, den utføres når en kortvarig testing er tilstrekkelig til å bevise at applikasjonen fungerer i henhold til spesifikasjonene. Dette testnivået er en delmengde av regresjonstesting.
- Dette er for å verifisere om kravene er oppfylt eller ikke, sjekke alle funksjonene bredt først.
Håper du er klar over forskjellene mellom disse to store og viktige programvaretestene. Del gjerne tankene dine i kommentarfeltet nedenfor !!
Anbefalt lesing
- Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
- Forskjellen mellom Desktop, Client Server Testing og Web Testing
- Funksjonstesting mot ikke-funksjonell testing
- Testing Primer eBook Download
- Alpha Testing og Beta Testing (En komplett guide)
- Bærbarhetstestveiledning med praktiske eksempler
- Typer programvaretesting: Ulike testtyper med detaljer
- Funksjonstesting mot ytelsestesting: Bør det gjøres samtidig?