Testiranje bez QA resursa

Je li moguće izvršiti dovoljno testiranja softverske aplikacije samo s programerima i BA-ima i bez QA resursa?

Ovdje postoje dvije škole misli:

Jedno je uvjerenje da su sve programske pogreške povezane s kodom i da ako imate vrlo visok postotak pokrivenosti testa za svoj kôd, u osnovi ne biste trebali imati grešaka. Kao testeri, svi znamo da to nije istina!


Drugo je uvjerenje da provodite dovoljno jedinstvenog testiranja, a također i integraciju, testiranje sustava i prihvaćanja korisnika kako biste osigurali da aplikacija odgovara svojoj svrsi. Iako se ovo čini lijepom idejom, nije praktično jer se programeri trebaju kodirati nove značajke!

Oba su ta uvjerenja krajnja.


Testiranje vlastitog koda može biti učinkovito, jer kao programer znate koji je dio koda složen i vjerojatnije će biti prisluškivan, pa biste se usredotočili na to područje. Također, znajući da više nema osiguranja kvalitete, prisiljeni ste napisati kvalitetan kod, kako kaže jedan programer

Na svom prvom poslu nisam imao QA. Na meni je bilo da se pobrinem da moj vlastiti kôd bude dovoljno kvalitetan prije nego što ga objavim, a taj me aspekt dovoljno prestravio da sam naučio pisati kvalitetni kôd (što u osnovi znači da temeljito testirate vlastiti kôd i radite vlastiti QA).

Je li testiranje programera dovoljno?

Vjerujem da je dobar potez potaknuti programere da preuzmu vlasništvo nad kvalitetom vlastitog koda, no kada testirate vlastiti kôd, više je vjerojatno da ćete propustiti čitavu klasu bugova.

Možete biti vrlo učinkoviti u hvatanju vrsta bugova kojih se možete sjetiti, ali to su uvijek najlakše bugove koje uopće možete uhvatiti. Testovi koje sami napišete nikada neće dobro uspjeti u hvatanju pogrešaka u vašim pretpostavkama o tome što bi kôd trebao napraviti, koje vrste unosa treba obraditi, itd. Za hvatanje takvih vrsta konceptualnih grešaka stvarno je potrebno kontradiktorno testiranje nekoga tko nije polazi od istog skupa pretpostavki.


Rad kao ispitivač automatizacije značio je da se moram usredotočiti na testiranje i kodiranje istovremeno, a često sam se mučio! Kada sam kodirao testove, samo sam se želio uvjeriti da se kôd izvršava i proći test, nije me previše brinulo što je stvarni test jer mi je glavni fokus bio na kodiranju. Ubrzo sam shvatio da automatiziram beskorisne testove koji nisu dali nikakvu vrijednost.

Još jedna važna stvar koju treba napomenuti je da jedinstveno testiranje hvata samo pogreške programera u kodu, a jedinstveno testiranje ne otkriva kvarove u aplikaciji, što znači da ako imate 100% pokrivenosti koda, to ne znači da aplikacija ne sadrži greške.

Iako je uvijek potrebno testirati vlastiti kôd putem jediničnih testova prije nego što se proslijedi, također je važno imati taj drugi pogled na njemu sa stajališta ponašanja. Često smo preblizu koda da bismo ga doista uspješno pretukli i podvrgnuli stvarno čudnim rubnim slučajevima, a dobri QA ljudi prilično su vješti u tome. Testiranje na razini sustava od strane drugog skupa korisnika, poput testera, često može otkriti vrlo zanimljive pogreške.

Također, nije sve u funkcionalnom testiranju. Moramo brinuti i brinuti se o testiranju performansi, sigurnosnom testiranju, testiranju upotrebljivosti itd., Što je potrebno ako želimo izdati visokokvalitetni softver.


Zašto nam i dalje treba osiguranje kvalitete?

Testeri se ponekad smatraju uskim grlom na cijelom dovodnom cjevovodu. Ne bi li bilo puno bolje da je sve automatizirano bez ručne intervencije i bez testera koji podižu programske pogreške kako bi zaustavili izdanje?

Dio problema kada se testeri doživljavaju kao uska grla jest nedostatak vlasništva nad kvalitetom među programerima. Ako su svi istinski smatrali da su odgovorni za kvalitetu proizvoda (ne samo koda), programeri i testeri rade na istom cilju.

Testeri se mogu upariti s programerima kako bi napisali bolje jedinične testove, a programeri mogu pomoći testerima pri pisanju automatiziranih provjera, a također educirati testere o arhitekturi aplikacije kako bi mogli dizajnirati dobre testove kako bi pronašli područja koja će se vjerovatno slomiti tijekom testiranja sustava.

U idealnom svijetu, ispitivači ne bi trebali pronaći nikakve nedostatke, ili barem trivijalne mane. Kada postoji 'tim QA-a' čiji je posao pronaći nedostatke, programeri su primamljivi da se samo oslone na testere kako bi pronašli sve nedostatke, dok se programeri usredotočuju na razvoj i kodiranje.


Iako Yahooov potez u uklanjanju odjela za provjeru kvalitete i testiranje potiče programere da preuzmu vlasništvo nad kvalitetom proizvoda, još uvijek nije dovoljno dobar da osigura robustan proizvod. Rekavši to, čak i s timom testera još uvijek ne možete jamčiti softver bez grešaka, ali ono što je važno je osigurati da se softver gleda s različitih gledišta i iz različitih perspektiva, i tu je stvarna korist imati dolazi dobra QA funkcija (za razliku od QA tima).

Ispitivači mogu osigurati da programeri slijede najbolje prakse osiguranja kvalitete i pružiti pomoć u tehničkim i poslovnim testovima kako bi identificirali najvažnije pogreške prije izdavanja softvera.