Redakcja
Testowaniem czerwonej skrzynki (and. red-box testing) można określić takie podejście do testowania oprogramowania, które łączy w sobie elementy testowania białej, czarnej i szarej skrzynki. Cechą charakterystyczną tego rodzaju testowania jest ograniczona znajomość kodu źródłowego testowanego oprogramowania. Nie jest to więc ani testowanie białoskrzynkowe, (które wymaga pełnego dostępu do kodu), ani testowanie czarnoskrzynkowe (które nie wymaga do niego żadnego dostępu). Zamiast tego, red-box testing opiera się na częściowej wiedzy o wewnętrznej strukturze oprogramowania.
Testowanie czerwonoskrzynkowe sprawdza, czy oprogramowanie rzeczywiście robi to, co ma robić, oraz czy robi to dobrze. Nie ogranicza się ono jedynie do testowania funkcjonalności, ale bierze też pod uwagę doświadczenie użytkownika i zgodność ze standardami technicznymi. Stara się weryfikować oprogramowanie z perspektywy użytkownika końcowego, jednocześnie mając pewien wgląd w to, jak działa ono wewnątrz.
RBT przydaje się szczególnie w sytuacjach, w których testowanie białoskrzynkowe jest niemożliwe albo niepraktyczne, a testowanie czarnoskrzynkowe jest niewystarczające lub nieefektywne. Testowanie czerwonej skrzynki może być więc stosowane do przetestowania oprogramowania, które jest częściowo (lub całkowicie) zamknięte (na przykład oprogramowanie firm trzecich lub zabezpieczone przed kopiowaniem). Może być ono również stosowane do testowania oprogramowania, które jest zbyt złożone lub skomplikowane, aby być w pełni zrozumiałym przez testera (np. oprogramowanie oparte na sztucznej inteligencji lub uczeniu maszynowym).
Co daje testowanie czerwonej skrzynki?
Dzięki testowaniu czerwonej skrzynki jesteśmy w stanie przetestowanie zarówno funkcjonalności, jak i zgodność techniczną oprogramowania, kładąc przy tym nacisk na perspektywę, potrzeby i oczekiwania użytkownika końcowego. Pomaga więc ono wykrywać i rozwiązywać problemy z:
- użytecznością
- interfejsem użytkownika
- dostępnością.
Dzięki testowaniu czerwonej skrzynki można uniknąć kosztownych błędów i poprawek w późniejszych etapach cyklu życia oprogramowania. Wczesne wykrycie i naprawienie błędów oszczędza czas i zasoby, nie mówiąc już o reputacji i zaufaniu, jakie tworzone jest na linii użytkownik końcowy - oprogramowanie. Pozwala też wprowadzić zrównoważoną strategię testowania, która uwzględnia zarówno aspekty techniczne, jak i użytkowe oprogramowania.
Jak testować czerwoną skrzynkę?
Pierwszym krokiem jest zrozumienie tego, czego oczekują i czego potrzebują użytkownicy końcowi od oprogramowania. Jakie są funkcje i problemy ma rozwiązywać produkt? Jakie są cele i preferencje użytkowników? Jakie są ich ograniczenia i wyzwania? Gdy zbierzemy już te informacje, przychodzi czas na zdobycie wiedzy o technicznych aspektach oprogramowania. Nie chodzi o to, by znać kod na pamięć, ale o to, by mieć ogólne pojęcie o tym, jak zaprojektowany i zaimplementowany jest system, jakie są jego komponenty i jak one ze sobą współpracują, a także jakie są jego wymagania i specyfikacje.
W kolejnym kroku trzeba opracować przypadki testowe, które będą sprawdzać testowane oprogramowanie pod kątem funkcjonalności i zgodności technicznej. Powinny być one oparte na wymaganiach użytkowników i aspektach technicznych, a także uwzględniać różne scenariusze i warunki testowe. Przypadki testowe wykonuje się,używając oprogramowania w sposób zbliżony do tego, jak będą używać go użytkownicy końcowi, obserwując przy tym, jak się ono zachowuje, szukając wszelkich nieprawidłowości lub błędów, które mogą wpływać na jego funkcjonowanie lub doświadczenie użytkownika. Warto przetestować też protokoły, aby w ten sposób sprawdzić, czy oprogramowanie przestrzega niezbędnych standardów i protokołów technicznych. Tego elementu nie powinno się pomijać zwłaszcza przy oprogramowaniu, które musi być zgodne z określonymi normami.
Ważną częścią testowania czerwonoskrzynkowego jest wykonanie UAT, angażując rzeczywistych lub reprezentatywnych użytkowników w ocenę oprogramowania. Celem takich testów jest zebranie informacji zwrotnych na temat użyteczności, funkcjonalności i satysfakcji korzystania z oprogramowania, aby upewnić się, że spełnia ono ich potrzeby i oczekiwania użytkowników końcowych. Każde otrzymane wyniki należy dokładnie przeanalizować, identyfikując wszelkie błędy, problemy z użytecznością i obszary do poprawy, wprowadzić niezbędne zmiany, po czym dokonać retestów i całość powtórzyć, aż oprogramowanie spełni zarówno wymagania użytkownika, jak i techniczne. Przez cały proces nie wolno zapominać o dokumentowaniu swoich wniosków, przypadków testowych i informacje zwrotnych użytkowników.
Czerwona skrzynka = szara skrzynka?
Czy istnieje różnica między testowaniem a czerwonej a szarej skrzynki? Odpowiedź brzmi: tak. Testowanie szarej skrzynki jest połączeniem testowania białej i czarnej skrzynki, gdzie tester ma częściową wiedzę o wewnętrznej strukturze i logice aplikacji. Z kolei testowanie czerwonej skrzynki jest traktowane jako rozwinięcie user acceptance testing, w którym tester stosuje dowolną technikę, aby sprawdzić, czy oprogramowanie spełnia wymagania i oczekiwania.
Testowanie szarej skrzynki pomaga wykryć błędy wynikające z nieprawidłowej struktury lub użycia oprogramowania, natomiast testowanie czerwonej skrzynki przydaje się do zapewnienia funkcjonalności i użyteczności systemu z perspektywy użytkownika końcowego.
Różnice między testowaniem szarej i czerwonej skrzynki wyjaśnia poniższa tabela:
Testowanie czerwonej skrzynki w automatyzacji
Testowanie czerwonej skrzynki jest nie tylko metodą testowania ręcznego, ale może być również zintegrowane z automatyzacją testów, poprawiając efektywność i skuteczność procesów testowych. Może ono posłużyć jako most między tymi dwoma rodzajami testowania, pozwalając na bardziej zróżnicowane podejście, gdzie testy automatyczne są projektowane nie tylko pod kątem funkcjonalności, ale także z pewnym stopniem wglądu w wewnętrzne działanie oprogramowania. Co więcej, testowanie czerwonej skrzynki pozwala na tworzenie bardziej ukierunkowanych skryptów testowych, które mogą symulować interakcje użytkowników w sposób bardziej realistyczny, sprawdzając jednocześnie zgodność ze standardami technicznymi.
Uwzględniając perspektywę użytkownika i stronę techniczną, testowanie czerwonej skrzynki w automatyzacji jest w stanie zapewnić bardziej wszechstronne pokrycie testów, które wykracza poza testowanie na poziomie powierzchniowym, uwzględniając aspekty doświadczenia użytkownika i wydajność w różnych scenariuszach. Także w środowiskach CI/CD, testowanie czerwonej skrzynki może okazać się pomocne, pozwalając na ciągłe, automatyczne testowanie, które jest dokładne i zgodne z oczekiwaniami użytkowników.
Testowanie czerwonej skrzynki zmniejsza również prawdopodobieństwa błędu ludzkiego, co przełoży się na dokładniejsze wyniki testów. Automatyczne testy będą bardziej biegłe w odkrywaniu różnorodnych problemów - od błędów funkcjonalnych po problemy z doświadczeniem użytkownika – a to pomoże szybciej identyfikować i rozwiązywać problemy. Wreszcie, testowanie czerwonej skrzynki w automatyzacji daje możliwość łatwej integracji informacji zwrotnych pozyskiwanych od użytkowników z całym procesem testowania, dzięki czemu automatyczne testy pozostają istotne i skuteczne w ocenie doświadczenia użytkownika z oprogramowania. Włączenie testowania czerwonej skrzynki do strategii automatyzacji testów może poprawić proces zapewniania jakości, przez co stanie on się bardziej zgodny zarówno ze standardami technicznymi, jak i potrzebami użytkowników.
Testowanie czerwonej skrzynki, łącząc w sobie różne inne techniki testowania, pomaga wypełnić lukę między funkcjonalnością oprogramowania a doświadczeniem użytkownika. Taka strategia zapewniania jakości oprogramowania potrafi dostosować się do zmieniających się warunków i wymagań, nie zapominając jednocześnie o tym, jak ważne jest zastosowanie zrównoważonego i precyzyjnego procesu testowania do tworzenia użytecznego i dobrego jakościowo oprogramowania.
