Dále navazuje realizace testů, které je možné rozdělit do tří základních skupin, a to na testování podle scénářů, free testy a retesty. Při testování podle scénářů vycházejí testeři z vytvořených testovacích sad, které krok po kroku provádějí, a vyplňují, zda je jejich průběh v pořádku nebo byla identifikována nějaká chyba. Kromě těchto testů je vhodné, aby někteří ze zkušenějších testerů, vykonali i tzv. free testy, jejichž kroky nejsou předem popsány, ale jsou prováděny podle uvážení testera, který se snaží odhalit místa, kde by mohla být chyba. V posledním typu testování, při provádění retestů chyb, je na nových verzích vyvíjeného IS ověřováno, zda byly odladěny chyby nalezené na předchozích verzích.

V okamžiku, kdy je při provádění testů nalezena chyba, je nutné ji reportovat, resp. zaznamenat výsledky testů do Testovacích sad a Reportu chyb (součást pracovního produktu Záznam výsledků testů). Při reportování je vhodné nalezenou chybu nejen zaznamenat, ale také ohodnotit z hlediska její důležitosti a závažnosti. Závažnost vyjadřuje hodnocení chyby z pohledu uživatele, oproti tomu důležitost určuje rychlost, s jakou je třeba chybu odstranit.

V rámci této metodiky jsou rozeznávány čtyři stupně závažnosti chyb, a to:

• stupeň závažnosti A, který reprezentuje kritické chyby, jež naprosto omezují určitou funkcionalitu IS/ICT,
• stupeň závažnosti B, který reprezentuje nekritické chyby, které sice omezují určitou funkcionalitu, ale zkušený uživatel je může alespoň částečně obejít
• stupeň závažnosti C, který reprezentuje drobné chyby, které nemají téměř žádný vliv na funkcionalitu aplikace,
• stupeň závažnosti D, které nereprezentuje chybu, ale pouze situaci, kdy si tester není jistý, zda se aplikace chová opravdu správně nebo ne.

Důležitost chyby může být:

• vysoká, což znamená, že vyžaduje okamžitou reakci a do dalšího buildu musí být bezpodmínečně odstraněna,
• střední, která nevyžaduje okamžitou reakci, nicméně je doporučováno, aby byla do příštího buildu opravena,
• nízká, což znamená, že nemusí být opravována.
  

Po dokončení veškerých testů v dané iteraci, popřípadě pouze po významnějších iteracích, je vhodné vypracovat i Záznam výsledků testů, který shrnuje provedené testy a nabízí srozumitelný přehled o tom, jaké chyby byly nalezeny.

V případě automatických testů je postup práce při vlastním testování o mnoho jednoduší. Dochází pouze k výběru automatických testů (testovacích sad), které je vhodné na dané verzi IS/ICT vyzkoušet, a tyto testy jsou následně spuštěny. Nástroj, pomocí kterého jsou automatické testy prováděny, obvykle sám dokáže zaznamenat nalezené chyby do tzv. test logu.

V závěru testování přichází na řadu zhodnocení výsledků testů. Veškeré záznamy, které byly v průběhu testování vytvořeny, by měly být zpřístupněny všem členům týmu a souhrnné výsledky testování by měly být konzultovány na pravidelných setkáních týmu.

Každá chyba by měla být komunikována s příslušným vývojářem a požadavky na její nápravu by měly být zaznamenány v Seznamu pracovních položek nebo Seznamu požadavků na změnu. V průběhu testování také může být zjištěno, že se aplikace sice nechová dle testovací sady, ale její funkcionalita je správná. Změny, které je v tomto případě nutné provést, se netýkají vyvíjené aplikace, ale vlastních testovacích podkladů. Pokud je problém v testovací sadě či případu triviální, může být opraven přímo při testování.