Good Mood

Utforske Forskjeller mellom Røyk Testing og Fornuft Testing i detalj med eksempler:

I denne opplæringen vil vi lære hva som er sunn Fornuft Testing og Røyk Testing Software Testing. Vi vil også lære viktige forskjeller mellom Fornuft og Røyk testing med enkle eksempler.

de Fleste av de gangene vi bli forvirret mellom betydningen av Fornuft Testing og Røyk Testing. Først av alt, disse to utprøving måte er «annerledes» og er utført i forskjellige stadier av en testing syklus.,

Fornuft Testing

Fornuft Testing er gjort når som et QA-vi har ikke nok tid til å kjøre hele testen tilfeller, kan det være Funksjonell Testing, UI, operativsystem eller Nettleser Testing.

Derfor, jeg vil definere,

«Fornuft Testing som en test kjøring som er gjort for å berøre hver gjennomføring og dens innflytelse, men ikke grundig eller i dybden, det kan være funksjonelle, UI, versjon, etc. testing avhengig gjennomføringen og dens innvirkning.»

Trenger vi ikke alle fall i en situasjon når vi har å melde seg ut i løpet av en dag eller to, men det bygges for testing, er fortsatt ikke gitt ut?,

Ah ja, jeg vedder på at du også må ha møtt denne situasjonen, minst en gang i dine Software Testing erfaring. Vel, jeg har opplevd det en mye fordi prosjektet mitt(s) for det meste var smidig og til tider ble vi bedt om å levere den samme dagen. Oops, hvordan kan jeg teste og slipp bygge innenfor en strekning av timer?

jeg pleide å gå nøtter til tider fordi at selv om det var en liten funksjonalitet, implikasjonen kan være enorm. Og som en glasur på kaken, klienter noen ganger rett og slett nekter å gi ekstra tid., Hvordan kan jeg fullføre hele testing i et par timer, må du kontrollere hver funksjonalitet, Bugs og slipp det?

svar til alle slike problemer var veldig enkel, jeg.e ingenting, men ved hjelp av Fornuften Testing strategi.

Når vi gjør dette for å teste for en modul, eller funksjonalitet eller et komplett system, Test sakene for gjennomføring er valgt slik at de vil berøre alle de viktige biter og stykker av samme dvs. bredt, men grunne testing.

Til tider testing er også gjort tilfeldig med noen test tilfeller., Men husk, sunn Fornuft test bør bare gjøres når du kjører kort tid, aldri bruk dette til din vanlige utgivelser. Teoretisk, testing dette er en delmengde av regresjonstesting.

Min Erfaring

Ut av min 8+ år av karrieren i Programvare Testing, for 3 år jobbet jeg i Agile-metoder, og det var den tiden da jeg for det meste brukt et fornuft test.

Alle de store utgivelsene var planlagt og utført på en systematisk måte, men til tider, små utgivelser ble bedt om å bli levert så snart som mulig., Vi fikk ikke mye tid til å dokumentere test tilfeller, utføre, gjør at det er en feil i dokumentasjonen, gjør regresjon og følge hele prosessen.

Derfor følgende er noen av de viktigste markørene for at jeg brukte til å følge under slike situasjoner:

#1) Sitter med leder-og utviklingsgruppen når de diskuterer gjennomføringen fordi de har til å arbeide raskt og derfor kan vi ikke forvente at de skal forklare oss separat.

Dette vil også hjelpe deg å få en idé om hva de kommer til å implementere, som området vil det påvirke etc., dette er en svært viktig ting å gjøre fordi vi til tider rett og slett ikke skjønner implikasjoner og hvis noen eksisterende funksjonalitet kommer til å bli hindret (i verste fall).

#2) Som du er kort tid, etter den tid utvikling team jobber med på gjennomføringen, kan du skrive ned testtilfeller omtrent i verktøy som Evernote, etc. Men pass på at du skriver dem et sted slik at du kan legge dem til senere til test verktøy.,

#3) Holde teststed klar som per implementering og hvis du føler at det er noen røde flagg som noen spesifikke data etableringen hvis et teststed vil ta tid (og det er en viktig test for utgivelsen), for deretter å høyne de flagg umiddelbart og informere din leder eller PO om veisperringen.

Bare fordi kunden ønsker asap, men det betyr ikke at en QA vil slippe selv om det er halvparten testet.,

#4) Gjør en avtale med teamet og manager som på grunn av crunch tid vil du bare kommunisere feilene til utviklingsteamet og den formelle prosessen med å legge til, merking bugs for ulike stadier i bug tracking tool vil bli gjort senere i for å spare tid.

#5) Når teamet er testing på slutten, kan du prøve å koble sammen med dem (kalt dev-QA sammenkobling) og gjøre en grunnleggende runde på deres oppsett selv, så vil dette bidra til å unngå hit og dit av bygge om grunnleggende gjennomføring er sviktende.,

#6) Nå som du har til å bygge, teste business regler og alle bruken tilfeller først. Du kan holde tester som en validering av et felt, navigasjon, etc for senere.

#7) Hva bugs deg å finne, lage et notat av alle av dem, og prøv å rapportere dem sammen til utviklerne heller enn rapportering av individuelt fordi det vil være lett for dem å jobbe på en haug.

#8) Hvis du har et krav for den generelle Ytelsen Testing eller Stress eller Legg Testing, så sørg for at du har en skikkelig automatisering rammeverk for det samme., Fordi det er nær umulig å manuelt teste disse med en fornuft test.

#9) Dette er den viktigste delen, og faktisk det siste trinnet av forstanden test strategi – «Når du utkast utgivelsen e-post eller dokumentet, kan du nevne alle test tilfeller, at du utførte, bugs funnet med en status som markør, og hvis alt ble stående uprøvd nevne det med grunner», kan du Prøve å skrive en sprø historie om testingen som vil formidle alle om hva som har vært prøvd, verifisert og hva som ikke har vært.

jeg har fulgt denne religiøst når jeg var ved hjelp av denne testingen.,

La meg dele min egen erfaring:

#1) Vi jobbet på et nettsted, og det brukes til å popup-annonser basert på søkeord. Annonsørene som brukes til å plassere bud for bestemte søkeord som hadde en skjerm som er designet for det samme. Standardbudet verdien som brukes til å bli vist som $0,25, som tilbyder kan til og med endre.

Det var ett sted der denne standard budet som brukes til å dukke opp, og det kan være byttet til andre verdien. Klienten kom med en forespørsel om å endre standardverdien fra $0.25 til $0.5 men han nevnes bare de åpenbare skjermen.,

i Løpet av vår brainstorming diskusjon, vi har glemt (?) om dette andre skjermen fordi det var ikke mye brukt for dette formålet. Men mens testing når jeg kjørte grunnleggende tilfelle av budet blir $0,5 og sjekket ende til ende, og jeg fant ut at cronjob for det samme var sviktende fordi på ett sted det var å finne $0.25.

jeg rapporterte dette til mitt team og vi har gjort endringer og levert det på samme dag selv.

#2) Under samme prosjekt (nevnt ovenfor), ble vi bedt om å legge inn en liten tekst-felt for noter/kommentarer til bud., Det var en veldig enkel implementering og vi er forpliktet til å levere det samme dag.

Derfor, som nevnt ovenfor, jeg testet alle business regler og bruk saker rundt det, og når jeg gjorde noen validering testing, fant jeg ut at når jeg kom inn i en kombinasjon av spesielle tegn som </>, siden krasjet.

Vi tenkte over det og funnet ut at den faktiske tilbydere vil ikke i noe tilfelle bruker slike kombinasjoner. Dermed slapp vi det med en godt utarbeidet notat om saken., Kunden akseptert det som en bug, men som er avtalt med oss for å gjennomføre det senere fordi det var en alvorlig feil, men ikke før ett.

#3) Nylig, ble jeg arbeider på en mobil app prosjektet, og vi hadde en forpliktelse til å oppdatere klokkeslett for levering vist i app som per time zone. Det var ikke bare for å bli testet i programmet, men også for web-tjenesten.

Mens teamet arbeidet på gjennomføringen, opprettet jeg automatisering skript for web service testing og DB-skript for å endre tidssonen for levering element., Dette reddet min innsats, og vi kunne oppnå bedre resultater i løpet av kort varighet.

Fornuft Testing Vs regresjonstesting

Gitt nedenfor er noen forskjeller mellom de to:

Strategi For Mobile App-Testing

Du må lure på hvorfor jeg å nevne spesifikt om mobile apps her?

grunnen er at OS og nettleser-versjon for web eller desktop apps ikke varierer mye, og spesielt skjermen størrelser er standard. Men med mobile apps, skjermstørrelse, den mobile nettverk, OS-versjoner, etc påvirker stabilitet, utseende og i korte, suksessen av din mobile app.,

Derfor en strategi formulering blir kritisk når du utfører denne testingen på en mobil app fordi en unnlatelse kan lande deg i en masse problemer. Testing må gjøres smartere og med forsiktighet også.

her er noen tips for å hjelpe deg med å utføre testing dette med hell på en «mobil-app’:

#1) Først av alt, analysere virkningen av OS-versjon på gjennomføring med ditt team.

Prøv å finne svar på spørsmål som vil atferden være forskjellige på tvers av versjonene? Vil gjennomføringen arbeid på den lavest versjon som støttes eller ikke?, Vil det være ytelsesproblemer for gjennomføring av versjonene? Er det noen spesifikk funksjon av OS-et som kan påvirke atferden til gjennomføringen? osv.

#2) På ovennevnte notat, analysere for telefonen modeller også dvs. er det noen funksjoner på telefonen som vil få konsekvenser for gjennomføringen? Er implementeringen av atferd-endring med GPS? Er gjennomføringen atferd endrer seg med telefonens kamera? osv. Hvis du finner ut at det er ingen innvirkning, unngå testing på ulike modeller.,

#3) med Mindre det er noen endringer i GRENSESNITTET for gjennomføring vil jeg anbefale å holde UI testing på minst prioritet, kan du informere team (hvis du vil) som UI vil ikke bli testet.

#4) for å spare tid, unngå testing på gode nettverk fordi det er åpenbart at gjennomføringen skal fungere som forventet på et sterkt nettverk. Jeg vil anbefale å starte med å teste på en 4G-eller 3G-nettverk.

#5) Denne testingen er å være gjort på mindre tid, men sørg for at du minst en felttest med mindre det er en ren endre UI.,

#6) Hvis du må teste for en matrise av ulike OS og deres versjon, jeg vil foreslå at du gjør det på en smart måte. For eksempel, velg den laveste, medium og den nyeste OS-versjon par for testing. Du kan nevne i frigi dokumentet at ikke alle kombinasjoner er testet.

#7) På en tilsvarende linje, for UI gjennomføring fornuft test, bruk liten, medium og stor størrelse for å spare tid. Du kan også bruke en simulator og emulator.,

Forholdsregler

Fornuft Testing er utført når du kjører kort tid, og derfor er det ikke mulig for deg å kjøre hver og hver test og viktigst du ikke får nok tid til å planlegge testingen. For å unngå skylden spill, det er bedre å ta forholdsregler.

I slike tilfeller mangel på skriftlig kommunikasjon, test, dokumentasjon og savner outs er ganske vanlig.,

for Å sikre at du ikke faller byttedyr til dette, må du kontrollere følgende:

• Aldri godta et bygg for testing før du er ikke gitt en skriftlig krav som deles av oppdragsgiver. Det hender at klienter kommunisere endringer eller nye implementeringer verbalt eller i chat eller en enkel 1 liner i en e-post og forvente oss å behandle det som et krav. Tvinge klienten til å gi noen grunnleggende funksjonalitet poeng og kriterier for aksept.
• kontroller Alltid grov merk av test-tilfeller og feil hvis du ikke har tilstrekkelig tid til å skrive dem pent. Aldri la disse udokumenterte., Hvis det er noen tid, dele det med din ledelse eller teamet, slik at hvis noe mangler de kan peke det ut.
• Hvis du og teamet ditt har lite tid, sørg for at den feil som er merket i de aktuelle staten i en e-post? Du kan sende e-post fullstendig liste over feil som er til laget og gjøre devs merke dem riktig. Alltid holde ballen i den andre s court.
• Hvis du har Automation Framework klar, bruke det og unngå å gjøre ManualTesting, på den måten i mindre tid du kan dekke mer.,
• Unngå det 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 en detaljert utgivelsen e-post kommunisere hva som er testet, hva som er utelatt, årsaker, risiko, som bugs er løst, hva er ‘Latered’ osv.

Som en QA, du skal bedømme hva som er den viktigste delen av gjennomføringen som trenger å bli testet, og hva som er de delene som kan være utelatt eller grunnleggende-testet.,

Selv i en kort tid, planlegge en strategi om hvordan du vil gjøre, og du vil være i stand til å oppnå det beste i den gitte tidsrammen.

Røyk Testing

Røyk Testing er ikke uttømmende testing, men det er en gruppe av tester som er utført for å kontrollere om den grunnleggende funksjonaliteten til en bestemt bygg er fungerer fint som forventet eller ikke. Dette er og skal alltid være den første testen gjøres på et «nytt» bygg.,

Når teamet lanserer et bygg til QA for testing, er det åpenbart ikke mulig å teste hele bygge og kontrollere umiddelbart dersom noen av implementeringer er å ha feil, eller om noen av de som arbeider funksjonalitet er brutt.

I lys av dette, hvordan vil et QA sørge for at de grunnleggende funksjonene fungerer fint?

svaret På dette vil være å utføre en Røyk Testing.

Når testene er merket som Røyk tester (i test-suite) pass, bare så bygge er akseptert av QA for grundig testing og/eller regresjon., Hvis noen av røyk tester mislykkes, bygge avvises og utvikling team trenger for å fikse problemet, og slipper en ny versjon for testing.

Teoretisk, Røyken testen er definert som overflate-nivå-testingen for å bekrefte at bygge gitt av utvikling team til QA-teamet er klar for videre testing. Denne testingen er også utført av teamet før du slipper bygge til QA-teamet.

Dette vanligvis brukes i integrasjonstesting, System Testing, og Aksept Nivå Testing. Aldri behandle dette som en erstatning for den faktiske ende-til-ende komplett testing., Det består av både positive og negative tester avhengig av bygge-implementering.

Røyk Testing Eksempler

Denne testingen er vanligvis brukt for Integrering, Aksept og systemtesting.

I min karriere som QA, jeg har alltid akseptert en bygge bare etter at jeg hadde utført en røyk test. Så, la oss forstå hva som er en smoke test fra perspektivet av alle disse tre utprøving, med noen eksempler.

#1) Aksept Testing

Når et bygg er gitt til QA, røyk test i form av en Aksept Testing bør gjøres.,

I denne testen, den første og viktigste røyk testen er å verifisere grunnleggende forventet funksjonalitet av gjennomføringen. Som dette, bør du kontrollere alle implementeringer for det aktuelle bygg.

La oss ta følgende Eksempler som implementeringer gjort i en bygge for å forstå røyk tester for disse:

• Implementert login funksjonalitet for å tillate registrert drivere for å logge inn.
• Implementert dashbordet funksjonalitet for å vise ruter om at en driver er å kjøre i dag.,
• Implementert funksjonalitet for å vise en passende melding hvis ingen ruter finnes på en gitt dag.

I den ovenfor bygger på aksept nivå, røyken test vil si å kontrollere at den grunnleggende tre implementasjoner fungerer fint. Hvis en av disse tre er ødelagt, så QA bør avvise bygge.

#2) Integrering-Testing

Denne testingen er vanligvis gjort når de enkelte modulene er implementert og testet., I integrasjonstesting nivå, denne testingen er utført for å sørge for at alle grunnleggende integrering og ende-til-ende funksjonene fungerer fint som forventet.

Det kan være integrering av to moduler eller alle modulene sammen, derfor kompleksiteten av smoke test vil variere avhengig av hvilken grad av integrasjon.

La oss se på følgende Eksempler på integrasjon gjennomføring for testing dette:

• Implementert integrering av route og stopper moduler.
• Implementert integrering av ankomst status oppdatering og gjenspeiler de samme på de stopper skjermen.,
• Implementert integrasjon av komplette plukke opp till levering funksjonalitet moduler.

I denne bygger på, røyk testen, vil ikke bare bekrefte disse tre grunnleggende implementeringer, men for tredje gjennomføring, et par tilfeller vil bekrefte for fullstendig integrasjon også. Det hjelper mye å finne ut av problemer som blir introdusert i integrering og de som gikk ubemerket av utviklingsteamet.

#3) System Testing

Som navnet selv antyder, for system-nivå, røyken testing inneholder tester for de viktigste og mest brukte arbeidsflyter av systemet., Dette gjøres bare etter at alle komplette system er klar & testet, og denne testingen for system-level kan bli referert til som røyk testing før regresjonstesting også.

Før du starter regresjon av hele systemet, de grunnleggende ende-til-ende-funksjoner er testet som en del av smoke test. Røyken test suite for hele systemet består av ende-til-ende test tilfeller at sluttbrukere kommer til å bruke veldig ofte.

Dette er vanligvis gjort med hjelp av automatisering verktøy.,

Betydning I SCRUM-Metodikk

i Dag, prosjekter knapt følge Foss metodikk i prosjektet implementering, stort sett alle prosjekter følg Smidig og SCRUM bare. I forhold til de tradisjonelle foss metode, Røyk Testing holder høy hilsen i SCRUM og Smidig.

jeg jobbet 4 år i SCRUM. Og som vi vet at i SCRUM, og spurter er av kortere varighet, og derfor er det ekstremt viktig å gjøre denne testingen, slik at den ikke klarte bygger kan umiddelbart meldes til utviklingsteamet og fast så godt.,

her er noen takeaway på betydningen av denne testingen i SCRUM:

• Ut av fjorten dager sprint, pausen er allokert til QA-men til tider bygger til QA er forsinket.
• I sprinter, det er best for laget at problemene er rapportert på et tidlig stadium.
• Hver historie har et sett av kriterier for aksept, derfor teste den første 2-3 akseptkriterier er lik røyk testing av funksjonalitet. Kunder avvise levering hvis en enkelt kriterium er sviktende.,
• Bare forestille seg hva som vil skje hvis det er 2 dager at teamet levert du bygge-og bare 3 dager igjen til demo, og du kommer over en grunnleggende funksjonalitet feil.
• i gjennomsnitt en sprint har historier alt fra 5-10, derfor når byggingen er gitt er det viktig å sørge for at hver historie er implementert som forventet før du aksepterer bygge inn testing.
• Når hele systemet er å bli testet og regressed, en sprint er dedikert til aktivitet., Et par uker kanskje litt mindre for å teste hele systemet, derfor er det svært viktig å kontrollere de mest grunnleggende funksjonene før du starter regresjon.

Røyk Test Vs Bygge Aksept Testing

Røyk Testing er direkte i slekt å Bygge Aksept Testing (BAT).

I BAT, vi gjør det samme testing – for å kontrollere om bygg har ikke sviktet, og at systemet fungerer fint eller ikke. Noen ganger skjer det at når et bygg er opprettet, noen problemer å få innført og når den er levert, bygge arbeider ikke for QA.,

jeg vil si at FLAGGERMUS er en del av en røyk sjekk fordi hvis systemet er sviktende, hvordan kan du som en QA godta bygge for testing? Ikke bare funksjonaliteten systemet i seg selv er nødt til å arbeide før QA oss fortsette med grundig Testing.

Røyk Test Syklus

følgende flytskjema forklarer Røyk Testing Syklus.

Når et bygg er distribuert til et QA, de grunnleggende syklus som følges er at hvis røyken testen går, bygge er akseptert av QA-teamet for ytterligere testing, men hvis det mislykkes, bygge avvises før de rapporterte problemene er løst.,

Test Syklus

Som Skal Utføre Røyk-Test?

Ikke hele laget er involvert i denne type testing for å unngå sløsing av tid for alle QA-tallet.

Røyk Testing er en ideell utført av QA-leder som bestemmer basert på resultatet som for enten å passere bygge laget for ytterligere testing eller avvise det. Eller i fravær av ledelsen, de QA er i seg selv kan også utføre denne testingen.

noen ganger når prosjektet er en stor skala, en gruppe av QA kan også utføre denne testingen for å sjekke for eventuelle showstoppere., Men slik er det ikke i tilfelle av SCRUM fordi SCRUM er en flat struktur med ingen Leder eller Ledere og tester hvert har sitt eget ansvar overfor sine historier.

Derfor individuelle QA ‘ s utføre denne testingen for historier som de eier.

Hvorfor Skal Vi Automatisere Røyk Tester?

Denne testingen er den første testen skal utføres på en bygge utgitt av utviklingsteamet(s). Basert på resultatene fra denne testingen, videre testing er gjort (eller bygge er avvist).,

Den beste måten å gjøre denne testingen er å bruke en automatisering verktøy og planlegge røyk suite til å kjøre når en ny versjon er opprettet. Du tenker kanskje hvorfor skal jeg «automatisere røyk testing suite»?

La oss se på følgende tilfelle:

La oss si at du er en uke unna utgivelsen og ut av de totalt 500 test tilfeller, din røyk test suite består av 80-90. Hvis du begynner å utføre alle disse 80-90 test tilfeller manuelt, kan du forestille deg hvor mye tid vil du ta? Jeg tror 4-5 dager (minimum).,

Men hvis du bruker automatisering og lage skript for å kjøre alle disse 80-90 test tilfeller så ideelt sett, disse vil bli kjørt i 2-3 timer og du vil ha resultater med deg umiddelbart. Ikke det du lagre din dyrebare tid, og gi deg resultatene om bygge-i mye mindre tid på?

5 år tilbake, ble jeg teste en økonomisk projeksjon-appen, som tok innganger om din lønn, sparing, etc. og anslått skatt, sparing, fortjeneste avhengig av den finansielle regler. Sammen med dette, vi hadde tilpasning for land som er avhengige av landet og dets skattereglene som brukes til å endre (i kode).,

For dette prosjektet, jeg hadde 800 test tilfeller, og 250 var røyk test tilfeller. Med bruk av Selen, kunne vi enkelt automatisere og få resultatene av de 250 test tilfeller i 3-4 timer. Det er ikke bare reddet vår tid, men viste oss ASAP om showstoppere.

Derfor, med mindre det er umulig å automatisere, tar hjelp av automatisering for denne testingen.

Fordeler Og Ulemper

La oss først ta en titt på fordelene som det har mye å tilby når sammenlignet med noen ulemper.

Fordeler:

• Enkel å utføre.
• Reduserer risikoen.,
• Feil blir identifisert på et tidlig stadium.
• Lagrer innsats, tid og penger.
• Går raskt hvis automatisert.
• Minst integrering risikoer og problemer.
• Forbedrer den generelle kvaliteten på systemet.

Ulemper:

• Denne prøvingen er ikke lik eller en erstatning for fullstendig funksjonell testing.
• Selv etter røyken passerer testen, kan du finne showstopper bugs.,
• Denne typen testing er best egnet hvis du kan automatisere annet mye tid er brukt på å manuelt kjøre test tilfeller, spesielt i store prosjekter å ha rundt 700-800 test tilfeller.

Røyk Testing bør definitivt gjøres på hver bygge som den peker på store feil og showstoppere på et svært tidlig stadium. Dette gjelder ikke bare nye funksjoner, men også til integrering av moduler, løse problemer og improvisasjon som godt. Det er en veldig enkel prosess å utføre og få riktig resultat.,

Denne testingen kan bli behandlet som inngangspunkt for fullstendig Funksjonell Testing av funksjonalitet eller system (som helhet). Men før det, QA team bør være veldig klar på hvilke tester som skal gjøres som røyk tester. Denne testingen kan minimere innsats, kan du spare tid og forbedre kvaliteten på systemet. Den har en svært viktig plass i spurter som tid i sprint er mindre.

Denne testingen kan utføres både manuelt og også med hjelp av automatisering verktøy. Men den beste og foretrukne måte er å bruke automatisering verktøy for å spare tid.,

Forskjellen Mellom Røyk Og Fornuft Testing

de Fleste av de gangene vi bli forvirret mellom betydningen av Fornuft Testing og Røyk Testing. Først av alt, disse to utprøving måte er «annerledes» og utført i forskjellige stadier av en testing syklus.

Følgende er en skjematisk fremstilling av forskjellene:

RØYK TESTING

• Denne testingen stammer i hardware testing praksis med å på et nytt stykke maskinvare for første gang, og vurderer det til en suksess hvis den ikke kom i brann og røyk. I programvareindustrien, testing dette er en langgrunn og bred tilnærming der alle deler av programmet uten å komme inn i for dypt, er testet.,
• En røyk testen er scriptet, enten ved hjelp av en skrevet av tester eller en automatisert test
• En Røyk testen er utformet for å berøre hver del av programmet i en overfladisk måte. Det er langgrunn og bred.
• Denne testingen er gjennomført for å sikre om de mest avgjørende funksjoner i et program som er i arbeid, men ikke bry deg med finere detaljer. (For eksempel bygge verifisering).
• testing Dette er en normal helse-sjekk-opp til oppbygging av et program før du tar den til test i dybden.,

FORNUFT TESTING

• En forstanden test er en smal regresjon tester som fokuserer på ett eller noen få områder av funksjonalitet. Fornuft Testing er vanligvis smal og dyp.
• Denne testen er vanligvis unscripted.
• Denne testen brukes for å bestemme at en liten del av programmet er fortsatt i arbeid etter en liten endring.
• Denne testingen er overfladisk testing er utført når en overfladisk testing er tilstrekkelig til å bevise at programmet fungerer i henhold til spesifikasjonene. Dette nivå av testing er et delsett av regresjonstesting.,
• Dette er for å kontrollere om kravene er oppfylt eller ikke, kontrollere alle funksjoner bredde-først.