O rynkowym sukcesie oprogramowania coraz częściej decyduje jego wysoka jakość, a nie cena. Jakość w dużej mierze zależy od testów. I tu pojawia się pytanie: czy lepiej oprogramowanie przetestować wewnętrznymi zasobami producenta czy zlecić to innej firmie.

Jakość, funkcjonalność oraz cena to najważniejsze kryteria podejmowania decyzji o zakupie oprogramowania. Użytkownicy coraz częściej rezygnują z produktu, jeśli jego jakość jest za niska. Producenci oprogramowania o tym wiedzą, dlatego zawsze próbują odpowiedzieć na pytanie, czy ich dzieło może być bardziej niezawodne i pracować wydajniej. Sukces zależy od umiejętności projektantów aplikacji i programistów, jednak ważniejszą rolę odgrywają testerzy oprogramowania. Kiedy faza produkcji dobiega końca, po stronie producentów często pojawia się szereg dylematów. Testy mogą spowolnić cały proces produkcji, nie wiadomo też czy lepiej wykonać je samemu czy zlecić to zadanie wyspecjalizowanej firmie. Testowanie bywa kosztownym i czasochłonnym procesem. Wykrycie błędów skutkuje oddaniem systemu z powrotem do produkcji, gdzie wprowadzane są poprawki, na co także potrzeba czasu. Ponoszone koszty są nieporównywalnie większe od kosztów modyfikacji wykonywanych w trakcie wytwarzania. Jeśli w fazie produkcyjnej coś idzie nie tak, takich iteracji może być kilka. W konsekwencji premiera produktu może odwlec się o kilka długich miesięcy. Dlatego producenci nierzadko ograniczają testy do „niezbędnego minimum”, oczywiście kosztem jakości. Liczą, że w ten sposób przyspieszą sprzedaż swojego produktu.

Poważne podejście do testowania wymaga czasu. Warto też pamiętać, że jest kilka rodzajów testów, z których każdy ma inny cel. Jeśli już w fazie produkcji nie przewidzi się oraz nie wykona odpowiednich analiz systemu, zawsze potem pojawiają się problemy – uważa Bartosz Kalinowski, prezes Edge Solutions, spółki która zajmuje się procesami SQA (wykonuje różnego rodzaju testy oprogramowania) dla producentów z kilkunastu krajów świata. Jakie najczęściej pojawiają się problemy? Od prozaicznych – kiedy coś nie działa, tak jak podano w specyfikacji, przez kłopoty większego kalibru, np. system nie wytrzymuje obciążenia w swoim naturalnym środowisku, pracuje wolno, zawiesza się. Odrębną grupę problemów są luki bezpieczeństwa, które czynią system podatnym na różnego rodzaju ataki (możliwość włamania, wycieku danych itp.). Obecnie jest tak duża konkurencja wśród dostawców aplikacji, że z pewnością zaniedbywanie testów nikomu się nie opłaca – nawet jeśli producent ma najlepszy dział produkcji. Straty spowodowane awariami, błędami i niezadowoleniem użytkowników wielokrotnie przewyższają nakłady przeznaczone na testy – uważa Bartosz Kalinowski. Być może coś w tym jest – Edge Solutions w ciągu roku potroiło liczbę swoich pracowników działu SQA, którzy zajmują się wyłącznie testowaniem aplikacji dla firm zewnętrznych.

Producenci często zadają sobie pytanie: testować systemy w ramach własnych struktur czy skorzystać z usług firmy zewnętrznej, która jest ekspertem w testowaniu. Zdania są podzielone, a punkt widzenia często zależy od przeznaczenia oprogramowania. Na przykład Pentacomp produkuje i wdraża systemy m.in. w strategicznych jednostkach administracji państwowej i największych przedsiębiorstwach. Przez wzgląd na zachowanie tajemnicy klientów spółka nie widzi wielu możliwości testowania tego rodzaju systemów na zewnątrz. W Pentacompie powstają rozwiązania na indywidualne zamówienie. Często objęte są one umowami o zachowaniu ścisłej poufności.

Dla tego typu projektów procesy produkcyjne, w tym testowanie, zorganizowaliśmy i utrzymujemy wewnątrz spółki. Ważne jest, aby zespoły realizujące testowanie w projektach nie podlegały kierownikom projektów, ale co najmniej dyrektorowi odpowiedzialnemu za ich realizację. Zwiększa to przejrzystość procesu testowania i ułatwia jego monitorowanie. Cele programistów i testerów są w pewnym sensie przeciwstawne. Ci pierwsi dążą do stworzenia bezbłędnego oprogramowania. Sukcesem tych drugich jest wykazanie, że w oprogramowaniu są błędy – mówi Wojciech Chybowski, wiceprezes Pentacompu. Jednocześnie przyznaje, że w przypadku produkcji oprogramowania o szerszym zastosowaniu, testowanie na zewnątrz mogłoby okazać się propozycją do rozważenia. W przypadku systemów dedykowanych ściśle jednemu podmiotowi, sam proces przekazywania informacji o tym produkcie firmie z zewnątrz mógłby trwać długo i sporo kosztować. W przypadku uniwersalnych rozwiązań, szczególnie tych o bogatej funkcjonalności użytkownika, wykonanie testów na zewnątrz mogłoby być bardziej opłacalne. Poza tym niektóre testy, na przykład bezpieczeństwa, wymagają zaawansowanej wiedzy, która w firmie może nie być dostępna. – dodaje Wojciech Chybowski.

Firmy, których głównym źródłem przychodów są testy aplikacji, przekonują, że outsourcing się opłaca. Jednym z głównych „argumentów za” jest posiadanie wypracowanego w trakcie wielu zleceń know how. Kolejnym argumentem jest kompleksowa specjalizacja, wiedza i wysoka elastyczność – z reguły dowolny typ testów może się rozpocząć natychmiast, a cały proces można konfigurować wedle woli producenta. W efekcie producent traktuje testowanie jako zewnętrzny projekt, którego cena w całości wliczana jest w koszty – bez ZUS-u, podatków dochodowych, zasiłków, wszystkich kwestii kadrowych.

Decydując się na outsourcing testów, producent może precyzyjniej zaplanować koszt. Poza tym może skoncentrować się wyłącznie na produkcji – nie musi tworzyć nowych miejsc pracy i utrzymywać infrastruktury niezbędnej do prawidłowego funkcjonowania działu testów. To są ewidentne oszczędności – podkreśla Bartosz Kalinowski. Korzyści wydają się być ewidentne, ale w praktyce każdy producent powinien sam ocenić, co bardziej się opłaca. Wiele zależy od specyfiki organizacji, typu produktów oraz faktycznych kosztów, jakie firma ponosi w obszarze testowania.

Wybrane rodzaje testów

Oprogramowanie można poddawać weryfikacji na wiele sposobów – każdy z nich ma za zadanie usprawnić produkt w innym obszarze.

Test funkcjonalny (blackbox) poddaje analizie działanie systemu od strony dostępnych funkcjonalności. Tester odgrywa rolę potencjalnego użytkownika aplikacji – bada dostępność i ergonomię funkcjonalności oraz rzeczywiste działanie produktu w odniesieniu do jego specyfikacji. Tego typu testy wykrywają błędy i niewłaściwe działanie, ale nie niosą informacji o przyczynach błędów.

Testy strukturalne (whitebox) weryfikują poprawność operacji wykonywanych przez system. Tester nie analizuje systemu z punktu widzenia użytkownika, lecz bada go od środka (m.in. strukturę kodu i jakość wykonywanych przez niego operacji). Tego rodzaju testy wymagają umiejętności programowania.

Testy integracyjne wykonuje się po połączeniu ze sobą kilku odrębnych aplikacji. Polegają m.in. na sprawdzeniu poprawności działania dostępnych w aplikacjach funkcjonalności oraz wzajemnego oddziaływania na siebie zintegrowanych aplikacji.

Testy obciążeniowe badają działanie i zachowanie systemu w sytuacji jego dużego obciążenia np. wielu zapytań do serwera w jednej jednostce czasu lub jednoczesnego zalogowania wielu użytkowników.

Testy wydajnościowe poddają analizie działanie i przepustowość aplikacji w warunkach zbliżonych do tych, w których ma być ona użytkowana.

Smoke test jest często punktem wyjścia do kolejnych faz testów. Polega na sprawdzeniu czy program się uruchamia, a następnie na określeniu dostępności interfejsu i właściwej reakcji na działanie użytkownika.

Testy regresyjne wykonywane są po wprowadzeniu do systemu zmian. Polegają na sprawdzeniu poprawności działania wszystkich jego obszarów – także tych, w których zmiany nie były wprowadzane. Pozwala to wykryć błędy będące niespodziewanymi efektami ubocznymi wprowadzonych zmian.

Testy bezpieczeństwa obejmują całą gamę technik testowania. Służą wskazaniu słabych punktów w oprogramowaniu, opisaniu zagrożeń lub wykryciu luk w warstwie bezpieczeństwa aplikacji.

Testowanie nie zawsze daje gwarancję usunięcia z programu wszystkich błędów. Ma jednak zasadniczy wpływ na jakość oprogramowania, która decyduje o skutecznej sprzedaży i utrzymaniu przy sobie klientów.