QA baliabiderik gabe probatzen

Posible al da software aplikazioen azterketa nahikoa egitea garatzaileekin eta BArekin eta QA baliabiderik gabe?

Hemen bi pentsamendu eskola daude:

Bata, akats guztiak kodearekin erlazionatuta daudela sinestea da eta zure kodearen testaren estaldura portzentaje oso altua baldin baduzu, funtsean ez duzula akatsik izan behar. Probatzaile gisa, denok dakigu hori ez dela egia!

Beste ustea da unitateen azterketa nahikoa egiten duzula eta, gainera, integrazioa, sistema eta erabiltzaileen onarpen probak egiten dituzula, aplikazioa helburu egokia dela ziurtatzeko. Ideia polita dirudien arren, ez da praktikoa garatzaileek ezaugarri berriak kodetzen jarraitu behar dutelako!

Bi uste horiek muturrekoak dira.

Zure kodea probatzea eraginkorra izan daiteke, izan ere, garatzaile gisa badakizu zure kodearen zein zati konplexua den eta litekeena da buggy izatea, arlo horretan zentratuko zinateke. Gainera, QA gehiago ez dagoela jakinda, kalitate kodea idaztera behartuta zaude, garatzaile batek dioen moduan



Nire lehen lanean, ez nuen QArik. Askatu baino lehen nire kodea nahikoa kalitatezkoa zela ziurtatzea tokatu zitzaidan, eta alderdi horrek nahikoa izutu ninduen kalitate kodea idazten ikasi nuenean (horrek esan nahi du funtsean zure kodea ondo probatzen ari zarela, zure QA propioa egiten).

Garatzaileentzako probak nahikoa al dira?

Software garatzaileek beren kodearen kalitatearen jabe izan daitezen bultzatzea oso ona dela uste dut, hala ere, zure kodea probatzen duzunean akats klase oso bat galtzen duzu.

Pentsa ditzakezun akatsak harrapatzeko oso eraginkorra izan zaitezke, baina horiek dira beti harrapatzeko akatsik errazenak. Zuretzat idazten dituzun probek ez dute sekula lanik egingo kodeak zer egin beharko lukeen, zer sarrera mota kudeatu behar dituen, eta abarreko hipotesietan akatsak antzemateko. Arazo akats kontzeptual horiek harrapatzeko, ez da beharrezkoa norbaitek egindako aurkaritza probak egitea. Ez da hipotesi multzo beretik abiatzen.

Automatizazio probatzaile gisa lan egiteak biak probatzen eta kodetzen aldi berean zentratu behar nuela esan nahi nuen, eta askotan kosta egiten zitzaidan! Probak kodetzen ari nintzenean, kodea exekutatzen zela ziurtatu eta proba gainditu nahi nuen, ez ninduen gehiegi kezkatu benetako proba zer zen, nire ardatz nagusia kodeketan zelako. Laster konturatu nintzen baliorik ematen ez zuten alferrikako probak automatizatzen nituela.

Kontuan izan beharreko beste puntu garrantzitsu bat da unitateen probak programatzailearen akatsak soilik harrapatzen dituela, unitateen probak ez ditu aplikazioan akatsak hautematen, hau da,% 100 kode estaldura baduzu, horrek ez du akatsik gabeko aplikazio bat esan nahi.

Unitateko proben bidez zure kodea probatu behar bada ere, pasa aurretik, garrantzitsua da bigarren begi multzo hori jokabidearen ikuspuntutik ikustea ere. Askotan kodetik gertuegi gaude benetan behar bezala gainditzeko eta ertz kasu arraroen menpe jartzeko, eta QA pertsona onak nahiko trebeak dira horretarako. Beste erabiltzaile multzo batek, hala nola probatzaileek, sistema mailan probatzeak akats oso interesgarriak azal ditzake askotan.

Gainera, ez da proba funtzionalen kontua. Errendimendu probak, segurtasun probak, erabilerraztasun probak eta abar zaindu eta kezkatu behar ditugu. Beharrezkoa da kalitate handiko softwarea kaleratu nahi badugu.

Zergatik behar dugu oraindik QA?

Batzuetan probatzaileek botila-lepoa ikusten dute entrega-kanalizazio osora. Ez al litzateke askoz hobea dena automatizatuta egongo balitz eskuzko esku-hartzerik gabe eta akatsak sortzen dituzten probatzaileek oharra geldiarazteko?

Probatzaileek botila-lepo gisa ikusten direnean arazoaren zati bat garatzaileen artean kalitatearen jabe ez izatea da. Denek benetan produktuaren kalitateaz arduratzen zirela uste bazuten (ez soilik kodea), garatzaileek eta probatzaileek helburu beraren alde lan egiten dute.

Probatzaileek garatzaileekin parekatu ditzakete unitateko proba hobeak idazteko eta garatzaileek egiaztatzaile automatikoak idazten lagun dezakete eta probatzaileek aplikazioaren arkitekturari buruz ere hezten dituzte, sistema onak probatzeko garaian apurtu daitezkeen eremuak aurkitzeko proba onak diseinatu ahal izateko.

Mundu ideal batean, probatzaileek ez dute akatsik aurkitu behar, edo gutxienez akats hutsalak. Akatsak aurkitzea duen 'QA talde' bat dagoenean, garatzaileentzat tentagarria da garatzaileek garapen eta kodifikazioan zentratzen diren bitartean akats guztiak aurkitzeko probatzaileetan oinarritzea.

Yahoo-k QA eta Testing saila ezabatzerakoan garatzaileak produktuaren kalitatearen jabe izatera bultzatzen dituen arren, oraindik ez da nahikoa ona produktu sendoa bermatzeko. Hori esanda, probatzaile talde batekin ere ezin duzu akatsik gabeko softwarea bermatu, baina garrantzitsua da softwarea hainbat ikuspuntutatik eta ikuspegi desberdinetatik begiratzen dela ziurtatzea eta hor dago benetako abantaila izatea QA funtzio ona (QA taldearekin alderatuta) dator.

Probatzaileek garatzaileek kalitatea bermatzeko praktika onenak jarraitzen dituztela ziurtatu dezakete eta softwarea kaleratu aurretik akatsik kritikoenak identifikatzen lagunduko duten proba teknikoen eta negozioen diseinuak lagun ditzakete.