Meni

Praktična primjena ručnog ispitivanja u 7 koraka prije puštanja u rad

7 step practical implementation manual testing before production release

Isprobajte Naš Instrument Za Uklanjanje Problema

U prethodnom postu ove serije o ručnom testiranju pokušao sam baciti što više svjetla na osnove ručnog testiranja.

Ako ste propustili, možete pročitati ovdje .

Nadam se da ste uspješno približili odgovore što ste ih tražili.

U tom slučaju, ne biste li voljeli znati više o praktičnoj provedbi ručnog testiranja, kako se s njim više upoznati i kako u njemu zapravo započeti karijeru?

Ovaj će članak baciti svjetlo na sve ove aspekte.

Provedba ručnog ispitivanja

Počnimo.

Što ćete naučiti:

Ciklus ručnog ispitivanja

Razumjeti Ciklus ručnog ispitivanja ili Životni ciklus testiranja softvera (STLC), prije svega, moramo razumjeti životni ciklus razvoja softvera (SDLC), za koji sam siguran da ga već razumijete.

Ljudi se na njih pozivaju odvojeno, ali nisu sigurni mogu li doista suživjeti. Oni su međusobno čvrsto integrirani. Pa, čak i ovi ciklusi imaju toliko njihovih verzija kreiranih i plutajućih u internetskom prostoru, da se oni uvelike razlikuju o odabranom razvojnom modelu.

Kao i većina svijet ide okretan ovih ću dana svoje stvari pojednostaviti oko Agilea.

7 praktičnih koraka ručnog ispitivanja prije puštanja u rad

Evo me.

Sjetite se da govorim i o SDLC-u i o STLC-u.

# 1) Prikupljanje zahtjeva

Faza okupljanja zahtjeva

Poslovni analitičar (osoba / tim odgovoran za prikupljanje zahtjeva) dokumentira zahtjeve. Oni dokumentiraju zahtjeve, to je vrhunac, možete zadržati fokus samo na tome. Tamo gdje je to dokumentirano, manje je važno.

Ljudi koriste bilo što za dokumentiranje onoga što im odgovara, ali ne ograničavajući se na tradicionalne platforme poput MS word doc, moderne platforme poput Jira / Rally i new age alate poput Trello.

# 2) Diskusija / dijeljenje zahtjeva

Faza rasprave o zahtjevima

Tada bi poslovni analitičar trebao podijeliti dokumentirane zahtjeve s razvojnim timom, timom za testiranje i UX timom (ako je potrebno). To se obično događa na službenom sastanku na kojem se SPOC-ovi (ovisno o cijelom timu ili čitav tim) iz sve tri funkcije susreću i razumiju cijeli zahtjev.

U zdravoj radnoj kulturi zahtjevi se raspravljaju iz svakog kuta i svaki član sastanka može postavljati pitanja i sumnje. Nakon što se odgovore na sva pitanja i izvrši potrebna izmjena zahtjeva, ova se faza može smatrati Gotovom. Opet, ono što nazivamo određenim sastankom / korakom i njegovom dokumentacijom, razlikuje se od tvrtke do tvrtke.

Daljnje čitanje=> Kako pregledati SRS dokument

Nakon što se odgovore na sva pitanja i izvrše potrebne izmjene zahtjeva, ova se faza može smatrati Gotovo .

Opet, ono što nazivamo određenim sastankom / korakom i njegovom dokumentacijom, razlikuje se od tvrtke do tvrtke.

Na primjer, dokumentacija se naziva ili raščlanjuje kao SRS (specifikacija zahtjeva sustava), dokument dokumenta, epizoda, korisnička priča, točka priče (moguće, najmanja jedinica zahtjeva) itd. Na sličnim se linijama ovaj sastanak na kojem se dijeli zahtjev naziva Sastanak o raspravi o zahtjevima, dotjerivanje, sastanak probijanja rupa itd., Nadam se da ste shvatili moju poantu?

Pritiskom na ove terminologije tako da se uvijek sjećate glavne ideje bez obzira na različita imena.

Objavite ovaj sastanak istovremeno se pokreću dva koraka, bez određenog redoslijeda, pogledajte sljedeća dva koraka.

# 3) Dizajniranje

Razvojni tim započinje sa svojim tehničkim projektiranjem čim se raspravlja o zahtjevima i kada nema većih nerešenih pitanja. Ono što se radi u ovoj fazi razlikuje se od tvrtke do tvrtke.

Ova faza može uključivati, ali ne ograničavajući se na sljedeće zadatke:

  • Odlučivanje o razvojnom pristupu
  • Priprema projektnog dokumenta
  • Dizajniranje dijagrama toka
  • Procjena napora
  • Otkrivanje utjecaja ovog novog zahtjeva na bilo koju postojeću funkcionalnost
  • Treba popraviti postojeće podatke itd.

UX tim se također može uključiti u ovu fazu kada dođe do promjene korisničkog sučelja ili ako treba razviti novi zaslon. UX tim pomaže razvojnom timu i ispitnom timu s prototipom korisničkog sučelja za funkcionalnost / značajku u raspravi. To može biti Photoshop dokument, jednostavna slika, PowerPoint prezentacija ili bilo što drugo što će natjerati razvojni tim da shvati kako treba razvijati zaslone.

Bilješka: Idealno bi bilo da su ovi zasloni ili barem njihove skice prikazani u diskusiji o zahtjevima samo da bi pomogli timu da bolje razumije. Označava se izvornim zahtjevom tako da se na njega može uputiti u bilo kojem trenutku.

# 4) Scenarij testa / dizajniranje test slučaja

Scenarij ispitivanja Faza projektiranja

Paralelno s fazom projektiranja, ispitni tim započinje s izradom scenarija ispitivanja i / ili ispitnih slučajeva na temelju raspravljanih zahtjeva. Hoće li se testni scenariji uvijek prvo napisati, a zatim provaliti u test slučajeve, nešto je što opet nije konstantno.

Po mom mišljenju, bez obzira dokumentirate li scenarije testa ili ne, oni su uvijek tu prije ispitnih slučajeva. Testni scenarij je vaša najvažnija točka, oni vas vode dalje u detaljima. Nakon završetka pisanja testnog slučaja, može se podijeliti s razvojnim timom kako bi im se pružila ideja o opsegu testiranja, a također mogu osigurati da razvoj koji se dogodio ili koji zadovoljava pisane testne slučajeve.

Nakon završetka pisanja testnog slučaja, može se podijeliti s razvojnim timom kako bi im se pružila ideja o opsegu testiranja, a također mogu osigurati da razvoj koji se dogodio ili koji zadovoljava pisane testne slučajeve.

Jednom napisani testni slučajevi idealno bi ih pregledao voditelj ili kolega iz više kutova kao što su:

  • Pokrivenost zahtjeva
  • Pravopisna gramatika
  • Standardi za pisanje testnih slučajeva (ništa osim predloška koji slijedi tim / tvrtka)
  • Povratna kompatibilnost
  • Kompatibilnost platforme
  • Reference podataka ispitivanja
  • Vrste ciljanih ispitivanja itd.

Daljnje čitanje=> Pisanje test slučajeva iz SRS dokumenta

U idealnom slučaju, tek nakon pregleda i potrebne izmjene, prosljeđuju se razvojnom timu.

Kad sam rekao ‘jednom kada je pisanje testnog slučaja gotovo’, mislio sam jednom da su ‘svi testni slučajevi napisani na temelju potpunog poznavanja zadanog zahtjeva i mogućih testnih scenarija otkrivenih do tog određenog vremena’. Gotovo je nemoguće imati 100% pokrivenost testnim slučajem u prvom pokretu.

Bit će nedostataka koje ćete pronaći u slučajnim (ali namjeravanim) radnjama, u čisto slučajnim radnjama (testiranje majmuna) i u nekim rijetkim scenarijima. Postoje šanse da ćete propustiti nekoliko od njih. A u neko biste vrijeme mogli propustiti čak i ona osnovna, uostalom, vi ste ljudi. Ali ovdje vas mogu spasiti barem dobar pregled testnih slučajeva i strukturirani način pisanja testnih slučajeva.

Češće nego ne, ispitivač ili tim za testiranje nastavlja dodavati sve više i više slučajeva u postojeći dio dok otkrivaju istinu ili razmišljaju više o zahtjevima.

Pa, do sada neki od vas sigurno sumnjaju u moje znanje o testiranju softvera jer neku riječ (koja je na neki način postala norma u testiranju softvera) još ne koristim. Ispitni plan, zar ne?

Dopustite mi da kažem nešto o ovome. Snažno vjerujem u potrebu za većinom informacija koje su spomenute u Planu ispitivanja, ali dokumentiranje svih na istome mjestu i njihovo apsolutno obavezno nešto je što smatram diskutabilnim.

U svakom slučaju, to je posve zasebna tema za raspravu. Podijeliti informacije o tome 'odgovara svima' je teško, ali dopustite mi da pokušam.

Ili vi, vi sa svojim testnim vodičem ili svojim testnim vodičem pripremate plan ispitivanja ili dokumentirate potrebne informacije na različitim mjestima.

Daljnje čitanje=> Kako napisati dokument plana ispitivanja

Informacije koje bi u ovoj fazi trebalo biti apsolutno zamrznute:

  • Opseg ispitivanja: Zahtjev, unatrag kompatibilnost, platforme, uređaji itd.
  • Osoba / tim koji će testirati
  • Procjena probnog napora
  • Ograničenja: Sve pretpostavke ili unaprijed prihvaćena ograničenja.
  • Ljudi dodatno dokumentiraju kriterije ulaska, kriterije izlaska, rizik itd. Za koje mislim da ih zapravo nije potrebno posebno spominjati, jer bi to prije trebalo biti normalno razumijevanje.
    • Kriteriji za ulazak (Kada započeti testiranje): Rijetki započinju kada postoji testirani dio funkcionalnosti dostupan za testiranje. Rijetki čekaju da se provjeri cijela funkcionalnost. Jednom kada se utvrdi da osnovni protok funkcionira, započinje testiranje.
    • Kriteriji za izlaz (Kada se zaustaviti): Kada nema blokatora, mogu se zaustaviti kritični i glavni (izloženi udarcu) nedostaci u ispitivanju otvorene faze. Ili na sredini, kada postoji previše nedostataka s kojima se testiranje može zaustaviti od strane odgovarajućih dionika.
    • Rizik : Poslovni rizik ili funkcionalni rizik ako se ispitivanje ne dogodi prema dokumentiranom planu.

# 5) Faza razvoja

Faza razvoja softvera

Razvojni tim nakon faze projektiranja započinje stvarnim razvojem i jedinstvenim testiranjem kada i kada završe s razvojem provjerljivih dijelova zahtjeva. Mogu prenositi funkcionalnost za testiranje u komadima kad i kada je implementirana ili mogu proslijediti cijelu funkcionalnost odjednom.

U idealnom scenariju, formalni pregled koda i testiranje bijelog okvira događaju se prije prosljeđivanja razvijene funkcionalnosti za testiranje. idealno bi bilo da se tim za razvoj, pored zahtjeva i projektne dokumentacije, osvrne i na ispitne slučajeve koje je pružio ispitni tim.

# 6) Faza ispitivanja

Kao što je ranije spomenuto, početak ove faze razlikuje se od tvrtke do tvrtke, od ekipe do ekipe.

Tim za testiranje započinje testiranje bilo kada je testiran (nešto što se može neovisno testirati) dio cijelog zahtjeva ili kada je razvijen cijeli zahtjev.

10 najboljih špijunskih aplikacija za android

Dopustite mi da detaljnije analiziram ovu fazu i razgovaram o važnim zadacima:

  • Tester / ispitni tim započinje s krugom testiranja (istraživačko ispitivanje i izvršavanje pisanih test slučajeva) i prijavom nedostataka
  • Razvojni tim ih rješava prema prioritetu.
  • Nova je gradnja (kod) napravljena na okruženju u kojem se događa testiranje
  • Riješene nedostatke tada provjerava ispitivač / ispitni tim i označava kao ispravljene
  • Ovaj se ciklus nastavlja sve dok se ne postignu kriteriji za izlaz.
  • Imajte na umu da su prema potrebi nedostaci također označeni kao Nevaljani, Dvostruki i mogu se kategorizirati kao Poboljšanja.

Još jedna stvar koja se razlikuje od tvrtke do tvrtke je koliko testova treba obaviti. Kao i u nekim slučajevima, prva runda testiranja događa se na malim dijelovima značajke kad su spremni, nakon čega slijedi runda ispitivanja od kraja do kraja u drugom okruženju nakon što se razviju svi zahtjevi. Ali opet, čuo sam i za ljude koji su izveli tri odgovarajuća puna kruga testiranja, a četvrti kao krug zdrave pameti / dima.

Prva agenda iza višestrukih krugova testiranja je testiranje funkcionalnosti u različitim okruženjima, a druga za testiranje od kraja do kraja nakon što se razviju sve točke priče. Krug zdrave pameti obično stekne brzo samopouzdanje kad se sve priče u izdanju samostalno razviju i testiraju.

Pročitajte detaljne korake=> Faza izvršavanja testa

# 7) Pregled poslovnog analitičara (BA)

Poslovni analitičar pregledava traženu funkcionalnost pozivanjem na rezultat testa ili pozivanjem na rezultat testa plus poigravanje aplikacijom kako bi stekao stvarni osjećaj. Ovaj je korak ponovno podvrgnut različitim akcijama među tvrtkama.

BA može pregledati opseg cijelog izdanja u jednom potezu ili u komadima. Ovisno o istom, ovaj bi korak mogao doći prije konačnog ispitivanja ispravnosti ili nakon završnog kruga ispitivanja ispravnosti od strane ispitnog tima.

Iznad 7 koraka događa se da bi se ispunile sve korisničke priče / zahtjevi, posebno izdanje (isporuka). Nakon što su svi ti koraci dovršeni za sve zahtjeve, izdanje je spremno za otpremu.

# 8) Pošiljka / puštanje

Izdanje je označeno kao Spremno za isporuku nakon uspješnog pregleda poslovnog analitičara.

Preporučeno čitanje=> Proces puštanja u test

Vrste ručnog (čitaj ljudskog) ispitivanja

Pa, ako moramo razgovarati o ukupnim vrstama testiranja u brojkama, negdje sam ih pronašao 100 vrsta ispitivanja s različitim imenima . Da budem iskren, nisam dovoljno pametan da bih razumio razliku između svih tih vrsta (namijenjena igra riječi).

Jednostavno je i jednostavno: Testiranje funkcionalnosti aplikacije prema zadanom zahtjevu uz ljudske napore i inteligenciju. Dalje se dijeli na nekoliko vrsta na temelju opsega i programa ispitivanja. Vrste navedene u sljedećem paragrafu.

Dalje se dijeli na nekoliko vrsta na temelju opsega i programa ispitivanja. Vrste navedene u sljedećem paragrafu.

Ako mi je dopušteno, dopustite mi da izgovorim nekoliko redaka Ljudskog testiranja (na što svaki tester potičem samo ručno funkcionalno testiranje). Nemojte se sada zbuniti, po mom mišljenju ručno funkcionalno testiranje podskup je ispitivanja ljudi. Jer postoji toliko puno stvari koje samo Ljudski um može učiniti.

Ispod je popis nekih popularnih i važnih vrsta ispitivanja koje se mogu svrstati u Ljudsko testiranje:

  • Ručno funkcionalno ispitivanje : Testiranje funkcionalnosti aplikacije prema zadanom zahtjevu uz ljudske napore i inteligenciju. Dalje se dijeli na nekoliko vrsta na temelju opsega i dnevnog reda testiranja, kao što su sistemsko testiranje, jedinično testiranje, dimno testiranje, ispitivanje ispravnosti, integracijsko testiranje, regresijsko testiranje, testiranje korisničkog sučelja itd.
  • Ispitivanje performansi : Ovo se kategorizira u nefunkcionalno testiranje, zar ne? Ali opet, čovjek je taj koji to provodi, premda izvršenje obavlja bilo čovjek ili alat. Tester bi trebao obaviti ovo testiranje u smislu vremena odziva (da vidi je li prihvatljivo) ako ne bi trebao koristiti bilo koji alat za ispitivanje opterećenja i sve ostalo.
  • Preglednik / Ispitivanje kompatibilnosti platforme: Aplikacija koja se testira trebala bi izgledati i raditi prema očekivanjima (očito može postojati manja razlika ovisno o pokretaču preglednika) u svim preglednicima i platformama (ili uređajima ako je riječ o mobilnoj aplikaciji).
  • Ispitivanje upotrebljivosti : Dopustite mi da se prije svega složim da je ovo velika tema sama po sebi i obično je u vlasništvu stručnjaka za ispitivanje upotrebljivosti. Još uvijek vjerujem da bismo kao tester trebali barem prijaviti ili istaknuti ako nađemo nešto manje korisno ili bismo trebali podijeliti svoje mišljenje.
  • Ispitivanje sigurnosti : Opet vrlo velika vrsta testiranja i naravno zahtijeva puno praktičnog znanja. Tester bi trebao pokušati naučiti i izvršiti barem osnovne testove poput neovlaštenog korištenja URL-a, skriptiranja na više web lokacija, ubrizgavanja SQL-a, otmice sesije itd., Ovisno o dostupnom znanju i gdje god je to primjenjivo.
  • Višestanarsko testiranje: Ako je vaša aplikacija višestanarska, tj. Pojedinačna instanca koja sadrži podatke više klijenata, tada je ovo testiranje neophodno. Bez obzira na izričito spominjanje zahtjeva, to bi trebalo učiniti. Podaci jednog klijenta koji se prikazuju drugom vrsta su zločina koji se razvija i testira.

Bilješka: Iznad stavova su moji osobni pogledi. Također vam preporučujem da pogledate opsežni popis vrsta ispitivanja za svoje znanje i slijedite ih / koristite ako smatrate da je to potrebno. Tijekom godina shvatio sam da bez obzira koristite li nešto ili, vjerujete li u nešto ili ne, ipak biste trebali imati neko znanje o široko korištenim konceptima u svom području.

To je sve za ovaj dio. Hvala na čitanju. Podijelite svoje stavove / povratne informacije u komentarima.

U sljedećem i posljednjem dijelu ovoga priručnik za ručno testiranje , Pokušat ću vam svima pomoći kakvu biste pripremu trebali raditi ako želite ući u polje za testiranje i koji su mogući načini ulaska tamo.

Preporučena literatura

^