Menu

Den nøjagtige forskel mellem verifikation og validering med eksempler

  • Vigtigste
  • Andet
  • Den nøjagtige forskel mellem verifikation og validering med eksempler

exact difference between verification

Prøv Vores Instrument Til At Fjerne Problemer

Verifikation vs validering: Udforsk forskellene med eksempler

Det er det tilbage til det grundlæggende folkens! Et klassisk kig på forskellen mellem Verifikation og validering .

Der er meget forvirring og debat omkring disse vilkår i softwaretestverdenen.

I denne artikel vil vi se, hvad verifikation og validering er set fra softwaretest. I slutningen af ​​denne artikel får vi forskellen mellem de to udtryk.

Forskel mellem verifikation og validering

Følgende er nogle af de vigtige grunde til at forstå forskellen:

  1. Det er et grundlæggende QA-koncept, derfor er det næsten byggestenen til at være QA-opmærksom.
  2. Dette er en ofte stillet Software Testing Interview Spørgsmål .
  3. Certificering pensum har et stort antal kapitler, der drejer sig om dette.
  4. Endelig, og praktisk talt når vi testere udfører begge disse testtyper, kan vi lige så godt være eksperter på dette.

Hvad du vil lære:

Hvad er verifikation og validering i softwaretest?

I forbindelse med testning “ Verifikation og validering ”Er de to almindeligt anvendte udtryk. For det meste betragter vi begge vilkårene som de samme, men faktisk er disse vilkår ret forskellige.

Der er to aspekter af V&V (Verification & Validation) opgaver:

  • Bekræfter kravene (Producentens syn på kvalitet)
  • Velegnet til brug (forbrugernes kvalitetssyn)

Producentens syn på kvalitet betyder i enklere termer udviklernes opfattelse af det endelige produkt.
Forbrugerne ser kvalitet betyder brugerens opfattelse af det endelige produkt.

Når vi udfører V & V-opgaverne, skal vi koncentrere os om begge disse kvalitetsopfattelser.

Lad os først starte med definitionerne af verifikation og validering, og derefter vil vi forstå disse termer med eksempler.

Bemærk: Disse definitioner er som nævnt i QAI's CSTE CBOK (tjek dette link for at vide mere om CSTE).

Hvad er verifikation?

Verifikation er processen med at evaluere de mellemliggende arbejdsprodukter i en softwareudviklings livscyklus for at kontrollere, om vi er i rette spor til at skabe det endelige produkt.

Med andre ord kan vi også sige, at verifikation er en proces til evaluering af softwaremæglerprodukter for at kontrollere, om produkterne opfylder de betingelser, der er pålagt i starten af ​​fasen.

Nu er spørgsmålet her: Hvad er formidlings- eller mæglerprodukterne?

Nå, disse kan omfatte de dokumenter, der produceres i udviklingsfaserne som kravkrav, designdokumenter, databasetabeldesign, ER-diagrammer, testcases, sporbarhedsmatrix , etc.

Vi har undertiden en tendens til at forsømme vigtigheden af ​​at gennemgå disse dokumenter, men vi skal forstå, at gennemgang i sig selv kan finde ud af mange skjulte uregelmæssigheder, når det kan være meget dyrt, hvis det findes eller løses i den senere fase af udviklingscyklussen.

Verifikation sikrer, at systemet (software, hardware, dokumentation og personale) overholder en organisations standarder og processer, afhængig af gennemgang eller ikke-eksekverbare metoder.

Hvor udføres verifikation?

Specifikt for IT-projekter er følgende nogle af de områder (jeg må understrege, at dette ikke alt er), hvor verifikation udføres.

VerifikationssituationAktørerDefinitionProduktion
Testdokumentation gennemgang (Peer review)QA-teammedlemmerEn peer review er, hvor teammedlemmerne gennemgår hinandens arbejde for at sikre, at der ikke er nogen fejl i selve dokumentationen.Testdokumentation klar til at blive delt med de eksterne teams.
Forretning / funktionskrav gennemgangDev team / klient til forretningskrav.Dette er et nødvendigt skridt for ikke kun at sikre, at kravene er samlet og / eller korrekt, men også at sikre, om de er gennemførlige eller ej.Afsluttede krav, der er klar til at blive forbrugt af det næste trin - design.
Design anmeldelseDev teamEfter designoprettelsen gennemgår Dev-teamet det grundigt for at sikre, at de funktionelle krav kan opfyldes via det foreslåede design.Design er klar til at blive implementeret i et it-system.
Kode gennemgangIndividuel udviklerKoden, når den er skrevet, gennemgås for at identificere eventuelle syntaktiske fejl. Dette er mere afslappet og udføres af den enkelte udvikler på den kode, der er udviklet af sig selv.Kode klar til enhedstest.
KodeinspektionDev teamDette er en mere formel opstilling. Emneeksperter og udviklere kontrollerer koden for at sikre, at den er i overensstemmelse med de forretningsmæssige og funktionelle mål, der er målrettet mod softwaren.Kode klar til test.
Testplan gennemgang (internt for QA team)QA teamEn testplan gennemgås internt af QA-teamet for at sikre, at den er nøjagtig og komplet.Et testplandokument klar til at blive delt med de eksterne teams (projektledelse, forretningsanalyse, udvikling, miljø, klient osv.)
Testplan gennemgang (ekstern)Projektleder, forretningsanalytiker og udvikler.En formel analyse af testplandokumentet for at sikre, at tidslinjen og andre overvejelser i QA-teamet er i tråd med de andre hold og hele selve projektet.Et underskrevet eller godkendt testplandokument, som testaktiviteten skal baseres på.
Testdokumentation endelig gennemgangForretningsanalytiker og udviklingsteam.En testdokumentation gennemgang for at sikre, at testcases dækker alle forretningsforholdene og funktionelle elementer i systemet.Testdokumentation klar til at blive udført.

Se test dokumentation gennemgang artikel, der udgiver en detaljeret proces om, hvordan testere kan udføre gennemgangen.

Hvad er validering?

Validering er processen med at evaluere det endelige produkt for at kontrollere, om softwaren opfylder forretningsbehovet. Med enkle ord er den testudførelse, vi udfører i vores daglige liv, faktisk den valideringsaktivitet, der inkluderer røgtest , funktionstest, regressionstest, systemtest osv.

Validering er alle former for test, der involverer at arbejde med produktet og sætte det på prøve.

Nedenfor er valideringsteknikkerne:

Validering sikrer fysisk, at systemet fungerer efter en plan ved at udføre systemfunktionerne gennem en række tests, der kan observeres og evalueres.

Fair nok, ikke? Her kommer mine to cent:

Når jeg forsøger at håndtere dette V&V koncept i min klasse, er der en masse forvirring omkring det. Et simpelt, lille eksempel ser ud til at løse al forvirringen. Det er noget fjollet, men fungerer virkelig.

Validerings- og verifikationseksempler

Eksempel på det virkelige liv :Forestil dig, at du går til en restaurant / spisestue og bestiller måske blåbærpandekager. Når tjeneren / servitrice bringer din ordre ud, hvordan kan du fortælle, at den mad, der kom ud, er i henhold til din ordre?

De første ting er, at vi ser på det og bemærker følgende ting:

test cases eksempel til webapplikation
  • Ser maden ud, som pandekager typisk ser ud til at være?
  • Skal blåbærene ses?
  • Lugter de rigtigt?

Måske mere, men du forstår kernen?

På den anden side, når du skal være helt sikker på, om maden er som forventet: Du bliver nødt til at spise den.

Bekræftelse er alt, når du endnu ikke skal spise, men kontrollerer et par ting ved at gennemgå emnerne. Validering er, når du faktisk spiser produktet for at se, om det er rigtigt.

I denne sammenhæng kan jeg ikke lade være med at vende tilbage til CSTE CBOK reference. Der er en vidunderlig erklæring derude, der hjælper os med at bringe dette koncept hjem.

Verifikation svarer på spørgsmålet: 'Har vi bygget det rigtige system?' mens valideringer adresserer, 'Har vi bygget systemet rigtigt?'

V&V i forskellige faser af udviklingslivscyklussen

Verifikation og validering udføres i hver af faserne i udviklingslivscyklussen.

Lad os prøve at se på dem.

# 1) V & V-opgaver - Planlægning

  • Kontrol af kontrakt.
  • Evaluering af konceptdokument.
  • Udfører risikoanalyse.

# 2) V & V-opgaver - Kravsfase

  • Evaluering af softwarekrav.
  • Evaluering / analyse af grænsefladerne.
  • Generering af systemtestplanen.
  • Generering af acceptplan.

# 3) V&V opgaver - Designfase

  • Evaluering af software design.
  • Evaluering / analyse af grænsefladerne (UI).
  • Generering af integrationstestplan.
  • Generering af komponenttestplanen.
  • Generering af testdesign.

# 4) V&V opgaver - Implementeringsfase

  • Evaluering af kildekode.
  • Evaluering af dokumenter.
  • Generering af testsager.
  • Generering af testproceduren.
  • Udførelse af komponenttestsager.

# 5) V&V opgaver - Testfase

  • Udførelse af systemtestsag.
  • Udførelse af accepttestsagen.
  • Opdatering af sporbarhedsmålinger.
  • Risikoanalyse

# 6) V&V opgaver - Installations- og kassen

  • Revision af installation og konfiguration.
  • Den sidste test af installationskandidatbygningen.
  • Generering af den endelige testrapport.

# 7) V&V opgaver - Driftsfase

  • Evaluering af nye begrænsninger.
  • Vurdering af den foreslåede ændring.

# 8) V&V opgaver - Vedligeholdelsesfase

  • Evaluering af anomalierne.
  • Vurdering af migration.
  • Vurdering af genoptagelsesfunktionerne.
  • Vurdering af den foreslåede ændring.
  • Validering af produktionsproblemer.

Forskellen mellem kontrol og validering

Verifikation mod validering

VerifikationValidering
Evaluerer mellemprodukterne for at kontrollere, om de opfylder de specifikke krav i den bestemte fase.Evaluerer det endelige produkt for at kontrollere, om det opfylder forretningsbehovet.
Kontrollerer, om produktet er bygget i henhold til det specificerede krav og designspecifikation.Det bestemmer, om softwaren er egnet til brug og tilfredsstiller forretningsbehovet.
Kontrol “Bygger vi produktet rigtigt”?Kontrol “Bygger vi det rigtige produkt”?
Dette gøres uden at udføre softwaren.Er færdig med at udføre softwaren.
Involverer alle de statiske testteknikker.Inkluderer alle dynamiske testteknikker.
Eksempler inkluderer anmeldelser, inspektion og gennemgang.Eksemplet inkluderer alle typer test som røg, regression, funktionel, systemer og UAT.

Forskellige standarder

ISO / IEC 12207: 2008

VerifikationsaktiviteterValideringsaktiviteter
Kravsbekræftelse indebærer en gennemgang af kravene.Forbered testkravsdokumenterne, testcases og andre testspecifikationer for at analysere testresultaterne.
Designverifikation involverer gennemgang af alle designdokumenter, herunder HLD og LDD.Evaluer, at disse testkrav, testtilfælde og andre specifikationer afspejler kravene og er egnet til brug.
Kodebekræftelse inkluderer kodegennemgang.Test for grænseværdier, stress og funktionaliteter.
Dokumentationsbekræftelse er verifikation af brugervejledninger og andre relaterede dokumenter.Test for fejlmeddelelser, og i tilfælde af fejl, afsluttes applikationen yndefuldt. Tester, at softwaren opfylder forretningskravene og er egnet til brug.

CMMI:

Verifikation og validering er to forskellige KPA'er på modenhedsniveau 3

VerifikationsaktiviteterValideringsaktiviteter
Udfører peer reviews.Bekræft, at produkterne og dets komponenter er egnede til miljøet.
Bekræft de valgte arbejdsprodukter.Når valideringsprocessen implementeres, overvåges den og kontrolleres.
Standardiser en bestemt proces ved at etablere politikker på organisatorisk niveau til planlægning og udførelse af anmeldelser.Lav lektioner, og indsaml forbedringsoplysninger. Institutionaliser en bestemt proces.

IEEE 1012:

Målene med disse testaktiviteter er:

  • Gør det lettere at opdage og korrigere fejl.
  • Tilskynder til og forbedrer ledelsesintervention i proces- og produktrisici.
  • Tilbyder understøttende foranstaltninger til softwareprocessen for at forbedre overholdelsen af ​​tidsplan og budgetkrav.

Hvornår skal man bruge Validate and Verify?

Dette er uafhængige procedurer, der skal anvendes sammen for at kontrollere, om systemet eller applikationen er i overensstemmelse med kravene og specifikationerne, og at det opnår det tilsigtede formål. Begge er vigtige komponenter i kvalitetsstyringssystemet.

Det er ofte muligt, at et produkt gennemgår verifikationen, men mislykkes i valideringsfasen. Da det opfyldte de dokumenterede krav og specifikationer, var disse specifikationer imidlertid i sig selv ude af stand til at imødekomme brugerens behov. Derfor er det vigtigt at udføre test for begge typer for at sikre den overordnede kvalitet.

Verifikation kan bruges som en intern proces i udvikling, opskalering eller produktion. På den anden side bør validering bruges som en ekstern proces for at få accept af egnethed hos interessenter.

Er UAT-validering eller verifikation?

UAT (User Acceptance Testing) skal betragtes som validering. Det er den virkelige verdens validering af systemet eller applikationen, som udføres af de faktiske brugere, der validerer, hvis systemet er “egnet til brug”.

Konklusion

V&V processer bestemmer, om produkterne fra en given aktivitet overholder kravene og er egnede til dens anvendelse.

Endelig er følgende et par ting at bemærke:

  1. I meget enklere vendinger (for at undgå enhver form for forvirring), husker vi bare, at Verifikation betyder gennemgangsaktiviteter eller statiske testteknikker, og validering betyder de faktiske testudførelsesaktiviteter eller dynamiske testteknikker.
  2. Bekræftelse involverer måske ikke selve produktet. Validering har bestemt brug for produktet. Bekræftelse kan undertiden udføres på de dokumenter, der repræsenterer det endelige system.
  3. Verifikation og validering behøver ikke nødvendigvis udføres af testerne. Som du ser ovenfor i denne artikel udføres nogle af disse af udviklerne og andre hold.

Dette er alt hvad du behøver at vide om verifikation og validering for at være SMV'er (fageksperter) om emnet.

Anbefalet læsning

^