Meny

Kontekstdrevet testing: 7 grunnleggende prinsipper med et eksempel

context driven testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

7 grunnleggende prinsipper for kontekstdrevet testing med et eksempel:

kravsporbarhetsmatrismal med eksempel

Når jeg kjører til flyplassen, tar jeg vanligvis motorveien som vil få meg dit på minimum tid og unngår bompenger. Men den dagen tok jeg en lengre lokal vei med bompenger. Fordi jeg ønsket meg noen ekstra minutter med vennen min på stasjonen, som reiste veldig langt for å tilbringe helgen med familien vår. Det normale verste valget, i dette tilfellet, viste seg å være det beste.

Men vurder dette.

Hva om jeg hadde lite bensin?

Hva om jeg hadde lite kontanter?

Jeg ville valgt det andre alternativet. Hvorfor? Sammenhengen.

Hva er kontekststyrt testing

(bilde kreditt )

Når du tar avgjørelser basert på, er det følgende en kontekstdrevet beslutning:

  • De involverte menneskene
  • Omstendigheter
  • Mål
  • Tilgjengelige alternativer
  • Følelser osv.

Så, hva er kontekststyrt testing?

Context Driven Testing er et tankegangskifte (eller School of testing) utviklet av Cem Kaner, James Bach og Bret Pettichord. Detaljer om det finner du i deres berømte bok: Leksjoner i programvaretesting .

Det er 7 grunnleggende prinsipper. Følgende er direkte plukket fra boken deres:

#1) Verdien av enhver praksis avhenger av konteksten.

#to) Det er god praksis i sammenheng, men det er ingen beste praksis.

# 3) Mennesker, som jobber sammen, er den viktigste delen av prosjektets sammenheng.

# 4) Prosjekter utfolder seg over tid på måter som ofte ikke er forutsigbare.

# 5) Produktet er en løsning. Hvis problemet ikke er løst, fungerer ikke produktet.

# 6) God programvaretesting er en utfordrende intellektuell prosess.

# 7) Bare gjennom dømmekraft og dyktighet, utøvd i samarbeid gjennom hele prosjektet, er vi i stand til å gjøre de riktige tingene til rett tid for effektivt å teste produktene våre.

Jeg kommer ikke til å forklare hver enkelt av dem fordi det gjøres for oss av eksperter her .

Jeg skal rett og slett gjøre en scenariobasert forklaring på mitt syn på kontekststyrt testing.

Et eksempel på kontekstdrevet testing:

La oss si at jeg starter et testprosjekt - Prosjekt A som inkluderer end-to-end testing for et nettbasert program.

Hva ville være min strategi?

I henhold til standardprosessene vil dette være rekkefølgen av hendelser:

  • Samle krav og forstå applikasjonen
  • Lag en testplan
  • Lag testdokumentasjon - Testscenarier, testtilfeller, sporbarhetsmatrise, etc.
  • Få all dokumentasjonen gjennomgått og godkjent
  • Sett opp QA-miljø og testdata
  • Utfør testutførelse
  • Lag feilrapporter
  • Generer og del testrapporter, etc.

Hvis jeg stiller meg selv spørsmålet: 'Hvordan bestemte jeg meg for at dette er hva jeg trenger å gjøre?' Svaret mitt vil være, best practices, QA-standarder, retningslinjer for bransjen, tidligere erfaringsgrunnlag, etc., ikke sant?

Jeg gjentar det jeg fikk lære eller hva jeg har sett andre gjøre.

Er det noe galt med det? Ikke i det hele tatt. Dette kan til og med fungere også fordi det er en viss følelse av repeterbarhet og tidsprøvdhet i denne tilnærmingen. Imidlertid baner det vei for optimale resultater?

qa testing intervju spørsmål for erfarne

Tvilsom. Hvorfor?

For med hvert prosjekt skal du håndtere forskjellige omstendigheter:

  • Dokumenterte vs. udokumenterte krav
  • Tett arbeid mot geografisk distribuerte team
  • Utviklings- og testteam som tilhører samme selskap vs. konkurranse
  • Tilstrekkelig tid vs. Tette tidsplaner
  • Sammensetningen av teamet ditt - Nykommere vs erfarne. Opplært mot utrente.
  • Tilgjengelighet av verktøy - Manuell vs. bruk av verktøy for testadministrasjon
  • Type prosjekt - Trenger streng overholdelse av regler (FDA eller bank) kontra eksperimentelle (som sosiale medier)
  • Prosjektets teknologi.For eksempel:du ville ikke teste nettet og en Windows-app på samme måte
  • Krav til klientene (Noen vil ha daglige detaljerte rapporter, andre vil bare ha høydepunktene)
  • Prosessen fulgte (smidig vs. tradisjonell, skript vs. utforskende testing)

Denne listen er ikke uttømmende, og du vet like godt som jeg at det er mange variabler til hvert prosjekt.

Kontekstdrevet testing er når du lar disse omstendighetene bestemme testpraksiser, teknikker og til og med definisjoner i stedet for standard, bransjeoppfattet ‘ beste praksis' .

La oss si at dette er detaljene jeg jobber med for prosjekt A:

  • Jeg jobber med et team på 5-4 nykommere og en erfaren tester.
  • Jeg har ingen dokumenterte krav.
  • Teamet mitt er i India og utviklingsteamet er i USA, så vi jobber motsatte tidssoner.
  • Kunden ønsker en daglig detaljert statusrapport
  • Vi bruker et nettbasert feilsporingsverktøy, for eksempel Mantis eller Bugzilla, og det er alt vi har.
  • Jeg må gjøre to testerunder på 10 dager med 3 dager for testdokumentasjon

Her er en grov spillplan:

1) Siden mange nykommere er i teamet, trenger vi mange fagfellevurderinger.

to) Vi trenger også minst 2 kravdiskusjonsmøter med BA og Dev team. Dette må være formelt fordi lagene ligger andre steder, og det er lite rom for meg å gå opp til dem med spørsmål.

3) Det er en aggressiv testtidslinje for dokumentasjon. Jo mer dokumentasjon vi skriver, jo flere anmeldelser trenger vi, noe som tilsvarer mer tid. Så vi må beholde minimumsdokumentasjon. Vi skal dokumentere bare det viktigste End-to-End TC-er og resten blir det testet utforskende .

4) Daglige statusrapporter under testutførelse skal opprettes og sendes EOD hver dag.

5) De fleste testene er utforskende, så råd tid til å prøve å lage en kort oversikt over hver test som utføres. På denne måten vet vi hva som er testet og hva som ikke er.

6) Mangler vil bli rapportert i sanntid til Mantis. Siden teamet jobber i en annen tidssone, må de kanskje vente en hel dag før de hører fra QA-teamet, i tilfelle de trenger en avklaring. Sett derfor opp en hverdagssamtale på et praktisk team, der QA-teamet vil demonstrere rekreasjon av feil. På den måten vil det ikke være behov for å vente eller følge opp.

Og så videre.

Når du har en overordnet strategi, skriver du en grunnleggende testplan som forklarer disse punktene. Nå er du klar til å komme inn i et testprosjekt etter nøye vurdering og skreddersydd en strategi for suksess.

Oppsummert:

Dette er Kontekststyrt testing; gjør omstendighetene dine (ikke standardene) til de viktigste inngangene og påvirkerne for teststrategien din. Det oppfordrer oss til å se oss om og ta hensyn til alt rundt deg.

Personlig er jeg forelsket i dette konseptet fordi testpraksis for ofte oppfattes som stiv og imitasjonsbasert. Noen gjorde det og var vellykket, så jeg kommer til å gjøre det også. Dette er den typen bilde som skremmer folk fra å prøve og bli i en testkarriere.

Men det er rikelig med rom for kreativ tenkning, analytiske ferdigheter og beslutningstaking. For å vite mer, les opp emnet i lenkene gitt ovenfor.

Glad kontekstdrevet testing

Anbefalt lesing

^