Përdorni testet si evidencë

Nisni me kërkesën

Testet janë evidencë për pretendime konkrete. Një ekzekutim i suksesshëm testesh nuk vërteton çdo veti të softuerit. Para se të kërkoni teste, identifikoni sjelljen që ka rëndësi dhe defektin që duhet të zbulojë çdo kontroll.

Për një eksport të sajuar të të dhënave të një organizate, kërkesa kryesore është izolimi i të dhënave. Një përdorues në organizatën A nuk duhet të marrë rekorde nga organizata B. Një test që kontrollon vetëm një shkarkim të suksesshëm nuk e vërteton këtë kërkesë.

Kërkojini agjentit të shpjegojë lidhjen mes kërkesës dhe kushtit të kontrolluar nga testi. Kjo e bën më të lehtë zbulimin e rasteve të munguara para se grupi i testeve të bëhet i madh.

Zgjidhni fushën e duhur të testimit

Një test njësie mund të kontrollojë shpejt një transformim të vogël. Një test integrimi mund të kontrollojë si punojnë së bashku komponentët. Një test nga fillimi në fund mund të kontrollojë një sekuencë të rëndësishme veprimesh të përdoruesit në aplikacionin e vendosur ose në një aplikacion përfaqësues.

Përdorni fushën më të ngushtë që jep evidencën e kërkuar. Një formatues nuk kërkon test të plotë në shfletues për çdo hyrje. Një kufi autorizimi mund të kërkojë një route real dhe rrugë reale aksesi në të dhëna. Një ndërveprim kritik në shfletues kërkon evidencë për ndërfaqen e shfaqur.

Asnjë përqindje fikse e llojeve të testeve nuk i përshtatet çdo sistemi. Zgjidhni sipas dështimit që duhet të zbuloni dhe kostos së mirëmbajtjes së kontrollit.

Shmangni një supozim të përbashkët të gabuar

Një agjent mund të shkruajë implementimin dhe testet nga i njëjti keqkuptim. Të dy mund të përputhen ndërsa kërkesa mbetet e paplotësuar.

Supozoni se implementimi i filtron rekordet sipas ID-së së organizatës që jepet në kërkesë. Testi përdor të njëjtën ID për përdoruesin e futur në sistem dhe për kërkesën. Testi kalon. Rasti i munguar është një përdorues që kërkon ID-në e një organizate tjetër.

Shtojeni atë rast përmes rrugës reale të identitetit të besuar dhe autorizimit. Një mock që kthen gjithmonë ‘lejohet’ nuk mund të vërtetojë izolimin mes tenant-ëve. Vërteton vetëm sjelljen pasi autorizimi ka sukses.

Verifikoni se testi mund të dështojë

Për një defekt të njohur, ekzekutojeni testin e ri të regresionit kundrejt versionit me defekt në një branch të izoluar. Konfirmoni se dështon për arsyen e synuar. Pastaj zbatoni korrigjimin dhe ekzekutojeni sërish.

Një test që dështon sepse një fixture nuk mund të ngarkohet ende nuk është evidencë për sjelljen e biznesit. Shqyrtoni dështimin, jo vetëm kodin e daljes.

Për ndryshime më të gjera, testimi me mutacione mund të ndihmojë të vlerësoni nëse ndryshime të zgjedhura të kodit shkaktojnë dështime testesh. Ai ka kosto dhe nuk e zëvendëson shqyrtimin e kërkesave. Përdoreni aty ku evidenca shtesë mbështet një vendim me pasoja të rëndësishme.

Mbajeni evidencën të lidhur me ndryshimin

Ekzekutoni kontrollet përkatëse mbi rishikimin final. Regjistroni kontrollet e anashkaluara dhe arsyet e tyre. Një rezultat nga një commit i mëparshëm mund të mos vlejë më pas një korrigjimi nga shqyrtimi.

Mbajini testet të kuptueshme. Parapëlqeni përgatitje dhe kushte kontrolli të qarta kundrejt një funksioni të madh ndihmës që fsheh kushtin e rëndësishëm. Hiqni kontrollet e tepërta kur shtojnë kosto mirëmbajtjeje pa zbuluar një dështim tjetër.

Shqyrtuesi duhet të jetë në gjendje të thotë çfarë vërtetojnë testet dhe çfarë mbetet e pasigurt. Ky shpjegim është më i dobishëm sesa një numër i madh testesh.