context driven testing
7 osnovnih načel kontekstualnega testiranja s primerom:
razlika med enotnim in integracijskim testom
Ko se vozim na letališče, navadno zapeljem na avtocesto, ki me pripelje v najkrajšem možnem času in se izogne cestninam. Toda tisti dan sem se s cestnino podal po daljši lokalni cesti. Ker sem si želel nekaj dodatnih minut s prijateljem v vožnji, ki je potoval zelo dolgo, da bi vikend preživel z našo družino. Običajno najslabša izbira se je v tem primeru izkazala za najboljšo.
Ampak, razmislite o tem.
Kaj če bi mi zmanjkalo plina?
Kaj če bi mi primanjkovalo gotovine?
Izbral bi drugačno možnost. Zakaj? Kontekst.
(slika kredit )
Ko se odločite na podlagi, je to odvisno od konteksta:
- Vpleteni ljudje
- Okoliščine
- Cilji
- Razpoložljive možnosti
- Čustva itd.
Torej, kaj je kontekstno usmerjeno testiranje?
Testiranje, ki temelji na kontekstu, je premik miselnosti (ali šola testiranja), ki so ga razvili Cem Kaner, James Bach in Bret Pettichord. Podrobnosti o tem najdete v njihovi slavni knjigi: Izkušnje pri preizkušanju programske opreme .
Obstaja 7 osnovnih načel. Iz njihove knjige neposredno izberemo naslednje:
# 1) Vrednost vsake prakse je odvisna od njenega konteksta.
#two) V kontekstu obstajajo dobre prakse, najboljših praks pa ni.
# 3) Ljudje, ki delajo skupaj, so najpomembnejši del konteksta katerega koli projekta.
# 4) Projekti se sčasoma odvijajo na načine, ki pogosto niso predvidljivi.
# 5) Izdelek je rešitev. Če težava ni rešena, izdelek ne deluje.
# 6) Dobro testiranje programske opreme je zahteven intelektualni proces.
# 7) Le s presojo in spretnostmi, ki se izvajajo skupaj v celotnem projektu, lahko naredimo prave stvari ob pravem času, da učinkovito preizkusimo svoje izdelke.
Ne bom razlagal vsakega od njih, ker to za nas naredi strokovnjaki tukaj .
Preprosto bom naredil razlago, ki temelji na scenariju, o mojem preizkusu na podlagi konteksta.
Primer kontekstualnega preizkušanja:
Recimo, da začenjam testni projekt - projekt A, ki vključuje celovito testiranje za spletno aplikacijo.
Kakšna bi bila moja strategija?
spletno mesto, ki vam omogoča prenos YouTube video posnetkov
V skladu s standardnimi postopki bo to zaporedje dogodkov:
- Zberite zahteve in razumite aplikacijo
- Ustvarite testni načrt
- Ustvarite testno dokumentacijo - testni scenariji, testni primeri, matrika sledljivosti itd.
- Vsa dokumentacija naj bo pregledana in odobrena
- Nastavite QA okolje in preskusne podatke
- Izvedite preizkus
- Ustvarite poročila o napakah
- Ustvarite in delite poročila o stanju izvajanja preizkusov itd.
Če si zastavim vprašanje: 'Kako sem se odločil, da to moram početi?' Moj odgovor bi bil najboljša praksa, standardi za zagotavljanje kakovosti, industrijske smernice, izhodiščne izkušnje iz preteklosti itd., Kajne?
Ponavljam tisto, česar sem se učil ali kaj sem videl, kako delajo drugi.
Ali je s tem kaj narobe? Sploh ne. Tudi to bi lahko delovalo, ker obstaja določen občutek ponovljivosti in časovne preizkušenosti tega pristopa. Vendar pa utira pot optimalnim rezultatom?
Dvomljivo. Zakaj?
Ker se boste pri vsakem projektu spopadali z različnimi okoliščinami:
- Dokumentirane in nedokumentirane zahteve
- Tesno delujoče in geografsko porazdeljene ekipe
- Razvojne in preizkusne ekipe istega podjetja v primerjavi s konkurenco
- Zadosten čas vs. Tesni urniki
- Sestava vaše ekipe - Novinci v primerjavi z izkušenimi. Usposobljeni proti neizučeni.
- Razpoložljivost orodij - Priročnik v primerjavi z uporabo orodij za upravljanje preskusov
- Vrsta projekta - Potrebno je dosledno upoštevanje pravil (FDA ali bančništvo) v primerjavi z eksperimentalnimi (kot so družbeni mediji)
- Tehnologija projekta.Na primer:ne bi testirali spleta in aplikacije za Windows na enak način
- Zahteve strank (nekateri želijo vsakodnevna podrobna poročila, nekateri želijo le najpomembnejše točke)
- Sledil je postopek (agilno v primerjavi s tradicionalnim, scenaristično ali raziskovalno testiranje)
Ta seznam ni izčrpen in tudi vi veste, da je za vsak projekt veliko spremenljivk.
Kontekstno usmerjeno preskušanje je, ko pustite, da te okoliščine odločajo o vaših preizkusnih praksah, tehnikah in celo definicijah, ne pa o standardnih, v industriji zaznanih „ Najboljše prakse' .
Zdaj, recimo, to so podrobnosti, s katerimi sodelujem pri projektu A:
- Sodelujem z ekipo 5-4 novincev in 1 izkušenega preizkuševalca.
- Nimam dokumentiranih zahtev.
- Moja ekipa je v Indiji, razvojna ekipa pa v ZDA, zato delamo v nasprotnih časovnih pasovih.
- Naročnik želi dnevno podrobno poročilo o stanju
- Uporabljamo spletno orodje za sledenje napakam, kot sta Mantis ali Bugzilla, in to je vse, kar imamo.
- V 10 dneh moram opraviti dva kroga testiranja s 3 dnevi za testno dokumentacijo
Tu je okvirni načrt igre:
1) Ker je v ekipi veliko novincev, potrebujemo veliko medsebojnih pregledov.
dva) Potrebujemo tudi vsaj dva pogovorov z razpravami s BA in Dev team. To mora biti formalno, ker se ekipe nahajajo drugje in imam malo možnosti, da bi stopil do njih z vprašanji.
3) Gre za agresiven časovni okvir za testiranje dokumentacije. Več dokumentacije pišemo, več pregledov potrebujemo, kar pomeni več časa. Torej, morali bomo hraniti minimalno dokumentacijo. Dokumentirali bomo samo glavno Končni TC-ji in ostali bodo preizkušeno raziskovalno .
4) Dnevna poročila o stanju med izvajanjem preizkusa bodo ustvarjena in vsak dan poslana EOD.
5) Večina testiranj je raziskovalnih, zato svetujte čas, da poskusite na kratko opisati vsak izveden test. Tako vemo, kaj je preizkušeno in kaj ne.
6) O napakah se bo v Mantisu poročalo sproti. Ker ekipa dela v drugem časovnem pasu, bo morda morala počakati cel dan, preden se bo oglasila, če bodo potrebovali pojasnilo. Zato vzpostavite vsakdanji klic pri priročni ekipi, kjer bo ekipa za zagotavljanje kakovosti predstavila rekreacijo napak. Tako ne bo treba čakati ali nadaljevati.
In tako naprej.
Ko imate splošno strategijo, napišite osnovni testni načrt, ki bo pojasnil te točke. Zdaj ste pripravljeni, da se po natančnem premisleku in izdelani strategiji za uspeh vključite v testni projekt.
V povzetku:
To je Testiranje na podlagi konteksta; da bodo vaše okoliščine (ne standardi) glavni vložki in vplivne osebe za vašo testno strategijo. Poziva nas, da se ozremo in upoštevamo vse okoli sebe.
Osebno sem zaljubljen v ta koncept, ker prepogosto prakse preizkušanja dojemamo kot toge in na imitaciji. Nekdo je to storil in bil je uspešno, zato bom to storil tudi jaz. To je podoba, ki ljudi prestraši, da bi poskusili in ostali v preizkusni karieri.
Toda prostora za kreativno razmišljanje, analitične sposobnosti in odločanje je veliko. Če želite izvedeti več, preberite temo na zgornjih povezavah.
Srečno preizkušanje na podlagi konteksta
Priporočeno branje
- Najboljša orodja za testiranje programske opreme 2021 (QA Test Automation Tools)
- Prenos eBook knjige za preizkušanje
- 20 preprostih vprašanj za preverjanje programske opreme za preizkušanje osnovnega znanja (spletni kviz)
- 7 osnovnih nasvetov za testiranje večjezičnih spletnih strani
- Testiranje obremenitve z vadnicami HP LoadRunner
- Razlika med testiranjem namizja, odjemalskega strežnika in spletnim preskušanjem
- Kaj je testiranje gama? Zaključni preizkusni oder
- Kaj je preizkušanje skladnosti (preizkus skladnosti)?