Odpowiedź.

Historia pytania:

Wraz z rozwojem masowej produkcji oprogramowania pojawiła się potrzeba szybkiego i jakościowego sprawdzania funkcjonalności produktów bez dostępu do ich wewnętrznej realizacji. Tak powstała metoda "czarnej skrzynki", w której tester pracuje tylko z publicznym interfejsem aplikacji.

Problem:

Bez zrozumienia kodu można przeoczyć niektóre wewnętrzne błędy lub nie przetestować określonych gałęzi wykonania. Niemniej jednak "czarna skrzynka" pozwala testować oczami użytkownika i odkrywać problemy z perspektywy użytkownika.

Rozwiązanie:

Metoda "czarnej skrzynki" polega na następującym:

Tester ocenia elementy interfejsu, zachowanie programu zgodnie z wymaganiami specyfikacji.
Nie wymaga znajomości kodu ani struktury systemu.
Sprawdzane są dane wejściowe i wyniki na wyjściu, a nie proces obliczeniowy między nimi.

Kluczowe cechy:

Zapewnia niezależną ocenę z punktu widzenia końcowego użytkownika
Pokrywa tylko zewnętrzne zachowanie systemu
Nie pozwala na sprawdzenie wewnętrznych błędów realizacji

Pytania z haczykiem.

Czy trzeba znać programowanie do testowania metodą "czarnej skrzynki"?

Nie, do zastosowania tej metody nie jest wymagana znajomość kodu, najważniejsze jest zrozumienie wymagań funkcjonalnych.

Czy metoda "czarnej skrzynki" gwarantuje pełne pokrycie wszystkich błędów?

Nie, ponieważ nie wszystkie błędy można wykryć przez zewnętrzny interfejs, część defektów pozostaje ukryta bez dostępu do wewnętrznej logiki.

Czy można stosować tylko "czarną skrzynkę" przy testowaniu skomplikowanych usług korporacyjnych?

Nie, zaleca się łączenie z innymi metodami ("białej skrzynki"), aby osiągnąć maksymalne możliwe pokrycie.

Typowe błędy i antywzorce

Testowanie tylko według UI bez sprawdzania API
Całkowite ignorowanie dokumentacji (specyfikacji)
Brak kreatywnych negatywnych scenariuszy

Przykład z życia

Negatywny przypadek

Tester sprawdzał aplikację bankową tylko metodą "czarnej skrzynki", wprowadzając standardowe dane przez interfejs i nie zwracając uwagi na pracę z wewnętrznym saldem (API nie było testowane).

Zalety:

Szybkie testowanie według scenariuszy użytkownika

Wady:

Po uruchomieniu okazało się, że przy powtarzających się operacjach dochodziło do naliczania dodatkowych środków (wewnętrzny błąd, który nie objawiał się na interfejsie użytkownika)

Pozytywny przypadek

Tester połączył testowanie: najpierw przeprowadził testy funkcjonalne metodą "czarnej skrzynki", opisując scenariusze użytkowników, a następnie, wspólnie z programistą, sprawdził API i dane w bazie danych.