Między młotem a kowadłem, tak, zdaje się najtrafniej można określić miejsce testera w zespole. Młotem jest szef projektu, a kowadłem zaś zleceniodawca.

Oprogramowanie ma coraz większy wpływ na nasze bezpieczeństwo oraz możliwość normalnego funkcjonowania. Nierzadko powierzamy swoje życie urządzeniom, maszynom oraz systemom, które funkcjonują w oparciu o cyfrowe przetwarzanie danych (sygnału). Niewątpliwie i prawdopodobnie nieodwracalnie, wdarło się ono w niemal każdy aspekt naszego życia, głęboko się zakorzeniając.

4 czerwca 1996 roku wystrzelono bezzałogową rakietę kosmiczną Ariane 5. Jej lot trwał zaledwie 40 sekund. Ogień eksplozji strawił 7 miliardów dolarów wydanych na budowę rakiety oraz dodatkowe 500 milionów dolarów, które stanowiły równowartość ładunku. Po dwóch tygodniach od katastrofy komisja podała, że przyczyną niepowodzenie był błąd w oprogramowaniu, związany z niepoprawną konwersją liczby zmiennoprzecinkowej na liczbę całkowitą [1].

W 1997 roku pojawił się na rynku samochód Mercedes-Benz klasy A. Testy bezpieczeństwa jazdy wypadły bardzo słabo, a wręcz niezadowalająco. Samochód przewracał się podczas "testu łosia". Manewr polega na gwałtownym skręcie najpierw w jedną stronę a następnie dynamicznie w drugą. Przyczyną tak owego zachowania pojazdu była wada w oprogramowaniu komputera, sterującego amortyzatorami [1].

Cel testowania
Testowanie oprogramowania jest procesem bezpośrednio związanym z jego wytwarzaniem. Stanowi on także jeden z procesów kontroli jakości aplikacji.
Celem testów jest wykrywanie błędów. Czym wcześniej zostaną one wykryte, tym mniejsze poniesiemy koszty ich naprawy.

Wszystkie zabiegi, jakie poczynimy w kierunku poprawy jakości oprogramowania, mają na celu zmniejszenie ryzyka wystąpienia błędu po przekazaniu produktu do klienta. Poprzez termin klient należy rozumieć w pierwszej kolejności klienta wewnętrznego (przekazywanie półproduktu do następnych działów/sekcji), a dopiero finalnie odbiorcę zlecającego produkcje (implementacja na żywy organizm).
Koszty (czas i pieniądze) obsługi błędu wykrytego na kolejnych etapach produkcji rosną lawinowo. Błąd wykryty w fazie definiowania projektu prawie nic nie kosztuje. Zazwyczaj można go usunąć w kilkanaście minut, co przekłada się, co najwyżej na kilka dodatkowych dolarów.
Inaczej jest, kiedy błąd zostanie ujawniony już w systemie produkcyjnym, który realizuje konkretne procesy biznesowe. Wystąpienie takiej sytuacji nierzadko może prowadzić do dramatu, który zapoczątkuje ciąg zdarzeń spychających firmę wprost do bankructwa.
Tak to już w życiu bywa, że jak komuś stanie się krzywda, to trzeba znaleźć winnego. Podmiot odpowiedzialny zazwyczaj ponosi konsekwencje zdarzenia. Jest poddany presji formalnej, finansowej i społecznej. Jeżeli producent oprogramowania (systemu) jest w stanie utrzymać na swoich barkach ciężar tej dramatycznej pomyłki, czy też niedociągnięcia, to musi zabrać się do niezwłocznego usunięcia wady - jeżeli nie to prawdopodobnie poniesie konsekwencje prawne (karne).
Tylko, iż to już nie sprowadza się jedynie do zmiany kodu oprogramowania.
Przecież jeszcze należy umożliwić dalszą pracę klientowi, który posługuje się naszym produktem. Każdy przestój kosztuje. Klient musi zapłacić pracownikom, w dodatku nie zarabia, ma do opłacenia koszty stałe poza personalne oraz traci markę. Tym samym wyrzucając w otchłań pieniądze przeznaczone na marketing.
Jednym słowem jest to dramat! A to nie koniec!
Trzecią kwestią jest usunięcie błędów z bazy (systemu) powstałych na skutek wady w oprogramowaniu. Nie trudno sobie wyobrazić, iż koszty całej procedury naprawczej i korygującej są ogromne.

Przy czym zaznaczam, iż nieco inaczej należy spojrzeć na producentów oprogramowania dla klientów masowych (np. aplikacje księgowo-magazynowe) aniżeli na firmy wykonujące system na indywidualne zamówienia (np. system dla banku).

Punktem ciężkości jest określenie, kto zawinił. Jeżeli jest to błąd obsługi oprogramowania, to nie ma problemu. Marketing zaciera ręce, zgłasza bezwzględną gotowość pomocy (płatnej) i utrwala pozytywne relacje z klientem.

Tym niemniej, jeżeli błąd leży po stronie producenta, to już jest gorzej. Każde dodatkowe środki wydane na serwis oprogramowania pomniejszają pulę z sumy przeznaczonej na wypłatę dywidendy. Tłumaczyć nie trzeba, czym to skutkuje. Szukanie winnego zaczyna się od dołu, czyli od testera aplikacji.

Definicja błędu
Za błąd uznaje się wszystko to, co jest niezgodne z projektem. Wydawać by się mogło, iż jest to jedyna i niezwykle trafna definicja. Niestety, ale stanowi ona tylko punkt wyjścia.

Jednym z najpoważniejszych problemów podczas realizacji przedsięwzięcia w aspekcie jakości, są błędy i spory wynikające z rozbieżnej interpretacji projektu. Innymi słowy ujmując, każdy ma ten sam projekt, ale inaczej wyobraża sobie efekt końcowy. Poniższe diagramy doskonale obrazują ten problem. Może w nieco w humorystyczny sposób, ale za to bardzo celny.


Rys 1. Jak wygląda naprawdę projekt cz.1

 

Rys 2. Jak wygląda naprawdę projekt cz.2

 

Rys 3. Jak wygląda naprawdę projekt cz.3

 
Rys 4. Jak wygląda naprawdę projekt cz.4


Wersje oryginalną można znaleźć na http://www.projectcartoon.com/ [How IT Projects Really Work (version 1.5) - Polish].

Testy
Oprogramowanie testuje się na wiele różnych sposobów. Wybór metody, zakresu i przypadków testowych zależy od tego, co w danym momencie jest dla nas ważne. Testy obciążeniowe wykonujemy chcąc sprawdzić wydajność aplikacji. Testy regresywne stosuje się po to, aby upewnić się czy nowa funkcjonalność nie "uszkodziła" innych modułów.

Poniżej przytaczam kilka najważniejszych rodzajów testów.

Testy automatyczne i manualne:

• Testy automatyczne zasadniczo wykonuje się w oparciu o specjalistyczne oprogramowanie, które za testera wykonuje zdefiniowane ścieżki (uruchamiane są skrypty).
• Testy manualne wykonuje ręcznie tester w oparciu o przypadki testowe (sekwencje kroków).
• Testy strukturalne i funkcjonalne:
• Testy czarnej skrzynki (ang. black box testing). W tym przypadku tester traktuje oprogramowanie analogicznie jak operator. Wykonuje czynności nie wnikając w szczegóły techniczne. Obserwuje jedynie wyniki wykonanych operacji. Są to testy funkcjonalne.
• Testy białej skrzynki (ang. white box testing). Tester ma dostęp do kodu. Może go analizować i śledzić np. do jakich bibliotek sięga aplikacja. Są to testy strukturalne.

Zakres testów:

•   Testy jednostkowe - jest to niski poziom testów, sprowadza się do pojedynczej metody (funkcji, modułu).
•   Testy integracyjne - analizujemy jakość i poprawność współpracy poszczególnych komponentów (modułów) między sobą.
•   Testy systemowe - sprawdzamy działanie aplikacji (systemu) jako całości.

Podział testów ze względu na ich przeznaczenie:

• Regresywne - sprawdzamy czy nowa funkcjonalność nie naruszyła innych modułów, obszarów oprogramowania.
• Obciążeniowe (wydajnościowe) - weryfikujemy jak zachowuje się aplikacja przy dużych ilościach danych.
•  Funkcjonalne (akceptacyjne) - weryfikacja oprogramowania, czyli sprawdzenie zgodności ze specyfikacją (!).
• Testy alfa i beta - udostępniamy wstępną wersją produktu określonej grupie użytkowników, a następnie zbieram od nich informacje zwrotne (wrażenia, odczucia, sugestie).
• Testy post-awaryjne - badamy, w jaki sposób aplikacja zachowa się w sytuacji awaryjnej, czy zadziałają procedury np. zabezpieczenia integralności danych.
•  Używalności (ang. usability tests) - w ten sposób uzyskami informacja na ile system (interfejs) jest przyjazny dla potencjalnego użytkownika, w oparciu o szybkość nauki jego obsługi.
• Testy konfiguracji (instalacyjne) - służą do sprawdzenia jak zachowuje się oprogramowanie na różnych platformach sprzętowych i systemach operacyjnych.

Pozostają jeszcze kwestia, kto, co, jak, kiedy i w jakim zakresie będzie testował?
Tym niemniej, nie będę nad tym rozważał w niniejszym artykule. Zaiste można by na ten temat napisać osobny tekst.

Moim celem jest zasygnalizowanie problemów społecznych w relacjach między osobami zaangażowanymi w projekt. Jak także zwrócenie uwagi na konieczność wykonywania testów oprogramowania.

Problemy testera
Rolą testera jest porównanie otrzymanego produktu z opisem w projekcie.
Tylko, że nie da się w pełni sprawdzić oprogramowania według takiego klucza. Tester nie jest w stanie uruchomić każdego moduł produktu przy uwzględnieniu wszystkich danych wejściowych, jakie mogą wpłynąć do systemu.
Oczywiście, obowiązkowo należy sprawdzić wartość graniczne, które uzupełnimy wybranym zbiorem danych ze środka przedziału. Tak testujemy każdy moduł, ale nie gwarantuje nam to, że kiedyś nie wystąpi sytuacja, gdzie do jakiejś funkcji nie spłynie kombinacja parametrów, z którymi ona sobie nie poradzi.

Problemem nie są dane początkowe, które operator wpisuje ręcznie. Można skutecznie zabezpieczyć się przed tym procedurami walidującymi, które wykluczą błędne wartości. Problemem jest, aby system sam wewnętrznie nie generował i podawał dalej błędnych parametrów (wartości). Przed tym nie jesteśmy w stanie się w pełni zabezpieczyć. Dlatego też, programiści powinni skrupulatnie wstawiać prawidłowe opisy (kody błędów), które będą zwracane w przypadku nie spełnienia warunków dla wykonania jakiejś procedury czy funkcji - oprogramowanie zgłosi błąd, ale podając jego kod serwis od razu zacznie szukać we wskazanym obszarze.

Po drugie środowisko laboratoryjne prawie nigdy nie jest odwzorowane 1:1. Oczywiście nie jest to możliwe do spełnienia i ciężko zaprzeczyć zasadności tego stanu rzeczy. Tym niemniej, ma to swoje konsekwencje.
Wyobraźmy sobie system, który obsługuje 3000 terminali obsługiwanych przez 5000 operatorów, gdzie każdy z nich wykonuje sto razy więcej operacji dziennie aniżeli pojedynczy tester. Firma produkująca oprogramowania dysponuje dwunastoma testerami, którzy wykonują kilka operacji dziennie w kilkunastu różnych modułach. Nie trzeba wielkiej matematyki, aby oszacować, szanse testera. Z drugiej strony testerzy posiadają więcej narzędzi i możliwości, które mają im zrekompensować dużo skromniejsze środowisko testowe.

Wszyscy przynajmniej raz w życiu mieliśmy w ręku produkt, który był przyzwoicie wykonany, spełniał swoją funkcje, jego koszt był adekwatny do jakości, nie był zwyczajnym bublem, ale czegoś bliżej nieokreślonego mu brakowało.
Analogicznie jest z oprogramowaniem. Taki stan rzeczy często można określić jako niedogodność funkcjonalną aplikacji, która formalnie nie jest błędem.
Powstaje pytania, a raczej kłopot, co z takim fantem zrobić. W pierwszej chwili nasuwa się pomysł, aby zgłosić wniosek o zmianę (cofnąć emisje do produkcji).Tylko, że do tego zazwyczaj jest potrzebna podstawa prawna, na którą należy się powołać (patrz projekt). Tym niemniej, skoro zgłoszenie nie jest sprzeczne z projektem, to prawdopodobnie spotkamy się odrzucenia wniosku. Czyli wracamy do punktu wyjścia.
Tester ma stwierdzić zgodność oprogramowania z dokumentacją. I tak się dzieje, w przypadku mało ambitnej osoby.

Porażka działań na pierwszej linii, nie oznacza, iż stajemy się bezradni. Zawsze możemy udać się do kierownika projektu testowego, któremu przedstawimy problem wraz z stosownymi argumentami, motywującymi konieczność zmiany. Oczywiście, jeżeli pójdziemy ocierać łzy, gdyż odrzucono nam wniosek to nic nie wskóramy. W takiej sytuacji warto zastosować drobny chwyt, polegający na prośbie o konsultacje tematu w oparciu o autorytet szefa zespołu. Jako, że odpowiada on za całość testów i pewien zakres jakości produktu, z całą pewnością poruszy ten problem na forum kierowniczym.
W ten sposób zabezpieczamy się przed zarzutem o ignorancje i słabą kreatywność, w przypadku jakichkolwiek zażaleń klienta w tym temacie. Ponad to, możemy zyskać kilka dodatkowych punktów i ugruntować relacje z przełożonymi.
Zasadniczo, chyba najważniejszym elementem będzie satysfakcja z wyników (efektów) pracy.
Zaiste testerowi zostanie przydzielone kolejne zadanie bez zmian w harmonogramie, ale cóż, ambicja kosztuje.

Przed przystąpieniem do testowania jakichkolwiek poprawek, tester winien odtworzyć błąd - w przypadku zgłoszeń z zewnątrz. Zasymulowanie błędu daje nam obraz, co było nie tak i w jakich okolicznościach to zaszło. W takiej sytuacji testowanie poprawki nie powinno sprawić większych problemów.
Natomiast, jeżeli nie jesteśmy w sanie z jakiś przyczyn wykonać replikacji błędu, a może się tak zdarzyć, to powinniśmy salwować się ucieczką.
Oczywiście jest to nieprawdą. Skoro została wykonana zmiana, to znaczy, że coś było na rzeczy (błąd można zazwyczaj podejrzeć u klienta). Nie pozostaje nam nic innego, jak zebranie wszelkich informacji o emisji i przetestowanie zmian na "czuja". Ryzyko jest znacznie większe aniżeli w przypadku replikacji błędu, ale też nie możemy zaniechać w ogóle testów, gdyż nowa emisja może zawierać błędy regresywne (powstałe na skutek produkcji poprawki).

Oprogramowanie a sieci komputerowe
Testy oprogramowania żądzą się swoimi prawami i mimo wielu podobieństw do testów sieci komputerowych, należy je rozpatrywać osobno.

Sieci analizuje się w oparciu o stos ISO/OSI, tudzież TCP/IP. Według tego modelu także przeprowadza się testy. Najpierw system okablowania strukturalnego (pasywna cześć infrastruktury), później sprzęt aktywny oraz komunikację między stacjami i serwerami. Następnie testuje się usługi oraz procesy biznesowe, jakie ma obsłużyć sieć. Natomiast oprogramowanie (bazy danych, interfejsy, aplikacje wspomagające) realizuje "biznes".

Sieć ma to w "nosie" czy prześle do 3000 terminali poprawny kod waluty, czy też odpowiednią wartość salda czyjegoś rachunku. Jej zadaniem jest zrobić to szybko, bezpiecznie i tam gdzie nadawca sobie życzył. Sieć teleinformatyczna z rozkazem nie ma prawa dyskutować, dopóki ma środki i możliwości do jego wykonania - nie myśli nad sensem wysyłanej informacji.

Wyjątkiem są systemy operacyjne urządzeń aktywnych (router, switch) oraz aplikacje serwerów np. DNS, DHCP. Funkcjonuje ono na potrzeby działania sieci i bez ich udziału nie będzie ona w stanie świadczyć usług na rzecz "oprogramowania właściwego".

Sieci komputerowe możemy rozpatrywać w kilku podstawowych kategoriach: wydajność, bezpieczeństwo danych i ciągłości pracy, skalowalność oraz redundancja. Są to podstawowe kryteria w oparciu, o które możemy planować rozwój infrastruktury.

Z oprogramowaniem jest nieco inaczej. Zasadniczo nie stosuję wobec aplikacji terminu rozwój, gdyż wybitnie w tym przypadku mi to nie pasuje. Wolę mówić, iż oprogramowanie dojrzewa. Każda implementacja nowej funkcjonalności, udoskonalanie już istniejących modułów, powstawanie oprogramowania wspomagającego software zasadniczy, zwiększa wartość systemu. Naturalnie, że z biegiem czasu system się "rozrasta". Jest to koszt, który trzeba ponieść za proces dojrzewania.

O cechach tak owego oprogramowania można by napisać osobny artykuł. Dlatego pominę ten wątek, analogicznie postąpiłem z metodologią testów.
Tym niemniej dojrzały system realizuje procesy biznesowe po optymalnych kosztach jego obsługi. Według mnie nie powinien być on hermetyczny. Powinien zapewniać możliwość dodawania (modyfikacji) nowych funkcji, wynikających np. ze zmian prawnych. Być może teraz narażę się pewnym osobą, ale uważam, że oprogramowanie powinno być otwarte na kooperację z aplikacjami obcymi (innych producentów), nawet jeśli sami mamy podobną aplikację.

Bardzo dobry interfejs, nie jest gwarantem dojrzałego oprogramowania. Proces udoskonalania (optymalizacji) aplikacji trwa latami. W szczególności jest to widoczne przy oprogramowaniu pisanym na zamówienia dla dużych podmiotów.

Uzupełnienie
Walidacja oprogramowania - sprawdzamy, czy oprogramowanie jest zgodne z oczekiwaniami użytkownika.
Weryfikacja oprogramowania - badamy, czy produkowane oprogramowanie jest zgodne ze specyfikacją.
Testy akceptacyjne mogą być wykonywane dla oprogramowania zamówionego z półki lub przygotowanego na zamówienie.


Rafał Pawlak


[1] http://erudis.pl/, Piotr Kochański, "Jak usprawnić proces testowania oprogramowania: procedury, metodologia i narzędzia".