Testowanie aplikacji i systemów - Testowanie w metodykach zwinnych AGILE. Podejście TDD.

1. W ostatnich latach wzrosła świadomość potrzeby testowania oprogramowania. Metodyki zwinne zwane często z języka angielskiego Agile development. Są to metodyki ukierunkowane na programowanie, czyli implementację. Przykładami metodyk zwinnych są SCRUM, XP (ang. Extreme Programming), DSDM (ang. Dynamic Systems Development Method). W większości przypadków oznacza to przejście z wypróbowanego modelu V do testowania zwinnego przy użyciu metodyki Scrum.

2. Agile to metodyka wytwarzania produktu w ramach krótkich faz (iteracji), ścisła, partnerska współpraca pomiędzy zamawiającym a wykonawcą, realizacja projektu przez ludzi o odpowiednich kompetencjach i dyscyplinie oraz elastyczność i otwartość na zmiany – możliwość korygowania założonego zakresu, budżetu i harmonogramu – w możliwie odformalizowany, prosty i uporządkowany sposób – na możliwie jak najwcześniejszym etapie.

3. Metoda Waterfall realizacji projektów nie sprzyja kulturze współpracy stron oraz komunikacji w ramach bieżących prac projektowych, co nie pozostaje bez wpływu na rezultat końcowy. Pomiędzy stworzeniem projektu, a jego realizacją, mija znaczny czas. W czasie realizacji projektu, współpraca oraz komunikacja pomiędzy stronami są znikome. Potrzeba wprowadzenia zmian lokalizowana jest dopiero na etapie testów obejmujących całość dostarczanego rozwiązania informatycznego.

4. Realizacja projektów informatycznych w modelu Waterfall wiąże się ze znaczną ekspozycją na ryzyka:

• braku możliwości albo znaczących trudności w dokonaniu zmiany zakresu projektu
• dostarczenia zamawiającemu rezultatu innego niż się spodziewał 
• dezaktualizacji założeń, które spełnia dostarczony finalnie rezultat.

5. W modelu Waterfall produkt wytwarzany jest w ramach zamkniętych, długich etapów, z których każdy dedykowany jest jednorodzajowemu działaniu. Weryfikacja rezultatów prac ma miejsce po raz pierwszy dopiero na etapie testowania. W metodykach Agile, produkt wytwarza się w krótkich fazach (iteracjach), których każdorazowym rezultatem jest niewielki, ale działający fragment produktu, którego poprawność wykonania jest na bieżąco weryfikowana na zakończenie dedykowanej mu iteracji.

6. Agile traktuje zmiany jako oczywistą konieczność i posiada mechanizmy umożliwiające sprawną ich realizację. Waterfall skupia się na dostarczeniu zaplanowanego pierwotnie rezultatu, dlatego zmiana nie jest dla niego stanem naturalnym ani preferowanym. W modelu Waterfall kaskadowość prac pozwala ujawnić potrzebę zmiany na zaawansowanym etapie prac, co związane jest z istotnymi nakładami czasowymi oraz finansowymi.

7. W modelu Waterfall współpraca stron ma co do zasady ograniczony, sformalizowany i bardzo niesystematyczny charakter. W Agile współpraca stron oraz ich wzajemna komunikacja mają charakter stały i bieżący. Istotą współpracy oraz komunikacji jest również ich odformalizowanie oraz „spłaszczenie”, co pozwala na utrzymanie właściwego tempa obiegu informacji.

8. Czynniki zwinności to mechanizmy projektowe, których wdrożenie umożliwia zwinne podejście do realizacji produktu informatycznego. Do najważniejszych czynników zwinności należą: 

• możliwość wykonania produktu w krótkich fazach (iteracyjnie)
• elastyczna modyfikacja zakresu produktu
• rozliczanie dostarczanych prac w sposób przyrostowy
• odpowiednie ujęcie kontraktowe obszarów współpracy i współdziałania stron w ramach realizacji produktu
• odpowiednie ujęcie kontraktowe obszaru dotyczącego personelu zamawiającego i dostawcy
• mechanizmy kontraktowe umożliwiające zakończenie współpracy stron połączone z tzw. scenariuszami wyjścia.

9. TDD (Test-Driven Development) to technika tworzenia oprogramowania, w której główną ideą jest w pierwszej kolejności pisanie testów do nieistniejącej funkcjonalności, a dopiero potem napisanie kodu implementującego tę funkcjonalność.

Cykle życia TDD:

• napisanie przypadku testowego
• uruchomienie napisanego testu
• napisanie minimalnego kodu do przejścia testu
• refaktoryzacja kodu
• powtarzamy cykl

TDD na pewno nie sprawdzi się w przypadku małych, nieskomplikowanych projektów.

10. Zalety TDD:

• Poprawa jakości kodu: TDD zachęca do pisania kodu, który jest czysty, modułowy, łatwy do utrzymania i spełnia wymagania testów.
• Szybkie wykrywanie i naprawa błędów: TDD pozwala na znalezienie i eliminację błędów na wczesnym etapie procesu tworzenia oprogramowania, co zmniejsza koszty i czas związane z konserwacją.
• Lepsze zrozumienie wymagań: TDD wymaga od programisty, aby znał specyfikację kodu przed napisaniem go, co pomaga w precyzyjnym odzwierciedleniu wymagań biznesowych w kodzie.
• Większa produktywność i komunikacja: TDD sprzyja lepszej współpracy i komunikacji między programistami, testerami i klientami, a także umożliwia szybsze dostarczanie oprogramowania o wysokiej jakości.

Wady TDD:

• Większy nakład czasu i pracy: TDD wymaga od programisty, aby pisał testy przed kodem, co może być czasochłonne i trudne, zwłaszcza na początku projektu.
• Trudność w utrzymaniu testów: TDD może być skomplikowane, jeśli wymagania oprogramowania często się zmieniają lub są niejasne, co może prowadzić do konieczności aktualizacji lub pisania nowych testów.
• Potrzeba wsparcia organizacyjnego: TDD może być skuteczne tylko wtedy, gdy cała firma lub organizacja wspiera jego wdrażanie i zapewnia odpowiednie narzędzia, szkolenia i kulturę