Redakcja
Założenie jest następujące: wystarczy mieć wymagania klienta, skonstruować na tej podstawie przypadki testowe, sformułować oczekiwane rezultaty i na końcu porównać wyniki testu ze zdefiniowanymi rezultatami.
Tutaj pojawia się moja wątpliwość... Ponieważ testowanie wszystkich przypadków jest niemożliwe, korzystamy z różnych technik celem ograniczenia ich liczby do rozsądnych rozmiarów. Jedną z takich technik jest "klasa równoważności", ale równie dobrze może być tutaj podstawiona każda inna.
Przy stosowaniu klas równoważności (generalizując pewne zbiory parametrów), automatycznie zakładamy (na jakiej podstawie?), że kod jest zaimplementowany zgodnie z założeniami tzw. "dobrych praktyk"...
A co jeśli nie? A co jeśli kod jest pisany przez programistę, który nie ma doświadczenia lub inaczej niż my rozumie to wymaganie? Prawdopodobieństwo popełnienia błędu jest bardzo duże, tak samo jak prawdopodobieństwo, że utworzony w tym miejscu defekt nie zostanie wykryty.
W tej sytuacji istnieją dwie możliwości:
- dopisujemy dodatkowe przypadki testowe
- zaglądamy do kodu
Pierwszy punkt zdaje się być bardzo atrakcyjny. Ale jest niezgodny z "tao" projektowania przypadków testowych!? Przecież po to zastosowaliśmy np. "klasy równoważności" aby zredukować liczbę przypadków. A teraz, ponieważ zastosowaliśmy klasy równoważności, musimy zwiększyć liczbę przypadków!? Absurd! Co więcej; na jakiej podstawie mamy stworzyć dodatkowe przypadki?
Drugi przypadek także eliminuje czarną skrzynkę, bo przecież zaglądamy do kodu. Ale uważam, że to podejście jest lepsze!
Na przykład:
Programista implementując zestaw wymagań obmyślił sobie, że jego podstawowym bytem będą szklanki. Z góry było wiadomo, że oprócz szklanek potrzebne będą także słoiki i dzbanki. Ale nasz inżynier sobie pomyślał: >>przecież słoiki i dzbanki to to samo co szklanka (służą do przechowywania cieczy) tylko inaczej skonfigurowane. Tak więc słoik i dzbanek to po prostu specjalne przypadki szklanki<<. Niestety... zespół testowy - ze względu na zupełnie inną obsługę dzbanków, inną obsługę szklanek i inną obsługę słoików - potraktował to jako zupełnie osobne byty. Testy zakończyły się pomyślnie a defekty pojawiły się dopiero w produkcji. Gdyby zespól testowy miał świadomość tego jak wygląda implementacja kodu, testy zostałyby dobrze skrojone.
Po pierwsze znając kod wiemy jak go "otestować" przypadkami, po drugie rozumiemy nie tylko jak program ma działać, ale także jak działa przez co jesteśmy w stanie identyfikować łatwiej źródła defektów.
Oczywiście wadą jest fakt, iż czasami dostęp do kodu nic nie da bo ze względu na "włoski makaron" lub rozproszenie źródeł, zrozumienie go zajmie więcej czasu niż czas potrzebny na "czarną skrzynkę" plus dodatki. W takim wypadku jednak można zorganizować spotkanie z szefem architektów aby wyjaśnił zamierzenia architektoniczne oraz spotkanie z szefem programistów aby wyjaśnił jak te zamierzenia zostały zaimplementowane.
Oryginał artykułu pojawił się na blogu termometr.blogspot.com w 2007 roku.
Autor: Tomasz Zdanowicz
