White Box & Black Box

W artykule tym chciałbym zapoznać czytelnika z dwoma technikami testowymi. Pokrótce opiszę metody zwane czarną oraz białą skrzynką. Nim zabierzemy sie do pracy musimy uzmysłowić sobie fakt, że testowanie samo w sobie jest pozbawione sensu, jeżeli nie określimy celów, do których zmierzamy. Przed przystąpieniem do pracy musimy określić przynajmniej ogólnikowy plan działania, w którym odpowiemy na następujące pytania:

• jaki jest zasięg przeprowadzanych przez nas testów
• z jakich narzędzi i technik testowych będziemy korzystać
• czy wykorzystujemy w pełni potencjał którym dysponujemy

Równocześnie powinniśmy określić kryteria, które pozwolą nam wybrane testy zakończyć.
Musimy ciągle pamiętać o jakości i solidności w naszym postępowaniu. Pozbawione sensu jest działanie gdy znajdując pewne anomalia w pracy programu mówimy „ten błąd nie pojawi się u klienta, zresztą po co mam to zgłaszać skoro i tak nikt już tego nie poprawi, jak klient sam to znajdzie to wtedy programiści rozwiążą ten problem”.

Przejdźmy do rzeczy… Weryfikacja działania programu może być przeprowadzona na wiele sposobów. Każdy z tych przypadków może zostać osiągnięty poprzez zastosowanie różnych powołanych do tego celu narzędzi, przy zastosowaniu różnorakich technik. Czym więc są te techniki testowe? Jest to zbiór metod, którymi posługujemy się w naszej pracy.

Metoda białej skrzynki (White Box)

Wykonywanie testów metodą białej skrzynki bazuje na naszej znajomości kodu testowanego programu. W ten sposób testujemy określone fragmenty programów (dla całości proces ten byłby zbyt żmudny i czasochłonny) w celu znalezienia sytuacji szczególnych, które prowadzą do błędów. Zajmujemy się jedynie tymi częściami kodu, w których widzimy zwiększone ryzyko wystąpienia błędów, w resztę struktury kodu nie ingerujemy.

Nasza praca powinna być podzielona na dwa etapy. Pierwszą fazą testów metodą White Box powinien według mnie zająć się zespół programistów odpowiedzialnych za dany projekt. Właśnie wtedy, gdy kodowana jest aplikacja istnieje największe prawdopodobieństwo wykrycia błędów. Im szybsze ich odnalezienie tym mniejszy nakład pracy na zlikwidowanie usterki i mniejsze koszty, które musimy ponieść. W drugim etapie aplikacja powinna przejść przez ocenę testerów. Wiadomo, że każdy, kto pisze kod będąc jego autorem jest przekonany, że to, co przesyła dalej jest pozbawione jakichkolwiek błędów. Tester jest osobą, która powinna mobilizować dział developmentu do bardziej intensywnej pracy, powinien wprowadzać zdrową konkurencję i przekonywać, że mimo błędów, które zostały już wyłapane on jest w stanie znaleźć jeszcze masę innych. Po przeprowadzeniu testów przez zespół QA testy białej skrzynki możemy uważać za zakończone.

Czarna skrzynka (Black Box)

Testy tego rodzaju odbywają się w oparciu jedynie o znajomość interfejsów konkretnych modułów i funkcji programu lub interfejsu całego systemu. Testy te powinny być przeprowadzane przez osoby, które nie były związane bezpośrednio z procesem tworzenia kodu. Testujemy tu ogólne funkcjonalności – trudno jest w ten sposób wychwycić przypadki szczególne. To właśnie tą metodą pośrednio posługujemy się w czasie weryfikacji podstawowego scenariusza testowego.

Chciałbym tu zwrócić uwagę na to, by nie mówić o tym który typ testów jest lepszy. Test jest zawsze testem. Trudno jest porównywać oba typy – w końcu każdy z nich zajmuje się testowaniem innych obszarów naszej aplikacji. Metody czarnej i białej skrzynki uzupełniają się (to tak jak tester i programista). Gdy w naszych projektach zastosujemy obie metody wykryjemy dwojakiego rodzaju błędy gdyż każda z metod ułatwi nam znalezienie usterek innego kalibru. Według mnie idealną sytuacją jest gdy tester w swojej pracy ma dostęp do kodu. To właśnie z niego może czytać jak z otwartej dłoni. Jego podejście jest znacząco różne od podejścia programisty. Programista skupia się na zagadnieniu „jak to zrobić” zaś tester zwraca znacząco większą uwagę czy dane metody są wystarczająco dobre i czy nie wprowadzają potencjalnego zagrożenia do naszych produktów.

dlaczego testować?

Obecnie nikt z nas nie wyobraża sobie życia bez komputera czy też telefonu komórkowego, coraz to częściej trudno jest nam się obyć również bez Internetu. Rozwój naszej cywilizacji związany jest nieodłącznie z rozwojem wielu dziedzin nauki w tym również informatyki. Osiągamy to dzięki twórczej pracy wielu jednostek i zespołów ludzkich. Pamiętajmy jednak, że człowiek jest istotą omylną. Z pewnością w naszym życiu nieraz spotkaliśmy się z oprogramowaniem, które nie działało tak jak tego oczekiwaliśmy. Niewielkie przeoczenie jednej z osób w zespole projektowym danej aplikacji może być powodem powstania błędów trudnych do uchwycenia w kodzie, co po kompilacji przekłada się na zawodność produktu, czy też całego systemu z którego korzystamy. W najmniej spodziewanym momencie może się więc wydarzyć coś, co nie jest zamierzone i potencjalnemu użytkownikowi może utrudniać pracę.
Przeprowadzanie testów, raportowanie błędów i sumienne prowadzenie dokumentacji projektowej może zredukować ryzyko wystąpienia awarii. Testowanie może podnieść jakość oprogramowania, rozumianą jako zwiększenie zaufania klienta. Celem testowania jest wykrycie jak największej ilości błędów. Poprzez wykonywanie odpowiednich testów w każdej z faz powstawania aplikacji możemy zminimalizować ryzyko wystąpienia błędów w gotowym produkcie. Możemy przez to zminimalizować koszty i obniżyć nakład pracy związany z późniejszymi usługami serwisowymi
i naprawianiem błędów w gotowym produkcie. Poza tym na pewno łatwiej jest znaleźć ewentualne błędy w poszczególnych fazach projektu, niż w jego całości.
Według Kroll`a i Kruchten`a pojęcie jakości jest synonimem relacji pomiędzy człowiekiem a rzeczą. Nawet jeżeli produkt pozostaje niezmienny, ludzie i ich otoczenie się zmieniają, zmienia się więc postrzeganie jakości. Śmiało można wysunąć wniosek, że proces testowy kończy się dopiero w chwili gdy nasz produkt przestaje być użyteczny – nie potrafi sprostać stawianym mu wymaganiom, bądź też zostaje wyparty przez konkurencyjne rozwiązania.
Przy pomocy testowania możemy ocenić jakość oprogramowania rozumianą jako liczba błędów znalezionych w trakcie jego tworzenia. Takie postępowanie, tj. krytyczna ocena każdej fazy projektu powinna zaowocować pozytywnym przejściem testów regresyjnych. Testy uwidaczniają nam ewentualne błędy i umożliwiają szybkie ich usuwanie w całym procesie tworzenia. Poprzez zrozumienie przyczyn występowania błędów możemy ulepszać nowe projekty redukując w bardzo wczesnym etapie możliwość powstawania podobnych usterek.