Podczas przeglądów używa się list kontrolnych przypominających uczestnikom o konieczności zweryfikowania konkretnych elementów. Pomagają one również w wyeliminowaniu z przeglądu czynnika osobistego: „używamy tej samej listy we wszystkich przeglądach, nie tylko w odniesieniu do twojego produktu”. Listy kontrolne mogą być ogólne, do zastosowania we wszelkiego rodzaju przeglądach, lub skoncentrowane na określonych atrybutach jakości albo obszarach. Na przykład, lista przeznaczona do przeglądów dokumentacji wymagań może zawierać takie punkty, jak sprawdzenie odpowiedniego użycia pojęć „będzie” i „powinien”, weryfikacja formatowania oraz inne podobne elementy dotyczące zgodności z szablonem. Specjalne listy kontrolne mogą koncentrować się na zagadnieniach związanych z bezpieczeństwem lub wydajnością.

Najbardziej przydatne są listy kontrolne sukcesywnie tworzone przez konkretne jednostki organizacyjne, ponieważ uwzględniają:

• charakter produktu,
• lokalne środowisko wytwórcze:
  • personel,
  • narzędzia,
  • priorytety,
• historię poprzednich sukcesów i defektów,
• specyficzne problemy (np. dotyczące wydajności i bezpieczeństwa).

Listy powinny zostać dostosowane do potrzeb organizacji, a być może także do potrzeb konkretnego projektu. Listy kontrolne zaprezentowane w niniejszym rozdziale należy traktować jedynie jako przykłady.

W niektórych organizacjach rozszerza się podstawowe znaczenie pojęcia lista kontrolna i uwzględnia tzw. antywzorce, czyli często popełniane błędy, niewłaściwe techniki i inne nieefektywne procedury. Pojęcie to pochodzi od popularnej koncepcji wzorców projektowych, stanowiących przeznaczone do wielokrotnego użytku, sprawdzone w praktyce rozwiązania często występujących problemów [Gamma94]. Antywzorzec oznacza zatem często popełniany błąd, powstający nierzadko w wyniku doraźnego rozwiązania jakiegoś problemu.

Należy pamiętać, że jeżeli wymaganie nie jest testowalne, czyli jest zdefiniowane w taki sposób, że techniczny
analityk testowy nie może zaprojektować sposobu jego przetestowania, to w takim wymaganiu tkwi defekt. Na przykład wymaganie „Oprogramowanie powinno działać szybko” nie jest testowalne. W jaki sposób techniczny analityk testowy ma stwierdzić, że oprogramowanie działa szybko? Gdyby z kolei wymaganie zawierało stwierdzenie „Maksymalny czas odpowiedzi oprogramowania musi wynosić trzy sekundy przy konkretnym obciążeniu”, to testowalność takiego wymagania będzie znacznie większa, jeśli zdefiniuje się znaczenie określenia „przy konkretnym obciążeniu” (np. podając liczbę jednocześnie pracujących użytkowników i wykonywane przez nich działania). Jest to też wymaganie bardzo ogólne, ponieważ w przypadku nietrywialnej aplikacji może na jego podstawie powstać wiele odrębnych przypadków testowych. Prześledzenie związków tego wymagania z przypadkami testowymi ma również kluczowe znaczenie, ponieważ w przypadku zmiany wymagania należałoby dokonać przeglądu i odpowiednich modyfikacji wszystkich przypadków testowych.