Coraz częściej - chyba dlatego, że programiści zabierają się za testowanie ;-) - można spotkać się z rozumieniem zagadnienia testowania w kontekście rywalizacji pomiędzy białą skrzynką a czarną skrzynką. Trudno jest udowodnić taką tezę! Jest to problem typu "kura czy jajko"!
Przykładem tego jest artykuł "Testing, fun? Really?"! Sam artykuł nie wnika subtelne różnice pomiędzy testami czarnej skrzynki a testami białej skrzynki. I chyba rzeczywiście tak powinno być. Test to test! Dobry tester powinien radzić sobie zarówno z kodem jak i z binarką. Na pewno nie powiem nic nowego stwierdzając, że czarna i biała skrzynka to uzupełniające się sposoby na przetestowanie oprogramowania. Problem polega na tym, że czarna skrzynka znajduje innego typu błędy niż biała skrzynka. Oznacza to oczywiście, że nie znajdziemy pewnych błędów stosując dajmy na to tylko test czarnej skrzynki.
Czy biała skrzynka oznacza konieczność stosowania testów jednostkowych? Według mnie nie! To co jest potrzebne to na pewno znajomość architektury danego rozwiązania oraz generalną strukturę organizacji kodu. W mojej opinii doskonałym rozwiązaniem jest korzystanie z kodu jak z podpowiedzi lub swojego rodzaju przewodnika. Na tej podstawie można w łatwy sposób zlokalizować potencjalne obszary ryzyka. Dodatkowo można spróbować określić techniczną naturę tego ryzyka i w zależności od tego zastosować techniki biało lub czarno skrzynkowe.
Testy jednostkowe to tylko jedno z zastosowań testów przeprowadzanych bezpośrednio na kodzie źródłowym i powinny być wykonywane przez autorów tego kodu. Testerzy natomiast nie powinni być odcinani od kodu. Obcując z nim, czytając, poznając architekturę rozumieją w jaki sposób system działa, są w stanie w łatwiejszy sposób zidentyfikować obszary wymagające bardziej intensywnych testów.
Nie pamiętam kto, powiedział, że prawdziwy haker to taki człowiek, który potrafi - mając zdefiniowane zadanie - określić, który język programowania będzie pasował najlepiej do realizacji tego zadania. Podobnie jest z testerami. Posiadając wiedzę na temat systemu, sposobu jego działania, sposobu w jaki jest budowany, architektury, itp. jest w stanie określić, które metody testowe będą najbardziej wydajne w stosunku do których obszarów (typów defektów).
Oczywiście dostęp do kodu powinien być przeznaczony dla osób, które posiadają odpowiednie kompetencje. Ale czy trzeba być programistycznym guru aby to robić? I znowu, wg. mnie wystarczy podstawowa wiedza dotycząca konkretnego języka, sposobu budowania funkcji, deklarowania i rzutowania zmiennych, tzw. "best practices". Podręcznik do C jest chyba inaczej czytany przez programistę a inaczej przez testera. Programista skupiony jest na zagadnieniu "jak coś zrobić" (przynajmniej tak mi się wydaje), tester natomiast skupiony jest na "obszarach potencjalnie niebezpiecznych".
1 komentarz:
Popieram, chociaż w wielu zespołach z którymi się spotkałem testerzy nie mają dostępu do kodu, wykonują testy po GUI, zaglądają do bazy danych i co wtedy? Czy to oznacza, że testy nie są przeprowadzne w pełni? Wg. mnie to zależy od konkretnego przypadku, w dużych korporacjach gdzie kod nie jest tworzony na miejscu w ogóle nie jest rolą testera aby badał kod, ani nie ma na to tak naprawdę czasu... Jak często testerzy podejmują się testów white box?
Chciałbym poznać inne zdania na ten temat...
Prześlij komentarz