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.

Zachęcamy do skorzystania z bezpłatnej prenumeraty
elektronicznej magazynu Computerworld!

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.

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.

Jeżeli chcesz uzyskać dostęp do dalszej części artykułu podaj adres e-mail

Dołącz do dyskusji
Bądź pierwszy i zostaw komentarz.