4. jasno określony cel testowania pożądana jakość produktu – ponieważ nie można przetestować wszystkich możliwych przebiegów aplikacji, należy z góry określić te przebiegi które muszą bezwzględnie zachowywać się poprawnie; co więcej dopuszczamy nieprawidłowe zachowanie się aplikacji w pewnych sytuacjach. satysfakcja odbiorcy minimalizacja zmian – w przeciwieństwie do XP nie należy codziennie testować przygotowywanej aplikacji, tu należy dążyć do otrzymywania z produkcji wersji pełnej (oczywiście ze względu na wskazaną funkcjonalność). akceptacja na podstawie z góry ustalonych funkcjonalnych testów akceptacyjnych – w przypadku stwierdzenia innych błędów iteracja jest akceptowana, poprawianie to kolejna iteracja
5. testowanie parami „co dwie pary oczu to nie jedna” zwiększenie bezpieczeństwa testów mamy tu możliwość tworzenia różnych par testerów np. doświadczony – niedoświadczony, znający problem biznesowy – nowicjusz itp. należy zapewnić rotację testerów w parach, będzie to skutkowało zmniejszeniem zarządzania ryzykiem – odejście „dobrego” testera nie skutkuje „dużymi” stratami w projekcie