context driven testing
7 osnovnih principa kontekstualnog testiranja s primjerom:
što je stringstream u c ++
Kad se vozim do zračne luke, obično idem autocestom koja će me odvesti za minimalno vrijeme i izbjegavam cestarine. Ali toga dana krenuo sam dužom lokalnom cestovnom rutom s naplatom cestarine. Jer želio sam nekoliko dodatnih minuta s mojim prijateljem u vožnji, koji je putovao vrlo dugo kako bi vikend proveo s našom obitelji. U ovom se slučaju pokazalo da je normalan najgori izbor najbolji.
Ali, razmislite o ovome.
Što ako bih imao malo goriva?
Što ako bih imao malo novca?
Ja bih izabrao drugu opciju. Zašto? Kontekst.
[slika Kreditna ]
Kada donosite odluke na temelju, sljedeća je odluka zasnovana na kontekstu:
- Uključeni ljudi
- Okolnosti
- Ciljevi
- Dostupne opcije
- Emocije itd.
Pa, što je kontekstualno testiranje?
Testiranje vođeno kontekstom promjena je načina razmišljanja (ili Škola testiranja) koju su razvili Cem Kaner, James Bach i Bret Pettichord. Pojedinosti o tome mogu se naći u njihovoj poznatoj knjizi: Lekcije naučene iz testiranja softvera .
Postoji 7 osnovnih principa. Sljedeće su izravno odabrane iz njihove knjige:
# 1) Vrijednost svake prakse ovisi o njezinom kontekstu.
#dva) U kontekstu postoje dobre prakse, ali nema najboljih praksi.
# 3) Ljudi, koji rade zajedno, najvažniji su dio konteksta bilo kojeg projekta.
# 4) Projekti se vremenom odvijaju na načine koji često nisu predvidljivi.
# 5) Proizvod je rješenje. Ako problem nije riješen, proizvod ne radi.
# 6) Dobro testiranje softvera izazovni je intelektualni proces.
# 7) Samo prosuđivanjem i vještinom, zajednički provedeni tijekom cijelog projekta, u mogućnosti smo učiniti prave stvari u pravo vrijeme kako bismo učinkovito testirali svoje proizvode.
Neću objašnjavati svakog od njih, jer to za nas čini sami stručnjaci ovdje .
Jednostavno ću iznijeti objašnjenje temeljeno na scenariju o svom pristupu testiranju na temelju konteksta.
Primjer kontekstualnog ispitivanja:
Recimo da započinjem projekt testiranja - projekt A koji uključuje cjelovito testiranje za web-aplikaciju.
Koja bi bila moja strategija?
Prema standardnim postupcima, to će biti slijed događaja:
- Prikupite zahtjeve i razumite aplikaciju
- Stvorite plan ispitivanja
- Stvaranje testne dokumentacije - scenariji testiranja, test slučajevi, matrica sljedivosti itd.
- Neka sva dokumentacija bude pregledana i odobrena
- Postavite QA okruženje i test podatke
- Izvršite test izvršavanje
- Stvorite izvješća o greškama
- Generirajte i dijelite izvješća o stanju izvršenja testa itd.
Ako si postavim pitanje: 'Kako sam zaključio da je to ono što moram raditi?' Moj bi odgovor bio, najbolja praksa, QA standardi, smjernice u industriji, osnovne postavke iz prethodnog iskustva itd., Zar ne?
Ponavljam ono što sam naučen raditi ili ono što sam vidio da drugi rade.
Sad, je li nešto loše u tome? Nikako. To bi čak moglo uspjeti i jer postoji određeni osjećaj ponovljivosti i vremenske provjere ovog pristupa. Međutim, otvara li put optimalnim rezultatima?
Sumnjivo. Zašto?
Jer sa svakim projektom suočit ćete se s različitim okolnostima:
- Dokumentirani i nedokumentirani zahtjevi
- Usko radeći u odnosu na zemljopisno raspoređene timove
- Timovi za razvoj i testiranje koji pripadaju istoj tvrtki u odnosu na konkurenciju
- Dovoljno vremena vs. Zbijeni rasporedi
- Sastav vašeg tima - Novopridošli protiv iskusnih. Obučeni naspram neobučenih.
- Dostupnost alata - Priručnik u odnosu na upotrebu alata za upravljanje testom
- Vrsta projekta - Potrebno je strogo poštivanje pravila (FDA ili bankarstvo) naspram eksperimentalnih (poput društvenih medija)
- Tehnologija projekta.Na primjer:ne biste testirali web i Windows aplikaciju na isti način
- Zahtjevi klijenata (Neki žele dnevna detaljna izvješća, neki žele samo najvažnije dijelove)
- Slijedio je postupak (agilno naspram tradicionalnog, skriptirano nasuprot istraživačkom testiranju)
Ovaj popis nije iscrpan i znate kao i ja da postoji mnogo varijabli za svaki projekt.
Kontekstualno testiranje je kada dopustite da ove okolnosti odluče o vašim testnim praksama, tehnikama, pa čak i definicijama, a ne o standardnim, industrijskim shvaćanjima najbolje prakse' .
Recimo da su ovo detalji s kojima radim na projektu A:
- Radim s timom od 5- 4 novajlije i 1 iskusnim testerom.
- Nemam dokumentirane zahtjeve.
- Moj tim je u Indiji, a razvojni tim u SAD-u, tako da radimo u suprotnim vremenskim zonama.
- Klijent želi dnevno detaljno izvješće o stanju
- Koristimo web alat za praćenje grešaka, kao što su Mantis ili Bugzilla, i to je sve što imamo.
- Moram obaviti 2 kruga testiranja u 10 dana s 3 dana za testiranje dokumentacije
Evo okvirnog plana igre:
1) Budući da je u timu puno novaka, trebamo puno recenzija.
2) Također su nam potrebna najmanje 2 sastanka za raspravu o zahtjevima s BA i Dev timom. To mora biti formalno, jer su timovi smješteni drugdje i malo mi je prostora da im priđem s pitanjima.
3) To je agresivan vremenski okvir za testiranje dokumentacije. Što više dokumentacije napišemo, to će nam trebati više recenzija, što odgovara više vremena. Dakle, morat ćemo voditi minimalnu dokumentaciju. Dokumentirat ćemo samo glavno TC-ovi s kraja na kraj a ostalo će biti ispitivano istraživačkim putem .
4) Svakodnevno će se stvarati i slati EOD svakodnevna izvješća o stanju tijekom izvođenja testa.
5) Većina testiranja je istraživačka, pa savjetujte vrijeme da pokušate napraviti kratki pregled svakog izvedenog testa. Na taj način znamo što se testira, a što ne.
6) O nedostacima će se u stvarnom vremenu prijavljivati Mantis. Budući da tim radi u drugoj vremenskoj zoni, možda će morati pričekati cijeli dan prije nego što se čuju s QA timom, u slučaju da im treba pojašnjenje. Stoga, uspostavite svakodnevni poziv prikladnom timu, gdje će QA tim demonstrirati rekreaciju bugova. Na taj način neće biti potrebe za čekanjem ili praćenjem.
I tako dalje.
Nakon što napravite opću strategiju, napišite osnovni plan ispitivanja koji objašnjava ove točke. Sada ste spremni za ulazak u projekt testiranja nakon pažljivog razmatranja i prilagođene strategije uspjeha.
U sažetku:
Ovo je Testiranje na temelju konteksta; čineći svoje okolnosti (a ne standarde) primarnim inputima i utjecajima za svoju test strategiju. Poziva nas da se osvrnemo i uzmemo u obzir sve oko sebe.
Osobno sam zaljubljen u ovaj koncept jer se prečesto prakse testiranja percipiraju kao krute i temelje se na imitaciji. Netko je to učinio i bio uspješno, pa ću i ja to učiniti. Ovo je vrsta slike koja plaši ljude da pokušaju i ostanu u testnoj karijeri.
popis špijunskih aplikacija za android
No, dovoljno je prostora za kreativno razmišljanje, analitičke vještine i donošenje odluka. Da biste saznali više, pročitajte temu na gore navedenim vezama.
Sretno testiranje vođeno kontekstom
Preporučena literatura
- Najbolji alati za testiranje softvera 2021. [Alati za automatizaciju ispitivanja kvalitete]
- Preuzimanje e-knjige za testiranje primera
- 20 jednostavnih pitanja za provjeru softverskog testiranja osnovnog znanja [mrežni kviz]
- 7 osnovnih savjeta za testiranje višejezičnih web stranica
- Ispitivanje opterećenja pomoću HP LoadRunner vodiča
- Razlika između testiranja radne površine, klijentskog poslužitelja i web testiranja
- Što je gama testiranje? Završna faza ispitivanja
- Što je ispitivanje sukladnosti (ispitivanje sukladnosti)?