Test pokrivenost u testiranju softvera (savjeti za maksimiziranje pokrivenosti testiranjem)

test coverage software testing

Potpuni vodič za pokrivanje ispitivanja softverskim testiranjem: Kako testirati više, uštedjeti vrijeme i postići bolje rezultate testiranja:

Testiranje softvera ključna je aktivnost u životnom ciklusu razvoja i održavanja softvera. To je praksa koja se često koristi za odlučivanje i poboljšanje kvalitete softvera.

Danas je razvoj sistematičniji i organizacije traže mjere ispitivanja potpunosti i učinkovitosti kako bi pokazale kriterije za završetak ispitivanja. Od svih se pokrivenost smatra posebno vrijednom.

Što ćete naučiti:

• Što je pokrivenost testom?
• Ispitajte pokrivenost i pokrivenost kodom
• Moje iskustvo
• Test značenje pokrivenosti
• Kako usvojiti odgovarajuću metodu pokrivanja testom?
• Kako biti siguran da je sve testirano?
• Kritična područja i metode za učinkovito ispitivanje
• Prednosti ispitivanja svijesti o pokrivenosti ispitivača:
• Zaključak
• Preporučena literatura

Što je pokrivenost testom?

Jednostavno rečeno, pokrivenost je 'Što testiramo i koliko testiramo?'

Pokrivenost testovima pomaže u nadzoru kvalitete ispitivanja i pomaže testerima da stvore testove koji pokrivaju područja koja nedostaju ili nisu provjerena.

Većina timova svoje izračune pokrivenosti temelji samo na funkcionalnim zahtjevima. To je također pošteno jer prvo i najvažnije aplikacija treba raditi ono što treba. Ako nije, brzina, sigurnost ili jednostavnost upotrebe - ništa od toga nije važno.

Međutim, ako je posvećen i neovisan nefunkcionalno ispitivanje timovi rade na izvedbi, sigurnosti, testiranju upotrebljivosti itd., a zatim će morati pratiti svoje zahtjeve sve do izvršenja putem analitike pokrivenosti testom.

Ispitajte pokrivenost i pokrivenost kodom

Pokrivenost testom često se miješa s pokrivenošću koda. Iako su temeljni principi isti, to su dvije različite stvari.

Pokrivenost kodom zaista govori o praksama jedinstvenog testiranja koje barem jednom moraju ciljati sva područja koda, a rade ga programeri.

Pokrivenost testom je, pak, testiranje svakog zahtjeva barem jednom i očito je aktivnost QA tima.

Što se stvarno kvalificira za pokriveni zahtjev, ovisi o interpretaciji svakog tima.

Na primjer , Neki timovi nazivaju zahtjev pokrivenim ako postoji barem jedan testni slučaj. Ponekad se pokriva ako mu je dodijeljen barem jedan član tima. Ili ako se izvrše svi testni slučajevi povezani s tim.

• Ako je stvoreno 10 zahtjeva i 100 testova - kada ovih 100 testova cilja svih 10 zahtjeva i ne izostavlja nijedan - to nazivamo odgovarajućim pokrivanjem testiranja na razini dizajna.
• Kada se izvrši samo 80 stvorenih testova i cilja samo 6 zahtjeva. Kažemo da nisu pokrivena 4 zahtjeva iako je provedeno 80% ispitivanja. Ovo je statistika pokrivenosti na razini izvršenja.
• Kada je samo 90 testova koji se odnose na 8 zahtjeva dodijelilo testere, a ostali nisu, kažemo da je pokrivenost zadatkom 80% (8 od 10 zahtjeva).

Također je važno kada treba izračunati pokrivenost.

Ako to učinite prerano u procesu, vidjet ćete puno praznina jer su stvari još uvijek nepotpune. Stoga se općenito savjetuje pričekajte do posljednje gradnje tj. Final Regression Build. To će pružiti ispravno pokrivanje testova provedenih za zadane zahtjeve.

Također pročitajte => Postupak upravljanja objavljivanjem i postavljanjem

Moje iskustvo

Scena prije 8 godina: Kad sam imao dvije godine iskustva u industriji testiranja softvera, mislio sam da je u redu ako ne znam neke osnove o testiranju softvera, jer se nešto može naučiti s iskustvom, a i ja ću to učiniti.

Bila sam u pravu - i također u krivu.

Točno jer s iskustvom naučite vidjeti širu sliku, razumijete pravo značenje 'kritične situacije' i više razumijete krajnjeg korisnika.

Pogrešno jer ni za jednu od spomenutih stvari nije potrebno iskustvo, već rano učenje, što sam vrlo kasno razumio. To je ohrabrujući faktor za pisanje ovog posta.

Evo mog iskustva iz jednog od tadašnjih intervjua:

Kako osigurati da je pokrivenost testom potpuna ili maksimalna? Pitali su me.

Ummmm ... Obavezno testiram svaku funkcionalnost , Rekao sam.

S o kažete da nakon što testirate sve funkcionalnosti, osjećate da ste pokrili maksimum aplikacije / proizvoda, u smislu testiranja , anketar se vratio.

Ummm ... pa ... .mmmm ... .da, jer kada testirate sve funkcionalnosti, sigurni ste u ponašanje aplikacije / proizvoda, Podržao sam svoj odgovor .

Slažem se, ali moje pitanje glasi - hoće li vam pružiti povjerenje da je vaše pokrivanje testiranjem maksimalno ili potpuno? ispitivač nije bio raspoložen da me pusti.

Sad sam postajao nestrpljiv, nepoznat zbog činjenice da ću naučiti jednu od najvažnijih tema o testiranju softvera - ' Test pokrivenost ” .

Umjesto da reproduciram dijelove intervjua, ovdje rezimiram ono što sam toga dana naučio o pokrivanju testiranjem. No, prije toga razjasnimo jednu stvar - pokrivenost testiranjem nikada ne znači znati testirate li dovoljno ili ne, niti znači da testirate savršeno ili ne.

Test značenje pokrivenosti

Obuhvat ispitivanjem može imati različito značenje u različitim kontekstima. Otkrijmo one kontekste jedan po jedan:

Pokrivenost proizvoda - Koje ste aspekte proizvoda pogledali?

najbolji špijunski uređaj za mobitele

Da, kada se mjeri pokrivenost testiranjem u smislu proizvoda, glavno područje na koje se trebate usredotočiti je - koja ste područja proizvoda testirali, a koja ostaju neprovjerena?

Primjer # 1:

Ako je 'nož' proizvod, vi testirate; samo se nemojte koncentrirati na provjeru reže li povrće / voće pravilno. Treba potražiti i druge aspekte, na primjer - korisnik bi trebao biti u stanju s tim se udobno nositi.

Primjer # 2:

Ako je 'notepad' aplikacija, vi testirate, provjera relevantnih značajki mora biti potrebna.

Ali drugi aspekti na koje treba voditi računa su - aplikacija pravilno reagira dok istovremeno koristi druge programe, aplikacija se ne ruši kada korisnik pokuša učiniti nešto neobično , korisniku se pružaju odgovarajuće poruke upozorenja / pogreške, korisnik može lako razumjeti i koristiti aplikaciju, sadržaj pomoći dostupan je po potrebi.

Ako ne proučite spomenute scenarije, ne možete tvrditi da je pokrivenost testiranja za aplikaciju potpuna.

Pokrivenost rizicima - Na koje ste rizike testirali?

Pokrivenost rizikom je još jedan aspekt potpune pokrivenosti testiranjem. Proizvod ili aplikaciju ne možete označiti kao 'testirani' dok ne testirate i povezane rizike. Pokrivenost povezanih rizika važan je čimbenik u ukupnom pokrivanju ispitivanjima.

Primjer # 1:

Tijekom ispitivanja zrakoplova, ako vam ispitivač kaže da je u potpunosti testirao unutarnji sustav zrakoplova i da radi u redu, ali tijekom leta nije obuhvaćena samo letačka sposobnost zrakoplova - kakva bi bila vaša reakcija?

Eto, to znači pokrivanje rizika. Prepoznavanje rizika prema aplikaciji / proizvodu i njegovo temeljito testiranje uvijek je dobra praksa.

Primjer # 2:

Tijekom testiranja web mjesta za e-trgovinu, ispitivač je uzeo u obzir svaki djelotvoran čimbenik, ali nije uzeo u obzir rizik od broja korisnika koji istovremeno pristupaju web mjestu i na dan Super PONUDE, a taj se rizik nije pokazao velikom pogreškom.

Preporučena literatura =>

• Ispitivanje temeljeno na riziku
• Upravljanje rizikom u fazi izvođenja testa

Pokrivenost zahtjevima - Za koje ste zahtjeve testirali?

Ako su proizvod ili aplikacija razvijeni vrlo dobro, ali ako se ne podudaraju sa zahtjevima kupca, onda nema koristi. Pokrivenost zahtjevima tijekom testiranja jednako je važna kao i pokrivenost proizvoda.

Primjer # 1:

Uzbuđeni zbog obiteljske funkcije, zamolili ste krojača da vam prošije haljinu i stavi te paunovoplave gumbe za prikaz na izrezu.

Dok je šivala haljinu, krojač je smatrao da stavljanje tih gumba na izrez neće izgledati dobro pa je umjesto toga prošio zlatni obrub. Na probni dan definitivno je nesretni kupac vikao na krojača da se ne drži zahtjeva.

Primjer # 2:

Tijekom testiranja aplikacije za chat, tester se pobrinuo za sve važne točke kao što je više korisnika koji razgovaraju u grupi, dva korisnika neovisno razgovaraju, dostupne su sve vrste emotikona, ažuriranja poslana korisniku itd., Ali zaboravio je pogledati dokument zahtjeva, koji jasno spomenuo je da kada dva korisnika neovisno razgovaraju, opcija video poziva treba biti omogućena.

Klijent je prodao aplikaciju za chat tvrdeći da će mu omogućiti pozivanje, dok dva korisnika neovisno razgovaraju. Možete zamisliti što bi se dogodilo s aplikacijom za chat.

Također čitati => Kako stvoriti matricu sljedivosti zahtjeva

Kako usvojiti odgovarajuću metodu pokrivanja testom?

Svjesnost je sve:

Prvo, QA tim mora znati koliko je posla uključeno i gdje su zadaci dizajna. Na taj će način biti svjesni hoće li se dodati još testova. Da biste to učinili, možete koristiti RTM kao što je tipična praksa.

=> Pogledajte ovaj članak da biste saznali više o njemu i kako ga koristiti: Kako stvoriti matricu sljedivosti zahtjeva - točan postupak s uzorkom predloška

Drugo, provjerite dodjelu resursa i postupak izvođenja testa da vidimo je li sve testirano na učinkovitiji način.

Tablica kao što je dolje može biti korisna:

Kako biti siguran da je sve testirano?

• Svaki ispitivač trebao bi biti svjestan zahtjeva i metoda ispitivanja
• Dajte prioritet svojim zahtjevima i usmjerite energiju tamo gdje je najpotrebnije
• Budite informirani o tome kako se određeno izdanje razlikuje od prethodnog kako biste mogli točnije prepoznati kritične zahtjeve i usredotočiti se na maksimalno pozitivno pokriće
• Prilagodite automatizaciju ispitivanja
• Koristite alate za upravljanje testovima da uvijek budem u toku
• Pametan radni zadatak - Usmjerite svoje najbolje resurse prema kritičnim zadacima i dopustite da novi testeri istražuju više za novu perspektivu
• Održavanje a kontrolni popis za sve zadatke i razne aktivnosti
• Više komunicirajte sa svojim razvojnim / Scrum / BA timovima kako biste stekli uvid u ponašanje aplikacije
• Pratite sve svoje cikluse izrade i popravke
• Prepoznajte probleme koji najviše utječu u početnim verzijama (kad je to moguće) kako bi kasniji mogli raditi na boljoj stabilnosti i doći do područja blokiranih prethodnim problemima

Kritična područja i metode za učinkovito ispitivanje

# 1)Premetanje resursa: Razmjenjujte zadatke između članova vašeg tima. To pomaže poboljšati angažman i spriječiti koncentraciju znanja.

#dva)Obuhvat kompatibilnosti: Provjerite jeste li svjesni i uključujući različiti preglednici i platforme kako biste testirali svoju prijavu.

# 3)Vlasništvo: Učinite testerima odgovornima i dajte im slobodu (uz praćenje i podršku naravno) za modul / zadatak na kojem rade. To im pomaže u izgradnji odgovornosti i omogućuje im isprobavanje kreativnih načina umjesto da slijede pretučene.

# 4)Rokovi: Poznavanje rokova za objavljivanje prije početka faze testiranja pomaže u učinkovitom planiranju

# 5)Komunikacija : Ostanite u kontaktu s razvojnim timom i ostalim timovima između ciklusa puštanja kako bi znali što se događa.

# 6)Održavanje RTM-a: Djeluje kao dobra izvedenica na Dionici ili klijenti , na temelju kojih se može potvrditi raspored izdavanja

Prednosti ispitivanja svijesti o pokrivenosti ispitivača:

• Prvenstveno pomaže kod određivanja prioriteta zadataka ispitivanja
• Pomaže u postizanju 100% pokrivenosti zahtjeva ili drugim riječima, sprječava curenje zahtjeva
• Analiza utjecaja postaje lakše
• Korisno u određivanju Kriteriji IZLAZA
• Omogućuje testni vodič za pripremu prozirnog izvještaj o zatvaranju testa

Zaključak

Pokrivanje testa ne završava spomenutim kontekstima. Postoje mnoge druge točke koje treba uzeti u obzir kada je riječ o pokrivenosti ispitivanjima.

Nije uvijek istina da kada testirate više, rezultati su bolji. Zapravo, kada testirate više bez očite strategije, vjerojatno ćete na kraju uložiti puno vremena.

Strukturiranijim pristupom, ciljem 100% pokrića zahtjeva i učinkovitim metodama ispitivanja, nećete ugroziti kvalitetu.

Nadamo se da će vam tehnike opisane u ovom članku dati neke smjernice.

Ulijte svoje komentare i stavove o postu. Kao i obično, volimo vas čuti.

Preporučena literatura

• Najbolji alati za testiranje softvera 2021. (Alati za automatizaciju ispitivanja kvalitete)
• Posao za QA pomoćnika za testiranje softvera
• Tečaj za testiranje softvera: Koji bih se institut za testiranje softvera trebao pridružiti?
• Odabir testiranja softvera za vašu karijeru
• Ispitivanje softvera Posao pisca tehničkog sadržaja Posao slobodnjaka
• Je li testiranje softvera emocionalni zadatak?
• Neka zanimljiva pitanja za ispitivanje softverskog testiranja
• Povratne informacije i kritike o tečaju softverskog testiranja