blog.testowka.pl

Testowanie wymagań

opublikowany przez 18, Maj, 2009, w kategoriach Agile, Praca, Scrum, Testowanie, Zarządzanie

„Testowanie wymagań i chodzenie po wodzie jest łatwe pod warunkiem, że są zamrożone”

Planując testy akceptacyjne staram się oprzeć na wymaganiach, które według klienta powinny zostać spełnione by aplikacja była akceptowalna. To jest oczywiste. Jednak co zrobić, gdy wymagania zmieniają się wraz z rozwojem aplikacji, jak to często w projektach Agile’owych i nie tylko bywa? Standardowy model „V” nie nadaje się tutaj do  zastosowania, gdyż zakłada on planowanie testów akceptacyjnych, a co za tym idzie implementację tych testów w odpowiedniej, stosunkowo wczesnej fazie projektu. Przy takim rozwiązaniu gdy testy są wcześnie zaimplementowane a wymagania nie są do końca sprecyzowana (ulegają ciągłym zmianom) utrzymanie testów staje się zbyt kosztowne.

Testowanie zmieniających się wymagań nigdy nie będzie proste i nigdy nie będzie tanie, chociażby  nie wiem jak te testy były zaplanowane i napisane/zrealizowane. Najbardziej optymalnym rozwiązaniem w takiej sytuacji jest powrót do podstaw i rozbicie aplikacji na poszczególne podsystemy o określonych, zawężonych funkcjonalnościach, maksymalnie oddzielone od reszty aplikacji, po czym doprowadzenie kolejno jeden po drugim każdy z tych podsystemów do oczekiwanego akceptowalnego stanu. W innym wypadku wpadniemy w „Cowoboy Coding” z „Bug Huntingiem”, co obrazuje się w sposób następujący: testerzy znajdują błędy w różnych częściach aplikacji, developerzy je poprawiają, dodają nową funkcjonalność psując coś w innym miejscu, testerzy lub automatyczne testy znajdują te błędy, deweloperzy  znów poprawiają psując coś innego i tak w kółko. Nie da się ogarnąć projektu bez zaplanowanej metodologi działania. Wszelkie poprawki i zmiany powinny być z góry zaplanowane i w odpowiedni sposób przetestowane przed wysłaniem ich na serwer, gdzie następują testy integracyjne. Bardzo istotny jest obieg informacji – co, kto i dlaczego robi, oraz co jeszcze ktoś inny będzie musiał  z tym zrobić. W agile testowanie w dużym stopniu opiera się na testach poszczególnych funkcjonalności, które wykluczają większość błędów nie wynikających z problemów integracyjnych.

Słyszałem o aplikacjach powstających metodą „Wielkiego Wybuchu”, która polega na tym, że wszyscy nagle siadają i coś kodują, starając się nie wchodzić sobie w drogę. Zazwyczaj kończy się to wielkim bałaganem, który czasem nawet działa ale nikt nie jest z niego zadowolony. Najgorsze jednak w tym wszystkim jest to, że jeśli przyjdzie zrobić jakąś zmianę, albo poprawić jakieś błędy to nagle okazuje się, że wiele fragmentów kodu jest zduplikowanych, albo zależy od nich zbyt wiele innych części aplikacji.

Rozwiązaniem większości problemów jest skrupulatne planowanie oraz pozostawienie możliwości przyszłego rozwoju dla każdej części aplikacji w każdym możliwym kierunku. Ważnym jest też dobór odpowiedniej metodologii. Dzięki tym rozwiązaniom nawet najbardziej zmienne wymagania nie są nam straszne. Jeśli wymagania się zmieniają, wracamy do odpowiedniej części aplilkacji i ponownie pracujemy nad nią, aż nowe wymagania zostaną spełnione, nie ingerując w inne części projektu.


2 Comments for this entry

  • Rico

    Kolego bardzo fajne te twoje artykuly ale nie da sie czytac w tych kolorach 😉 Musialem przekleic do worda.

  • streser

    Tak wiem o tym, niestety jest to standartowy szablon z wordpresa, odrobinę, przeze mnie dopracowany… Trwają prace nad własnym szablonem i nad postem odnośnie właśnie czytelności na stronach, na razie mógłbym podać swojego bloga jako przykład negatywny ;-)… Na razie mogę jedynie powiedzieć: „Przepraszam, mam nadzieję, że gdy zobaczycie nowy layout to moje grzechy zostaną przebaczone” 😉

Skomentuj