Oczywiste oczywistości czyli o podstawach kompletnych testów

Tym razem chciałbym napisać o rzeczach, które uważam za kompletne podstawy... . Chciałem zdanie dokończyć 'testowania oprogramowania' ale uzmysłowiłem sobie, że to nie dotyczy wyłącznie testowania. A więc... chcę napisać o kompletnych i podstawowych zabiegach, stosowanych w szeroko pojętej inżynierii w mocnym kontekście testów oprogramowania, odchylonych - z kolei - mocno w stronę automatyzacji i/lub powtarzalności.

• Parametryzacja - separacja danych od logiki ich przetwarzania. Duża część testów polega na mnipulacji samymi danych (klasy równoważności, wartość graniczne, dziedziny itd). W związku z tym o wiele łatwiej jest zarządzać tymi danymi mając je "na zewnątrz" skryptu.
  
• Atomizacja - rozbijanie złożonych problemów na proste. Informatyka jest pod tym kątem szczególnie łaskawą dziedziną. Praktycznie każdy złożony problem składa się z mniejszych i prostszych. Trzeba tylko umieć wyłowić powiązania prostych problemów w kontekście złożonego. Dodatkowo, "testowo" obsłużone proste problemy mogą być re-używalne.
  
• Logika - nie testować w oparciu o nazwy kontrolek ale w oparciu o logiczne przepływy danych. Każde oprogramowanie składa się z warstwy prezentacyjnej (interfejs użytkownika), warstwy przetwarzania (middleware) i warstwy sterowania (sterowniki). Dobrze napisane oprogramowania ma te warstwy mocno odseparowane co pozwala na wydajne testowanie logiki w oderwaniu od kontrolek i zasilaniu logiki bezpośrednio z zestawów danych testowych np. poprzez API.
  
• Narzędzia - co może za nas zrobić narzędzie to niech to zrobi. Pytanie tylko czy potrafimy tym narzędziem się posłużyć. Narzędzi jest całe mnóstwo i nie problem znaleźć takie, które wydaje się przydatne ale wcześniej trzeba wiedzieć do czego chce się wykorzystać takie narzędzie.
  
• Abstrakcja - nie związywanie procedur testowych z konkretną wersją (wyglądem) testowanego oprogramowania ale raczej z jego przeznaczeniem. Np. przypadki testowe odwołujące się do konkretnych nazw kontrolek muszą być aktualizowane gdy zmieni się wersja GUI. A z drugiej strony, skoro przypadki już są gotowe to po co czekać i nie uruchomić procedur testowych od razu. Przecież kontrolki na interfejsie użytkownika można potraktować jako swojego rodzaju dane, które się weryfikuje (czy kontrolka jest, wartości kontrolki, funkcjonalności kontrolki).
  
• Elastyczność - łatwość rozbudowywania i dostosowywania do konkretnych potrzeb. W przypadku automatyzacji chodzi np. o możliwość zestawiania poszczególnych skryptów czy przypadków testowych w różnych sekwencjach.
  
• Generowalność - generowanie scenariuszy i generowanie rezultatów testów. Wybudowanie środowiska testowego pozwalającego na swobodne generowanie scenariuszy testowych o jasno określonym celu jest bardzo trudne jeśli wręcz nie możliwe. Jakkolwiek, należy budować przypadki testowe w taki sposób aby na ich podstawie móc generować scenariusze. Drugą stroną jest możliwość generowania wyników z testów. Każdy przeprowadzony test kończy się określonym wynikiem. Dobrze jest jeśli takie wyniki odnotowywane są automatycznie w sposób umożliwiający ich dalszą weryfikację.