Menu

Kontekstdrevet test: 7 grundlæggende principper med et eksempel

context driven testing

Prøv Vores Instrument Til At Fjerne Problemer

7 grundlæggende principper for kontekstdrevet test med et eksempel:

softwaretest genoptager prøver 2 års erfaring

Når jeg kører til lufthavnen, tager jeg normalt motorvejen, der bringer mig der på den minimale tid og undgår vejafgifter. Men den dag tog jeg en længere lokal vejrute med vejafgift. Fordi jeg ville have et par minutter ekstra med min ven på drevet, der rejste meget langt for at tilbringe weekenden med vores familie. Det normale værste valg, i dette tilfælde, viste sig at være det bedste.

Men overvej dette.

Hvad hvis jeg havde lavt gasindhold?

Hvad hvis jeg havde få kontanter?

Jeg ville vælge den anden mulighed. Hvorfor? Konteksten.

Hvad er kontekstdrevet test

(billede kredit )

Når du træffer beslutninger baseret på, er det følgende en kontekstbaseret beslutning:

  • De involverede mennesker
  • Omstændigheder
  • Mål
  • Tilgængelige muligheder
  • Følelser osv.

Så hvad er kontekstdrevet test?

Context Driven Testing er et tankegangskift (eller School of testing) udviklet af Cem Kaner, James Bach & Bret Pettichord. Detaljer om det kan findes i deres berømte bog: Lektioner lært i softwaretest .

Der er 7 grundlæggende principper. Følgende vælges direkte fra deres bog:

# 1) Værdien af ​​enhver praksis afhænger af dens sammenhæng.

#to) Der er god praksis i sammenhæng, men der er ingen bedste praksis.

# 3) Mennesker, der arbejder sammen, er den vigtigste del af ethvert projekts sammenhæng.

# 4) Projekter udfolder sig over tid på måder, der ofte ikke er forudsigelige.

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

# 6) God softwaretest er en udfordrende intellektuel proces.

# 7) Kun gennem dømmekraft og dygtighed, der udøves i samarbejde gennem hele projektet, er vi i stand til at gøre de rigtige ting på de rigtige tidspunkter for effektivt at teste vores produkter.

Jeg vil ikke forklare hver enkelt af dem, fordi det gøres for os af eksperterne her .

Jeg vil simpelthen lave en scenariebaseret forklaring på mit syn på kontekstdrevet test.

Et eksempel på kontekstdrevet test:

Lad os sige, at jeg starter et testprojekt - projekt A, der inkluderer end-to-end test for en webbaseret applikation.

Hvad ville være min strategi?

I henhold til standardprocesserne vil dette være rækkefølgen af ​​begivenheder:

  • Saml krav og forstå applikationen
  • Opret en testplan
  • Opret testdokumentation - Testscenarier, testsager, sporbarhedsmatrix osv.
  • Få al dokumentation gennemgået og godkendt
  • Opsæt QA-miljø og testdata
  • Udfør testudførelse
  • Opret fejlrapporter
  • Generer og del testrapporter mv.

Hvis jeg stiller mig selv spørgsmålet: 'Hvordan besluttede jeg, at dette er hvad jeg skal gøre?' Mit svar ville være, bedste praksis, QA-standarder, brancheretningslinjer, tidligere baselinjer osv., Ikke?

Jeg gentager, hvad jeg lærte at gøre, eller hvad jeg har set andre gøre.

Er der noget galt med det nu? Slet ikke. Dette kunne endda fungere også, fordi der er en vis følelse af repeterbarhed og tidsprøvning af denne tilgang. Dog baner det vejen for optimale resultater?

Tvivlsom. Hvorfor?

Fordi med hvert projekt skal du håndtere forskellige omstændigheder:

  • Dokumenterede vs. udokumenterede krav
  • Arbejder tæt sammen med geografisk distribuerede hold
  • Udviklings- og testteam, der tilhører den samme virksomhed vs. konkurrence
  • Tilstrækkelig tid vs. Stramme tidsplaner
  • Sammensætningen af ​​dit team - Nybegyndere vs. erfarne. Uddannede vs. utrænede.
  • Tilgængelighed af værktøjer - Brug af manuel versus teststyringsværktøj
  • Projektets type - Har brug for nøje overholdelse af regler (FDA eller bank) vs. eksperimentel (som sociale medier)
  • Projektets teknologi.For eksempel:du ville ikke teste internettet og en Windows-app på samme måde
  • Krav fra klienterne (nogle vil have daglige detaljerede rapporter, andre vil kun have højdepunkterne)
  • Processen blev fulgt (Agile vs. traditionel, scriptet vs. sonderende test)

Denne liste er ikke udtømmende, og du ved lige så godt som jeg, at der er mange variabler til hvert projekt.

Kontekstdrevet test er, når du lader disse omstændigheder bestemme din testpraksis, -teknikker og endda definitioner snarere end standard, industri-opfattet ' bedste praksis' .

Lad os sige, at dette er de detaljer, jeg arbejder med for projekt A:

  • Jeg arbejder med et team på 5-4 nykommere og 1 erfaren testere.
  • Jeg har ingen dokumenterede krav.
  • Mit team er i Indien, og udviklingsteamet er i USA, så vi arbejder i modsatte tidszoner.
  • Kunden ønsker en daglig detaljeret statusrapport
  • Vi bruger et webbaseret bug tracking-værktøj, såsom Mantis eller Bugzilla, og det er alt, hvad vi har.
  • Jeg er nødt til at lave 2 testrunder på 10 dage med 3 dage til testdokumentation

Her er en grov spilplan:

1) Da mange nye er i teamet, har vi brug for masser af peer reviews.

to) Vi har også brug for mindst 2 kravsdiskussionsmøder med BA og Dev team. Dette skal være formelt, fordi holdene er placeret et andet sted, og der er lidt plads for mig at gå hen til dem med spørgsmål.

3) Det er en aggressiv testtidslinje til dokumentation. Jo mere dokumentation vi skriver, jo flere anmeldelser har vi brug for, hvilket svarer til mere tid. Så vi bliver nødt til at opbevare minimumsdokumentation. Vi skal dokumentere kun det vigtigste End-to-End TC'er og resten bliver testet udforskende .

4) Daglige statusrapporter under testudførelse oprettes og sendes EOD hver dag.

5) De fleste test er udforskende, så råd tid til at prøve at lave en kort oversigt over hver udført test. På denne måde ved vi, hvad der testes, og hvad der ikke er.

6) Mangler rapporteres i realtid til Mantis. Da teamet arbejder i en anden tidszone, kan det være nødvendigt at vente en hel dag, før de hører fra QA-teamet, hvis de har brug for en afklaring. Opret derfor et hverdagskald til et praktisk team, hvor QA-teamet demonstrerer rekreation af bugs. På den måde vil der ikke være behov for at vente eller følge op.

Og så videre.

Når du har en overordnet strategi, skal du skrive en grundlæggende testplan, der forklarer disse punkter. Nu er du klar til at komme ind i et testprojekt efter nøje overvejelse og skræddersyet en strategi for succes.

oracle pl sql interview spørgsmål til erfarne

Sammenfattende:

Dette er Kontekstdrevet test; gør dine omstændigheder (ikke standarderne) til de primære input og påvirkere for din teststrategi. Det opfordrer os til at se os omkring og tage hensyn til alt omkring dig.

Personligt er jeg forelsket i dette koncept, fordi testpraksis for ofte opfattes som stiv og efterligningsbaseret. Nogen gjorde det og var med succes, så jeg vil også gøre det. Dette er den slags billede, der skræmmer folk fra at prøve og blive i en testkarriere.

Men der er masser af plads til kreativ tænkning, analytiske færdigheder og beslutningstagning. Hvis du vil vide mere, skal du læse om emnet i linkene ovenfor.

Glad kontekst-drevet test

Anbefalet læsning

^