Shift-Left Testing - Czyli Jak Zoptymalizować Proces Testowania Oprogramowania

Podczas tworzenia oprogramowania chcemy, żeby jego wydajność i jakość szły w parze ze zmniejszaniem kosztów. Co może w tym pomóc? 
Rozwiązaniem może być podejście shift-left testing, dzięki, któremu możemy znajdować defekty we wczesnym etapie rozwoju oprogramowania. Dziś omówimy szczegółowo ryzyka, z jakimi tester musi się mierzyć podczas realizacji projektu i w jaki sposób “przesunięcie w lewo” pozwala nam na zoptymalizowanie cyklu pracy.

Z tego tekstu dowiesz się:

1. Jakie są ryzyka testingu w modelu kaskadowym
2. Z czym musi mierzyć się tester w metodykach zwinnych (Agile)
3. W jaki sposób testing shift-left optymalizuje proces rozwoju oprogramowania
4. 4 metody shift left testingu
5. Czy shift left testing jest rozwiązaniem przydatnym w codziennej pracy testera

Ryzyka Testingu W Modelu Kaskadowym

W modelu kaskadowym (Waterfall), gdzie kolejne fazy projektu następują po sobie, etap testowania przypada dopiero po fazie planowania, analizy, projektowania, developmentu (zatem jest przesunięte w prawo na linii z kolejnymi etapami prac nad produktem), co oznacza w praktyce, że wykrywanie defektów odbywa się dość późno, na już gotowym produkcie, a co za tym idzie ich naprawa jest kosztowna, czasochłonna i obarczona ryzykiem wpływu zmian na już gotowe elementy. 

Ryzyka Podczas Testowania Oprogramowania - Metodyki Zwinne

W popularnych dzisiaj metodykach zwinnych  przykładem której jest Scrum  ryzyko jest dość podobne. Różnica polega na cykliczności tego podejścia. Pracując w tzw. “sprintach” testy wykonuje się na poszczególnych etapach tworzenia produktu. Pozwala to na szybsze zidentyfikowanie problemu, niż w przypadku zmagania się z ogromem bugów w ostatecznej wersji.

Praca testera oprogramowania stanowi swoisty wyścig z czasem: kiedy deweloperowi przedłuża się praca nad funkcjonalnością, tester czeka na podjęcie pracy nad nią. W rezultacie,  czas na testy się skraca. Prowadzi to do sytuacji, w których po wykryciu defektu  deweloper ma już mało czasu na jego poprawę.-nie mówiąc już o czasie na retest przez zespół testerski. Tak wąskie ramy czasowe mogą  negatywnie wpłynąć  na  końcową jakość produktu. Pod tak ogromną presją łatwo również o nieuwagę.

Przesunięcie W Lewo - Czyli Jak Zoptymalizować Testowanie Oprogramowania

Aby uniknąć tego typu sytuacji ważnym jest, by wprowadzić proces testowania już na początku procesu rozwoju oprogramowania. Oznacza to, że odbywać się on będzienie po fazie programowania, ale przykładowo  już na etapie planowania i analizy wymagań. Dzięki takiemu podejściu zespół testerski ma możliwość wychwycenia błędów związanych z bazową logiką biznesową już we wczesnym etapie rozwoju produktu. Naprawa błędu na etapie tworzenia wstępnej dokumentacji jest nieporównywalnie tańsza niż naprawa defektu w trakcie developmentu.

W innym wypadku przebudowa systemu może opóźnić jego release i podnieść znacząco koszty. Przypuścmy, że że dwa szalenie ważne funkcjonalnie elementy systemu wzajemnie się wykluczają w jakimś zakresie.  My z kolei już przecież ponieśliśmy koszt developmentu i implementacji tych elementów oraz koszt ich testów. Teraz zaś dodatkowo podnosimy  koszty związane z ponowną analizą, developmentem i kolejnej fazy testingowej. 

Innym, równie obrazowym przykładem tego problemu mogą być testy dostępności. Na etapie projektowania designów warto zaangażować zespół testerski do weryfikacji mockupów, chociażby pod kątem czytelności (kontrastu) elementów. Dzięki temu możemy łatwo uniknąć kosztów poprawy takich elementów.

Podsumowując, “przesunięcie w lewo” wpływa korzystnie na pracę testerów poprzez:

• Lepszą współpracę
• Lepszą komunikację
• Zwiększoną wydajność
• Zmniejszone ryzyko opóźnień lub niepowodzeń projektu
• Cenne informacje zwrotne i spostrzeżenia
• Lepsza jakość produktu końcowego
• Płynna praca między programistami i testerami
• Rozwój oprogramowania z myślą o jakości i wydajności

​​​​​​​4 Metody Shift-Left Testingu

Wśród testów opartych na metodologii shift-left możemy wyróżnić cztery podtypy. Ich kolejność obrazuje chronologiczny postęp tej metodyki. Każda z nich ma również nieco inne zastosowanie w zależności od projektu, do którego są przeznaczone.

Tradycyjny (Traditional Shift-left Testing)

Tradycyjny Shift-Left testing pojawił się jako pierwsza odpowiedź na potrzebę przeprowadzania testów oprogramowania. Metodyka ta przesuwa nacisk na testy jednostkowe i integracyjne z pomocą testów API. W rezultacie, obserwujemy przełożenie wagi całości procesu na testy na poziomie systemu.  

Stopniowy/ Przyrostowy (Incremental Shift-left Testing)

Tradycyjny shift left testing z biegiem czasu ewoluował w testing przyrostowy. Jest to metodyka odpowiednia dla dużych i złożonych systemów, w szczególności tych, które wykorzystują wiele zasobów sprzętowych. Czynności testowe są stopniowo przenoszone do wcześniejszych etapów rozwoju oprogramowania, zaczynając od fazy developmentu i cofając się do wcześniejszych etapów.

Agile/DevOps Shift-left Testing

Ta forma testowania w ostatnich latach zyskuje na popularności dzięki możliwości wczesnego reagowania na bugi w projektowanym oprogramowaniu. Agile/DevOps Shift Left Testing kładzie nacisk na ciągłe i częste testowanie w wielu sprintach w trakcie rozwoju oprogramowania. Proces ten w znacznym stopniu opiera się na dobrej komunikacji i współpracy każdego członka zespołu.

Testing Oparty na modelu (Model-Based Shift-left Testing)

Ta forma testowania oprogramowania rozpoczyna się od fazy zbierania wymagań. Sprawia to, że  model ten pozwala na najwcześniejsze rozpoznanie problematycznych miejsc w kodzie  jeszcze przed rozpoczęciem tworzenia oprogramowania. Testerzy tworzą graficzny model reprezentujący zachowanie oprogramowania i używają zautomatyzowanych narzędzi do testowania modelu. Pozwala to sprawdzić różne scenariusze i zweryfikować projekt przed rozpoczęciem prac.

źródło: https://www.adservio.fr/post/benefits-types-of-shift-left-testing

Podsumowanie 

Testując wcześnie i często jesteśmy w stanie już na początkowych etapach tworzenia oprogramowania zapewnić jego jakość. Zespół testerski jest szybciej angażowany w prace nad projektem, co przekłada się na szybsze wykrycie zagrożeń a co za tym idzie na ich zapobieganie i minimalizowanie kosztów naprawy bądź przebudowy finalnego produktu.

---

Interesuje Cię tematyka testowania oprogramowania? Zobacz inne nasze wpisy:

1. Czym jest TDD?
2. Refaktoryzacja kodu - gdy aplikacja wymaga poprawy
3. Czym jest Proof of Concept w rozwoju oprogramowania?