Po co testerowi teoria
Teoria daje wspólny język. Kiedy w zespole ktoś mówi “zróbmy regresję po tej poprawce” albo “to defekt o niskiej ważności, ale wysokim priorytecie”, wszyscy powinni rozumieć to samo. Poza tym pomaga wybierać testy z głową, a nie testować wszystkiego po trochu.
Ten wpis opiera się na sylabusie ISTQB Foundation Level (v4.0), czyli standardzie, na którym bazuje większość szkoleń i rozmów rekrutacyjnych. To druga część serii “Testowanie od podstaw”.
Pomyłka, defekt, awaria
Trzy słowa, które w mowie potocznej znaczą “błąd”, a w testowaniu opisują trzy różne rzeczy:
- Pomyłka: człowiek robi coś źle, np. programista źle rozumie regułę naliczania rabatu.
- Defekt: skutek pomyłki zapisany w kodzie, wymaganiach albo dokumentacji.
- Awaria: moment, w którym defekt ujawnia się podczas działania systemu, np. klient płaci pełną cenę mimo kodu rabatowego.
Rozróżnienie ma praktyczne znaczenie. Testy dynamiczne (uruchamianie aplikacji) znajdują awarie, a przyczynę, czyli defekt, trzeba dopiero ustalić. Przegląd wymagań może znaleźć defekt, zanim ktokolwiek napisze kod.
7 zasad testowania w praktyce
| zasada | co oznacza w pracy |
|---|---|
| Testowanie ujawnia defekty, nie dowodzi ich braku | “Nie znalazłem błędów” to nie to samo co “błędów nie ma”. Raportuj, co sprawdziłeś. |
| Testowanie gruntowne jest niemożliwe | Wszystkich kombinacji nie przetestujesz, więc wybierasz według ryzyka. |
| Wczesne testowanie oszczędza czas i pieniądze | Pytanie o wymaganie przed implementacją kosztuje minutę, poprawka po wdrożeniu dni. |
| Defekty się kumulują | Większość błędów siedzi w kilku modułach. Tam testuj dokładniej. |
| Testy się zużywają | Te same testy z czasem przestają znajdować nowe błędy. Zmieniaj dane i scenariusze. |
| Testowanie zależy od kontekstu | Aplikacja bankowa i strona wizytówka potrzebują innego podejścia. |
| Przekonanie o braku defektów jest błędem | System bez błędów, który nie rozwiązuje problemu użytkownika, i tak jest bezużyteczny. |
Proces testowy
Testowanie to więcej niż wykonywanie testów. ISTQB wyróżnia grupy czynności, które w praktyce się przeplatają:
- Planowanie: cele, zakres, podejście, harmonogram.
- Monitorowanie i nadzór: porównywanie postępu z planem i reagowanie na odchylenia.
- Analiza: co testować, czyli warunki testowe na podstawie wymagań i ryzyka.
- Projektowanie: jak testować, czyli przypadki testowe i potrzebne dane.
- Implementacja: przygotowanie środowiska, danych i skryptów.
- Wykonanie: uruchomienie testów, porównanie wyników, zgłoszenie defektów.
- Ukończenie: raport, wnioski, archiwizacja materiałów testowych.
W małym zespole wszystko to robi jedna osoba w ciągu jednego sprintu. W dużym projekcie każda czynność może mieć osobny dokument.
Poziomy testów
| poziom | co sprawdza | kto zwykle wykonuje |
|---|---|---|
| testy modułowe | pojedyncze funkcje i klasy | programiści |
| testy integracji modułów | współpracę modułów w jednym systemie | programiści, testerzy |
| testy systemowe | cały system względem wymagań | testerzy |
| testy integracji systemów | współpracę z systemami zewnętrznymi, np. płatnościami | testerzy |
| testy akceptacyjne | czy system spełnia potrzeby użytkownika i biznesu | klient, użytkownicy, właściciel produktu |
Tester na początku kariery najczęściej pracuje na poziomie systemowym i przy testach akceptacyjnych.
Typy testów
Typ testu mówi, jaką cechę sprawdzasz, niezależnie od poziomu.
- Funkcjonalne: czy system robi to, co powinien.
- Niefunkcjonalne: jak to robi: wydajność, bezpieczeństwo, użyteczność, dostępność, kompatybilność.
- Czarnoskrzynkowe: oparte na specyfikacji i zachowaniu, bez zaglądania w kod.
- Białoskrzynkowe: oparte na strukturze kodu, np. czy każda gałąź warunku została wykonana.
Do tego dwa rodzaje testów związanych ze zmianą:
- Retest (test potwierdzający): czy konkretny defekt został naprawiony.
- Test regresji: czy zmiana nie zepsuła czegoś, co wcześniej działało.
Regresja to najlepszy kandydat do automatyzacji, bo powtarza się przy każdym wydaniu. Więcej o tym w poradniku o regresji w CI.
Testy statyczne i dynamiczne
Testy dynamiczne wymagają uruchomienia aplikacji. Testy statyczne to sprawdzanie bez uruchamiania: przegląd wymagań, historyjek, projektu, kodu, a także analiza narzędziami.
Przykład z praktyki: historyjka mówi “użytkownik może anulować zamówienie”. Pytanie przy przeglądzie: do kiedy? Po wysyłce też? Odpowiedź zajmuje minutę, a bez niej programista zgaduje i tester zgłasza potem defekt, który wcale nie jest błędem programisty, tylko luką w wymaganiu.
Jak uczyć się dalej
Sylabus ISTQB Foundation Level jest bezpłatny i dostępny także po polsku. Nie trzeba go znać na pamięć, ale warto przeczytać całość raz i wracać do rozdziałów przy konkretnych problemach. Słownictwo z tego wpisu sprawdzisz w praktyce w 50 pytaniach rekrutacyjnych na testera QA.
Kolejna część serii pokazuje, jak z tej teorii zrobić konkretne przypadki testowe.
Seria “Testowanie od podstaw”
- Czym zajmuje się tester i jak zacząć
- Teoria testowania w pigułce (ten wpis)
- Jak napisać przypadek testowy
- Jak zgłaszać defekty
- Testowanie API od podstaw
- Pierwsze kroki w automatyzacji testów