Paweł Goleń, blog

Bo żeby testy można przeprowadzić...

Istnieje jeden podstawowy warunek przeprowadzenia testów. Musi istnieć obiekt testów. Wydaje się to wymaganiem prostym do spełnienia, ale wcale tak nie jest. Często pojawiającym się problemem jest to, że testowana aplikacja co prawda została dostarczona przez dostawcę, ale:

• nie działa,
• jest niepełna,
• ma poważne błędy funkcjonalne,

Jeśli aplikacja nie działa, to w ogóle nie ma o czym mówić, sprawa jest jasna, warunek stopu został osiągnięty. Bardziej złożona jest kwestia w pozostałych dwóch przypadkach. Co jeśli aplikacja jest niepełna? Czy testy takiej aplikacji można przeprowadzać i czy są one sensowne? Odpowiedź tutaj brzmi: to zależy. Jeśli aplikacja jest modularna i później dostarczone moduły nie wpłyną na działanie już istniejącej funkcjonalności, testy można przeprowadzać. Jeśli jednak dostępna jest niepełna funkcjonalność w obrębie poszczególnych modułów i będą one dalej rozwijane, to testy nie mają sensu. Dlaczego? Z tego samego powodu co w przypadku trzecim, gdy aplikacja nie działa do końca prawidłowo. Jeśli testy mają mieć sens, to powinny odbywać się już na ukończonym produkcie, a nie na jego wersji rozwojowej, która z dnia na dzień się zmienia. Każda zmiana może wprowadzić nowe podatności, wystarczy by na istniejącej formatce pojawiło się jedno nowe pole, w którym nie działa walidacja i może się okazać, że pojawia się XSS czy sqlinjection. Teoretycznie jeśli istniałby change log, to na jego podstawie można byłoby określić zmiany, które zostały wprowadzone do aplikacji i w kolejnej turze testów przetestować tylko zmiany. W praktyce rejestr zmian nie jest prowadzony w postaci wystarczająco szczegółowej, w związku z czym tak naprawdę nie wiadomo co się konkretnie zmieniło i co należałoby w związku z wprowadzonymi zmianami przetestować.

W związku z powyższym testy bezpieczeństwa aplikacji, lub poszczególnych modułów, jeśli testowany jest większy system, powinny być przeprowadzane po ukończeniu testów funkcjonalnych, w chwili, gdy moduł jest stabilny. W tym miejscu następuje naturalna konkurencja między testami bezpieczeństwa i testami funkcjonalnymi. Osoby odpowiedzialne za testy funkcjonalne mogą argumentować, że poprawka błędu bezpieczeństwa może spowodować błąd funkcjonalny. To prawda, trudno tutaj znaleźć rozwiązanie, które zadowoliłoby wszystkich uczestników złożonego projektu, jakim jest produkcja, testowanie i wdrożenie oprogramowania. Warto jednak zastanowić się jaki błąd jest "gorszy" w swoich skutkach, błąd funkcjonalny, czy błąd bezpieczeństwa.

Optymistycznie zakładamy, że nie będzie błędów

Często popełnianym błędem przy konstrukcji harmonogramów jest założenie, że dostarczony system ni będzie zawierał błędów. Nie chodzi tutaj wyłącznie o błędy związane z bezpieczeństwem, ale również kwestie funkcjonalne. Często można spotkać się z sytuacją, w której na testy przewidziany jest tydzień czasu, a zaraz po tym tygodni następuje go live!. Tylko co, jeśli po tym tygodniu się okaże, że aplikacja nie spełnia wymagań funkcjonalnych i przy okazji jest dziurawa jak sito? Gdzie czas na poprawki? Wbrew pozorom opóźnienie uruchomienia produkcyjnego często jest niemożliwe, na przykład dlatego, że wykupiona została już kampania reklamowa, wydrukowane ulotki, zorganizowana impreza... Ja rozumiem, że takie błędy w swojej naiwności można popełnić raz, dwa, ale popełnianie ich ciągle, mimo że wykonawca wielokrotnie pokazał, że z terminowością i jakością produktu ma poważne problemy, dziwi mnie. Swoją drogą warto tu wspomnieć o czymś, co się nazywa Evidence Based Scheduling. W skrócie jest polega to na obserwowaniu odchylenia między deklarowanym terminem ukończenia zadania, a jego rzeczywistym czasem trwania i wykorzystanie tej wiedzy do "urealniania" proponowanych harmonogramów.

Ale czy testy na końcu to nie za późno?

Czasami za późno... Szczególnie wtedy, gdy bezpieczeństwo nie jest uwzględniane w procesie produkcji systemu. Jeśli po zakończeniu testów funkcjonalnych miejsce ma pierwszy test bezpieczeństwa, to może się okazać, że aplikacja nie nadaje się do wdrożenia, zawiera nie tylko błędy implementacji, ale przede wszystkim jest źle zaprojektowana. W takiej sytuacji ciężko mówić o usuwaniu podatności, raczej aplikację należy stworzyć (przynajmniej częściowo) od nowa. Jak z tym walczyć? W przypadku większych systemów można wcześnie w projekcie uwzględnić krótki rekonesans dotyczący bezpieczeństwa aplikacji. Nie musi on być szczególnie długi, kilka dni roboczych pozwoli na stwierdzenie, czy twórca aplikacji stosuje dobre praktyki i tworzy w miarę bezpieczne aplikacje, czy też dostarczona próbka dowodzi, że dostawca nie bardzo wie co robi. Tutaj zespół testujący może oddać się "radosnemu bughuntingowi" przyglądając się aplikacji i sprawdzając miejsca, w których, na podstawie wcześniejszych doświadczeń, członkowie zespołu podejrzewają, że może być ŹLE. Zresztą taka faza z powodzeniem może być stosowana również w późniejszych testach, poświęcenie czasu na ogólne zapoznanie się z aplikacją pozwala zobaczyć las. Czasami okazuje się nawet, że błędy/podatności znalezione w tej fazie są jedynymi znaleziskami i nic więcej nie udaje się w aplikacji odkryć, mimo jej dekompozycji i monotonnego sprawdzenia całości parametr po parametrze.

Ale można jeszcze inaczej...

Testy penetracyjne można uczynić integralną częścią procesu tworzenia aplikacji, ale to wymaga zmiany świadomości u dostawców oprogramowania. Co prawda niektórzy twierdzą, że dostarczana aplikacja przechodzi wewnętrzne testy bezpieczeństwa, ale zwykle jakoś tego nie widać...