Meny

Nøyaktig forskjell mellom bekreftelse og validering med eksempler

  • Hoved
  • Annen
  • Nøyaktig forskjell mellom bekreftelse og validering med eksempler

exact difference between verification

Prøv Instrumentet Vårt For Å Eliminere Problemer

Verifisering vs validering: Utforsk forskjellene med eksempler

Det er tilbake til det grunnleggende folkens! Et klassisk blikk på forskjellen mellom Verifisering og validering .

Det er mye forvirring og debatt rundt disse begrepene i testverdenen for programvare.

I denne artikkelen vil vi se hva bekreftelse og validering er fra synspunktet for programvaretesting. Ved slutten av denne artikkelen vil vi få forskjellen mellom de to begrepene.

Forskjellen mellom bekreftelse og validering

Følgende er noen av de viktigste grunnene til å forstå forskjellen:

  1. Det er et grunnleggende QA-konsept, derfor er det nesten byggesteinen for å være QA-kjent.
  2. Dette er en vanlig spørsmål Programvare Testing Intervju Spørsmål .
  3. Sertifisering pensum har en god del kapitler som dreier seg om dette.
  4. Til slutt, og praktisk talt når vi testere utfører begge disse testtypene, kan vi like godt være eksperter på dette.

Hva du vil lære:

Hva er bekreftelse og validering i programvaretesting?

I sammenheng med testing, “ Verifisering og validering ”Er de to mest brukte begrepene. Som oftest anser vi begge begrepene som de samme, men faktisk er disse begrepene ganske forskjellige.

Det er to aspekter av V&V (Verification & Validation) -oppgaver:

  • Bekrefter kravene (produsentens syn på kvalitet)
  • Passer til bruk (forbrukernes kvalitetssyn)

Produsentens syn på kvalitet , i enklere termer, betyr utviklernes oppfatning av det endelige produktet.
Forbrukerne ser på kvalitet betyr brukerens oppfatning av det endelige produktet.

Når vi utfører V & V-oppgavene, må vi konsentrere oss om begge disse synspunktene på kvalitet.

La oss først begynne med definisjonene av verifisering og validering, og deretter vil vi forstå disse begrepene med eksempler.

Merk: Disse definisjonene er, som nevnt i QAIs CSTE CBOK (sjekk ut denne lenken for å vite mer om CSTE).

Hva er bekreftelse?

Verifisering er prosessen med å evaluere de mellomliggende arbeidsproduktene i en livssyklus for programvareutvikling for å sjekke om vi er i rett spor for å lage det endelige produktet.

Med andre ord kan vi også si at verifisering er en prosess for å evaluere meglerproduktene til programvare for å sjekke om produktene tilfredsstiller vilkårene som ble pålagt i begynnelsen av fasen.

Nå er spørsmålet her: Hva er mellomledd eller meklerprodukter?

Vel, disse kan inkludere dokumentene som er produsert i utviklingsfasene, som kravspesifikasjon, designdokumenter, databasetabelldesign, ER-diagrammer, testtilfeller, sporbarhetsmatrise , etc.

Noen ganger pleier vi å neglisjere viktigheten av å gjennomgå disse dokumentene, men vi bør forstå at gjennomgang av seg selv kan finne ut av mange skjulte uregelmessigheter når det kan bli veldig kostbart hvis det blir funnet eller løst i den senere fasen av utviklingssyklusen.

Verifisering sikrer at systemet (programvare, maskinvare, dokumentasjon og personell) overholder organisasjonens standarder og prosesser, avhengig av gjennomgang eller ikke-kjørbare metoder.

Hvor utføres bekreftelse?

Spesifikt for IT-prosjekter, følgende er noen av områdene (jeg må understreke at dette ikke er alt) der verifisering utføres.

BekreftelsessituasjonSkuespillereDefinisjonProduksjon
Testdokumentasjon gjennomgang (Peer review)QA-teammedlemmerEn fagfellevurdering er der teammedlemmene gjennomgår hverandres arbeid for å sikre at det ikke er noen feil i selve dokumentasjonen.Testdokumentasjon klar til å deles med de eksterne teamene.
Forretnings- / funksjonskravgjennomgangUtvikler / klient for forretningsbehov.Dette er et nødvendig skritt for å ikke bare sørge for at kravene er samlet og / eller riktig, men også for å sikre om de er gjennomførbare eller ikke.Avsluttede krav som er klare til å bli konsumert av neste trinn - design.
Design anmeldelseDev teamEtter designopprettingen vurderer Dev-teamet det grundig for å sikre at funksjonskravene kan oppfylles via den foreslåtte designen.Design er klar til å implementeres i et IT-system.
Code WalkthroughIndividuell utviklerKoden en gang skrevet blir gjennomgått for å identifisere eventuelle syntaktiske feil. Dette er mer uformelt og utføres av den enkelte utvikler på koden utviklet av seg selv.Kode klar for enhetstesting.
KodeinspeksjonDev teamDette er et mer formelt oppsett. Fageksperter og utviklere sjekker koden for å sikre at den er i samsvar med forretnings- og funksjonelle mål som programvaren retter seg mot.Kode klar for testing.
Testplangjennomgang (internt for QA-teamet)QA teamEn testplan gjennomgås internt av QA-teamet for å sikre at den er nøyaktig og fullstendig.Et testplandokument klar til å deles med de eksterne teamene (prosjektledelse, forretningsanalyse, utvikling, miljø, klient, etc.)
Testplangjennomgang (ekstern)Prosjektleder, forretningsanalytiker og utvikler.En formell analyse av testplandokumentet for å sikre at tidslinjen og andre hensyn til QA-teamet er i tråd med de andre teamene og hele selve prosjektet.Et avskrevet eller godkjent testplandokument basert på hvilken testaktiviteten skal baseres på.
Testdokumentasjon endelig gjennomgangForretningsanalytiker og utviklingsteam.En testdokumentasjonsgjennomgang for å sikre at testtilfellene dekker alle forretningsforholdene og funksjonelle elementene i systemet.Testdokumentasjon klar til å utføres.

Se testdokumentasjonsgjennomgang artikkel som legger ut en detaljert prosess om hvordan testere kan utføre gjennomgangen.

Hva er validering?

Validering er prosessen med å evaluere det endelige produktet for å sjekke om programvaren oppfyller forretningsbehovet. Med enkle ord er testutførelsen vi gjør i vårt daglige liv faktisk valideringsaktiviteten som inkluderer røykprøving , funksjonstesting, regresjonstesting, systemtesting osv.

Validering er alle former for testing som innebærer å jobbe med produktet og sette det på prøve.

Nedenfor er valideringsteknikkene:

Validering sikrer fysisk at systemet fungerer i henhold til en plan ved å utføre systemfunksjonene gjennom en serie tester som kan observeres og evalueres.

Greit nok, ikke sant? Her kommer mine to-cent:

Når jeg prøver å takle dette V & V-konseptet i klassen min, er det mye forvirring rundt det. Et enkelt, lite eksempel ser ut til å løse all forvirringen. Det er litt dumt, men fungerer virkelig.

Validerings- og verifikasjonseksempler

Eksempel på virkeligheten :Tenk deg å gå til en restaurant / spisestue og bestille kanskje blåbærpannekaker. Når servitøren / servitrisen bringer bestillingen ut, hvordan kan du fortelle at maten som kom ut er i henhold til bestillingen din?

De første tingene er at vi ser på det og legger merke til følgende ting:

test tilfeller for webapplikasjon i manuell testing
  • Ser maten ut som pannekaker vanligvis ser ut til å være?
  • Skal blåbærene sees?
  • Lukter de riktig?

Kanskje mer, men du forstår kjernen?

På den annen side, når du trenger å være helt sikker på om maten er som du forventet: Du må spise den.

Bekreftelse er alt når du ennå ikke skal spise, men sjekker på noen få ting ved å gjennomgå emnene. Validering er når du faktisk spiser produktet for å se om det er riktig.

I denne sammenhengen kan jeg ikke la være å gå tilbake til CSTE CBOK referanse. Det er en fantastisk uttalelse der ute som hjelper oss å bringe dette konseptet hjem.

Verifisering svarer på spørsmålet: 'Bygde vi riktig system?' mens valideringene adresserer: 'Byggte vi systemet riktig?'

V&V i forskjellige faser av utviklingslivssyklusen

Verifisering og validering utføres i hver av fasene i utviklingslivssyklusen.

La oss prøve å se på dem.

# 1) V & V-oppgaver - Planlegger

  • Verifisering av kontrakt.
  • Evaluering av konseptdokument.
  • Utfører risikoanalyse.

# 2) V & V-oppgaver - Kravsfase

  • Evaluering av programvarekrav.
  • Evaluering / analyse av grensesnittene.
  • Generering av systemtestplanen.
  • Generering av godkjenningstestplan.

# 3) V&V oppgaver - Designfase

  • Evaluering av programvaredesign.
  • Evaluering / analyse av grensesnittene (UI).
  • Generering av integrasjonstestplan.
  • Generering av komponenttestplanen.
  • Generering av testdesign.

# 4) V&V oppgaver - Implementeringsfase

  • Evaluering av kildekode.
  • Evaluering av dokumenter.
  • Generering av testsaker.
  • Generering av testprosedyren.
  • Gjennomføring av komponenttestsaker.

# 5) V&V oppgaver - Testfase

  • Gjennomføring av systemtestsak.
  • Gjennomføring av aksepttestsaken.
  • Oppdaterer sporbarhetsberegninger.
  • Risikoanalyse

# 6) V&V oppgaver - Installasjons- og utsjekkingsfase

  • Revisjon av installasjon og konfigurasjon.
  • Den siste testen av installasjonskandidatbygningen.
  • Generering av den endelige testrapporten.

# 7) V&V oppgaver - Driftsfase

  • Evaluering av ny begrensning.
  • Vurdering av den foreslåtte endringen.

# 8) V&V oppgaver - Vedlikeholdsfase

  • Evaluering av avvikene.
  • Vurdering av migrasjon.
  • Vurdering av retrial-funksjonene.
  • Vurdering av den foreslåtte endringen.
  • Validerer produksjonsproblemene.

Forskjellen mellom verifisering og validering

Bekreftelse mot validering

BekreftelseValidering
Evaluerer mellomproduktene for å sjekke om det oppfyller de spesifikke kravene i den spesielle fasen.Evaluerer det endelige produktet for å sjekke om det oppfyller forretningsbehovet.
Sjekker om produktet er bygget i henhold til det spesifiserte kravet og designspesifikasjonen.Den avgjør om programvaren er egnet for bruk og tilfredsstiller forretningsbehovet.
Sjekker “Bygger vi produktet riktig”?Sjekker “Bygger vi riktig produkt”?
Dette gjøres uten å utføre programvaren.Er ferdig med å kjøre programvaren.
Involverer alle statiske testteknikker.Inkluderer alle dynamiske testteknikker.
Eksempler inkluderer anmeldelser, inspeksjon og gjennomgang.Eksempel inkluderer alle typer tester som røyk, regresjon, funksjonell, systemer og UAT.

Ulike standarder

ISO / IEC 12207: 2008

VerifikasjonsaktiviteterValideringsaktiviteter
Kravsverifisering innebærer en gjennomgang av kravene.Forbered testkravsdokumentene, testtilfellene og andre testspesifikasjoner for å analysere testresultatene.
Designverifisering innebærer gjennomgang av alle designdokumentene, inkludert HLD og LDD.Evaluer at disse testkravene, testtilfellene og andre spesifikasjoner gjenspeiler kravene og er egnet for bruk.
Kodeverifisering inkluderer gjennomgang av kode.Test for grenseverdier, stress og funksjonalitet.
Dokumentasjonsbekreftelse er bekreftelse av brukerhåndbøker og andre relaterte dokumenter.Test for feilmeldinger, og i tilfelle feil, avsluttes søknaden. Tester at programvaren oppfyller forretningskravene og er egnet til bruk.

CMMI:

Verifisering og validering er to forskjellige KPAer på modenhetsnivå 3

VerifikasjonsaktiviteterValideringsaktiviteter
Utfører fagfellevurderinger.Kontroller at produktene og komponentene er egnet for miljøet.
Bekreft de valgte arbeidsproduktene.Når valideringsprosessen implementeres, overvåkes den og kontrolleres.
Standardiser en bestemt prosess ved å etablere organisatoriske retningslinjer for planlegging og gjennomgang.Gjør leksjoner og samle forbedringsinformasjon. Institusjonalisere en bestemt prosess.

IEEE 1012:

Målet med disse testaktivitetene er:

  • Tilrettelegger for tidlig oppdagelse og korrigering av feil.
  • Oppmuntrer og forbedrer ledelsesintervensjon i prosess- og produktrisiko.
  • Tilbyr støttende tiltak for programvarens livssyklusprosess, for å forbedre overholdelsen av tidsplan og budsjettkrav.

Når skal du validere og verifisere?

Dette er uavhengige prosedyrer som bør brukes sammen for å kontrollere om systemet eller applikasjonen er i samsvar med kravene og spesifikasjonene, og at det oppnår det tiltenkte formålet. Begge deler er viktige komponenter i kvalitetsstyringssystemet.

Det er ofte mulig at et produkt går gjennom verifiseringen, men mislykkes i valideringsfasen. Da den oppfylte de dokumenterte kravene og spesifikasjonene, var disse spesifikasjonene imidlertid ikke i stand til å imøtekomme brukerens behov. Dermed er det viktig å utføre testing for begge typene for å sikre den generelle kvaliteten.

Verifisering kan brukes som en intern prosess i utvikling, oppskalering eller produksjon. På den annen side bør validering brukes som en ekstern prosess for å få aksept av egnethet hos interessenter.

Er UAT-validering eller bekreftelse?

UAT (User Acceptance Testing) bør betraktes som validering. Det er den virkelige validering av systemet eller applikasjonen, som gjøres av de faktiske brukerne som validerer hvis systemet er 'egnet til bruk'.

Konklusjon

V&V prosesser avgjør om produktene fra en gitt aktivitet oppfyller kravene og er egnet for bruk.

Til slutt er følgende noen ting å merke seg:

  1. I veldig enklere termer (for å unngå enhver form for forvirring), husker vi bare at Verifisering betyr gjennomgangsaktivitetene eller de statiske testteknikkene, og validering betyr de faktiske testutførelsesaktivitetene eller de dynamiske testteknikkene.
  2. Verifisering kan eller ikke involvere selve produktet. Validering trenger definitivt produktet. Bekreftelse kan noen ganger utføres på dokumentene som representerer det endelige systemet.
  3. Verifisering og validering trenger ikke nødvendigvis å utføres av testerne. Som du ser ovenfor i denne artikkelen, blir noen av disse utført av utviklerne og andre team.

Dette er alt du trenger å vite om bekreftelse og validering for å være SMB (fageksperter) om emnet.

Anbefalt lesing

^