Redakcja
Obszar czarnoskrzynkowej weryfikacji jakości oprogramowania jest dość niewielki. Liczba technik zamyka się w kilkunastu, a automatyzacja bez zrozumienia architektury jest nieefektywna, w pewnych obszarach nawet nieskuteczna. Gdy rozmawiamy o nieskończonym procesie uczenia się, nieuchronnym kierunkiem jest pogłębienie wiedzy i wejście w rozumienie konstrukcji oprogramowania. Doskonałym przykładem mogą tu być testy bezpieczeństwa, które można zrealizować w 5% na poziomie interfejsu, a pozostałe 95% wymaga zrozumienia tego, jak zaprojektowane jest rozwiązanie.
Postaramy się bardziej szczegółowo pokazać na przykładzie testów API, jak różne poziomy wiedzy testera mogą przekładać się na pełniejszą weryfikację rozwiązania.
Czarna skrzynka to pierwszy etap rozwoju testera oprogramowania. Może ona pozostać stałą, wąską specjalizacją na poziomie testów funkcjonalnych dla ekspertów dziedzinowych lub dla ekspertów od UX. Dla wszystkich innych aspektów manualnej i automatycznej weryfikacji oraz charakterystyk oprogramowania konieczne będzie zejście do kolejnych warstw oprogramowania.
Przykład: Tester oprogramowania wie, że istnieje API, ale nie ma pełnej wiedzy o tym, jak ono działa i jakie funkcje są w nim zaimplementowane.
Szara skrzynka oznacza tutaj pogłębienie wiedzy i zrozumienie, co kryje się za interfejsami oprogramowania. Często jest to wiedza wystarczająca do tego, by projektować pierwsze testy automatyczne. Mówimy o sytuacji, gdzie na poziomie weryfikacji API mamy pełną listę funkcji, które są w danej usłudze dostępne. Istnieje więc możliwość pokrycia każdej z funkcji przynajmniej jednym testem.
Biała skrzynka daje nam pełne zrozumienie nie tylko tego, jakie i ile funkcji istnieje, ale również jakie mają one ograniczenia, a poprzez wgląd do ich kodu wiemy, jak możemy doprowadzić je do niepoprawnego lub nieobsłużonego działania. Projektowanie i wykonywanie testów na tym poziomie jest kompletne i uwzględnia pełne pokrycie ram dla danej funkcji API.
Przezroczysta skrzynka oznacza najwyższy poziom wtajemniczenia, gdzie żaden aspekt końcowego rozwiązania nie jest dla testera tajemnicą. W naszym przykładzie dla testów API mówimy o sytuacji zrozumienia dla samego oprogramowania, ale również np. dla aspektów hostowania usługi lub apektów sprzętowych.
Proces uczenia się nie jest tutaj może tak powolny, jak sama ewolucja, ale z perspektywy wieloletniej kariery zawodowej jednej osoby można go uznać za dość wolny. Z drugiej strony nie da się przez koncept skrzynek jednoznacznie pokazać przejścia od juniora do seniora, bo senior może swoją wiedzę zatrzymać na poziomie szarej skrzynki i nie będzie od niego wymagane dojście do głębszej wiedzy o działaniu oprogramowania. Można jednak pokazać, że pełne testy wymagają pełniejszego zrozumienia tego, jak powstaje oprogramowanie. Co więcej, pokazana w tym artykule przezroczysta skrzynka jest kompetencją niedostępną dla większości pracowników IT, ponieważ wymaga umiejętności i wiedzy z bardzo wielu, bardzo różnych obszarów: od komunikacji w systemach, po ich architekturę, aż na aspektach biznesowych oprogramowania kończąc. Można powiedzieć, że zdobycie pełnej wiedzy jest tak samo niemożliwe, jak uzyskanie pełnego pokrycia funkcji, danych i cech oprogramowania.
