Agile a kłopoty z testowaniem wydajności

Natura metodyki Agile sprawia, że w prowadzonych zgodnie z nią projektach programistycznych pojawia się problem, jak prowadzić testy wydajności tworzonego oprogramowania. Co ciekawe, jeśli potraktować testy wydajności jako oddzielny projekt, doskonale nadają się one do realizacji według wspomnianej metodyki.

Teoretycznie testy wydajności powinny iść jak bułka z masłem w projektach Agile. Po każdym sprincie ma się działający kawałek systemu i wiadomo dokładnie, jaka jest jego wydajność. Z testami nie powinno się więc czekać do zakończenia projektu, lecz prowadzić je na bieżąco, porównując z wymaganiami. Uproszcza to cały proces prowadzenia testów i rozwiązuje problem wynikający z tradycyjnego podejścia, które mówi, że testy należy prowadzić na gotowym systemie.

W praktyce założenia Agile nie zawsze działają. Z reguły weryfikację wydajności przekłada się na koniec projektu. Prawdopodobną przyczyną jest znane od dawna zjawisko: funkcjonalność ma pierwszeństwo przed wydajnością. W efekcie testy wydajności odkłada się na koniec projektu, tracą w ten sposób szansę zbudowania na podstawie wymagań odpowiedniego procesu inżynierii wydajności.

Zobacz również:

Problem skali

Podstawowym problemem jest brak skalowalności zespołów testerów, nawet jeśli pracują one efektywnie. Takie zespoły mogą dobrze funkcjonować w korporacyjnym środowisku, sprawdzając oprogramowanie przed uruchomieniem go w produkcji. Jednak problemy mogą pojawić się, jak tylko zostanie rozszerzony obszar testów wydajności (zaangażowanie zespołu we wczesnym etapie projektu, większa liczba produktów, konfiguracji, scenariuszy). Projekty Agile również odsłaniają ten problem, ponieważ wymagają testowania po każdym sprincie, z czym wiąże się sporo pracy.

Remedium jest dobrze znane: automatyzacja oraz nakładanie obowiązków związanych z wydajnością wszystkim osobom zaangażowanym w projekt. Niestety te sposoby nie są jeszcze szeroko stosowane. To, co czyni projekty Agile rzeczywiście trudnymi pod tym względem, to konieczność powtarzania dużej liczby testów. Do ich wykonania są potrzebne narzędzia, które wspierają automatyzację. Automatyzacja oznacza ciągłe testy wydajności, ale nie polega wyłącznie na korzystaniu z narzędzi (te zawsze stosuje się w takich testach). Celem jest automatyzacja całego procesu, włączając w to przygotowanie środowiska, uruchomienie testów i dostarczanie raportów z wynikami. W praktyce rzadko udaje się go osiągnąć, ponieważ automatyzacja testów wydajności jest znacznie bardziej skomplikowana niż automatyzacja testów funkcjonalności. Wymaga sporego wysiłku, ale nie jest niemożliwa.

Im krótsze sprinty, z których składa się projekt prowadzony według Agile, tym mniej zgodne z tą metodyką będą testy wydajności. I w drugą stronę, jeśli proces programowania będzie przebiegał bardziej kaskadowo, wtedy testy wydajności powinny być bardziej „zwinne”, aby dostarczać bardziej wartościowych wyników.

Mniejsze zadania, trudniejsze testy

Kolejną kwestią jest specyfika Agile, który zakłada dzielenie projektu na mniejsze zadania. Z punktu widzenie wydajności jest to utrudnienie, ponieważ testy związane z tym aspektem działania aplikacji z reguły obejmują cały projekt.

Nie ma standardowego podejścia określającego, jak powinny przebiegać testy wydajności w projektach Agile. Najczęściej sugeruje się, aby przedstawiać je jako opowieści użytkowników lub jako ograniczenia. Różnica między tymi dwoma podejściami polega nie na tym, jak definiowane są wymaga dotyczące wydajności, lecz jak są realizowane w trakcie prac programistycznych nad projektem. Z punktu widzenia ograniczeń opowieści użytkowników powinny się one składać z ograniczonej liczby zadań. Jednak testów wydajności nie można traktować w ten sposób, ponieważ z reguły obejmują one więcej niż jeden komponent i więcej niż jedną iterację.

Testy jako projekt

Termin Agile odnosi się do grupy metodologii tworzenia oprogramowania, które promują pracę przyrostową, otwartą współpracę oraz dostosowywanie procesów w miarę postępu prac nad projektem. To samo podejście można zastosować również do testów wydajności. Testy wydajności ze swojej natury bowiem wpasowują się dobrze w założenia Agile. Sformalizowane podejście może doprowadzić do przeoczenia różnych problemów z wydajnością. Natomiast testowanie małymi krokami czyni proces bardziej elastycznym, a efektywność testów wzrasta. Pomaga naukowe, badawcze podejście, szkodzi natomiast rutynowe wykonywanie kolejnych zadań. Jedyną sytuacją, kiedy formalne podejście może pomóc, jest testowanie dobrze znanego systemu (można je nazwać testami wydajności regresji).

Nie jest wykonalne zaplanowanie każde detalu testów od początku do końca projektu. Nigdy nie wiadomo, kiedy pojawią się problemy z wydajnością i jak będzie można im zaradzić. Owszem, należy mieć plan, ale powinien on być bardzo elastyczny. Testy powinny stać się iteracyjnym procesem, obejmującym również optymalizację i usuwanie problemów w bliskiej współpracy z programistami czy administratorami systemu i baz danych.

Testowanie wydajności mają charakter iteracyjny: po przeprowadzeniu testu otrzymuje się wiele informacji na temat systemu. Należy je przeanalizować, na tej podstawie wprowadzić poprawki do systemu i, jeśli to koniecznie, zmodyfikować plan dalszych działań. Przykładowo, po wykryciu istotnym problemu z wydajnością, należy wstrzymać dalsze testy aż do momentu usunięcia przyczyny.

<ramka>

W ramach szkoleń organizowanych przez Computerworld (www.computerworld.pl/konferencje?warsztaty) można poszerzyć wiedzę z zakresu prowadzenia projektów informatycznych. Doświadczeni prelegenci wprowadzą uczestników, m.in. w tajniki prowadzenia testów i definiowania wymagań.

</ramka>