Marzeniem każdego programisty jest napisanie takiego kodu, który od samego początku będzie w pełni funkcjonalny i kompletny. Tymczasem może okazać się, że stworzonemu przez niego programowi daleko do doskonałości. Testowanie oprogramowania na etapie jego tworzenia stanowi nieodzowną pomoc. Pozwala na wychwycenie błędów, które można skorygować. Dzięki temu klient otrzymuje produkt, który jest satysfakcjonujący, a firma może uniknąć przykrych konsekwencji.
Testowanie? A co to?
Dzisiaj trudno wyobrazić sobie jakąkolwiek dziedzinę naszego życia bez dedykowanej dla niej aplikacji. Począwszy od małych programów służących głównie rozrywce aż po wielofunkcyjne i pełne licznych połączeń zewnętrznych oprogramowanie. Proces powstawania programu to nie tylko pisanie skryptu, który ma zadziałać. To mozolna praca licznych zespołów, które zajmują się uzgodnieniami z klientem, tłumaczą je na język techniczny, planują strukturę programu, piszą skrypt, projektują interfejs aż po testerów, których zadaniem jest wypróbowanie działania skryptu i wychwycenie jego niedoskonałości.
Testowanie oprogramowania to – najprościej mówiąc – nic innego jak kontrola jakości. W środowisku programistów znane jest pojęcie „Quality Assurance”, czyli zapewnienie jakości. Testerzy weryfikują poprawność działania aplikacji. Ich zadaniem jest również zbieranie informacji na temat oprogramowania. Do takich informacji należą na przykład sygnały docierające od użytkowników programu wprowadzonego na rynek. Im bardziej zgłoszenia użytkowników są uzasadnione, tym bardziej do pracy powinien przystąpić zespół QA.
Testować można już sam pomysł na program. Testować można stworzoną dokumentację. Testować można kod źródłowy. Testować można funkcjonalność programu. Testować można interakcje pomiędzy systemami. Możliwości jest naprawdę wiele. Jednak nawet najdrobniejsze testy mają ogromne znaczenie dla osiągnięcia sukcesu zakładanego przez twórców oprogramowania.
Metody testowania
Do testowania oprogramowania stosuje się dwie metody. Pierwsza z nich to metoda „czarnej skrzynki” (ang. black-box testing). Polega ona na fizycznym sprawdzaniu oprogramowania. W metodzie czarnoskrzynkowej nie analizuje się kodu źródłowego. Dużo większe znaczenie ma wykrycie błędów zgodności funkcjonalności oraz poszczególnych komponentów z tym, co zostało zapisane w dokumentacji. Testy te nazywa się testami funkcjonalnymi. Natomiast testy niefunkcjonalne mają za zadanie wykazać bezpieczeństwo danych, obciążenie systemu czy też poprawność osadzenia komponentów w środowisku programu.
Drugą metodą jest metoda „białej skrzynki” (ang. white-box testing). Tester podaje na wejściu zdefiniowane dane, po czym sprawdza przejście wszystkich możliwych ścieżek oprogramowania. Test białoskrzynkowy pozwala na weryfikację, czy wykonanie akcji wywołuje następne akcje, jakie zostały założone w architekturze kodu.
Kiedy testować?
Właściwa odpowiedź brzmi: zawsze. Testowanie oprogramowania ma znaczenie nie tylko przed wprowadzeniem produktu na rynek. Testy przeprowadzane przed udostępnieniem oprogramowania wykazują błędy i wady na etapie jego powstawania; powodują, że finalny produkt wzbudza zaufanie wśród użytkowników; pozwalają na uniknięcie awarii, które mogą być powodem kosztów ponoszonych na prace naprawcze; są źródłem efektywności aplikacji, co gwarantuje zadowolenie klientów i wzrost zaufania wobec firmy.
Kod jest żywym organizmem. Wraz z rozwojem technologii może potrzebować zmiany, unowocześnienia czy uzupełnień. Nowe wersje systemów operacyjnych mogą spowodować konieczność wprowadzenia istotnych zmian w architekturze kodu. Jest zatem oczywiste, że taki unowocześniony kod trzeba przetestować zanim odda się aplikację użytkownikom. Natomiast szczególnie wśród użytkowników biznesowych mogą pojawić się dodatkowe oczekiwania wynikające ze zmian zachodzących w ramach rozwoju działalności. Dodawane kolejne funkcjonalności bez wątpienia poddać należy testom.
Kilka głośnych błędów oprogramowania
W latach osiemdziesiątych firma AECL, producent maszyn do naświetlania, borykała się z poważnymi problemami w funkcjonowaniu swoich urządzeń. Kilka osób poddanych naświetlaniu zmarło w wyniku zabiegów. Po długim dochodzeniu firma przyznała, że przeprowadzono zbyt mało testów. W trakcie śledztwa ujawniono, że oprogramowanie stworzyła jedna osoba. Błąd był wynikiem pominięcia przez nią jednego wiersza kodu. Brak dbałości o prawidłowość i kompleksowość testów doprowadził do poważnych konsekwencji.
Innym przykładem błędu, który mógł zostać wychwycony i usunięty w fazie testów, jest błąd zwany „millenium bug”. Polegał on na tym, że programiści, w ramach oszczędności, postanowili zapisywać w programach komputerowych oznaczenie roku pod postacią liczby dwubajtowej. W ten sposób wraz z nadejściem roku 2000 niektóre systemy zaczęły błędnie podawać datę: 1 stycznia 1900 roku. Inne systemy uległy po prostu awarii. Tego błędu również można było uniknąć w procesie testowania.
Europejska Agencja Kosmiczna (ESA) przeznaczyła 7 mld dolarów oraz 10 lat pracy na budowę rakiety Ariane-5, która 4 lipca 1996 roku 30 sekund po starcie zboczyła z kursu i eksplodowała. Przyczyną był całkowity brak testów oprogramowania, które po prostu skopiowano z rakiety Ariane-4, gdzie doskonale się sprawdziło. Jednak nowa rakieta miała szybsze silniki. Oprogramowanie zaczęło generować wyższe liczby, co skutkowało błędem konwersji danych między 64-bitowymi danymi zmiennoprzecinkowymi a 16-bitowymi całkowitymi. Wynik konwersji danych był zbyt duży i spowodował przepełnienie, czego skutkiem było zniszczenie rakiety.
Testowanie wewnętrzne czy outsourcing?
Testowanie oprogramowania można przeprowadzić własnym zespołem QA. Jednak powierzenie testów zewnętrznemu usługodawcy jest z punktu widzenia biznesowego znacznie korzystniejsze. Gwarantuje wyższy poziom obiektywizmu, wysoką jakość usługi wynikająca z profesjonalizmu testerów. Testerzy, obok posiadanego przygotowania, dysponują doświadczeniem i gruntowną znajomością procesu przygotowania oraz przeprowadzania testów oprogramowania. Ostatecznie outsourcing lub konsulting IT jest ekonomiczniejszy. Przygotowanie własnego zespołu QA wymaga znacznych kosztów, pomijając kwestię czasu, jaki należałoby poświęcić na ich wyszkolenie.
