Przeprowadza testy

Dlaczego tak

Cykl TDD opisuje się jako red – green – refactor: najpierw powstaje test nowej funkcji, który nie przechodzi, bo funkcji jeszcze nie ma, potem najprostszy kod spełniający test, a na końcu porządkowanie kodu przy stale przechodzących testach. Pisanie testów po gotowym kodzie to klasyczne podejście, a nie TDD. Refaktoryzacja przed napisaniem kodu nie ma sensu, bo nie ma jeszcze czego porządkować.

Dlaczego tak

Test funkcjonalny sprawdza, co system robi – czy wykonuje właściwą operację i daje oczekiwany wynik. Test niefunkcjonalny sprawdza, jak system działa: wydajność, obciążenie, użyteczność, bezpieczeństwo czy zgodność. Czas odpowiedzi przy określonej liczbie użytkowników to wymaganie wydajnościowe, a koszyk, rabat i e-mail z potwierdzeniem to funkcje sklepu.

Dlaczego tak

Analiza wartości brzegowych sprawdza każdą granicę przedziału oraz najbliższą wartość leżącą po drugiej stronie granicy, bo tam najczęściej występują błędy typu „<” zamiast „<=”. Dla przedziału 18–65 są to 17 i 18 oraz 65 i 66. Zestaw 18, 40, 65 nie sprawdza wartości niepoprawnych, a w zestawie 17, 19, 64, 66 brakuje samych granic 18 i 65.

Dlaczego tak

Testy integracyjne wykonuje się po testach jednostkowych, aby sprawdzić współpracę modułów – przekazywanie danych i wywołania między nimi. Testy jednostkowe sprawdzają pojedyncze moduły lub funkcje w izolacji, a ten etap jest już zakończony. Testy akceptacyjne przeprowadza klient na końcu projektu, a testy dymne to szybkie sprawdzenie, czy nowa wersja w ogóle się uruchamia.

Dlaczego tak

Test obciążeniowy sprawdza działanie systemu przy spodziewanym, typowym lub szczytowym obciążeniu i porównuje wyniki, np. czas odpowiedzi, z wymaganiami. Test przeciążeniowy (stress test) celowo przekracza przewidywane obciążenie, aby znaleźć punkt awarii i sprawdzić, jak system się po niej zachowuje. Testy użyteczności dotyczą wygody obsługi przez ludzi, a testy zgodności – działania w różnych przeglądarkach i systemach.

Dlaczego tak

Status RESOLVED oznacza, że programista uważa sprawę za rozwiązaną, ale poprawkę musi jeszcze sprawdzić ktoś inny – zwykle tester lub zgłaszający. Po potwierdzeniu zgłoszenie otrzymuje status VERIFIED, a jeśli błąd nadal występuje, zostaje ponownie otwarte. Weryfikacja własnej poprawki przez programistę omija kontrolę jakości, a zgłoszeń się nie usuwa, bo stanowią historię projektu.