Mantra DevOps

Jeszcze nie tak dawno temu cykl życia oprogramowania w ogóle nie uwzględniał oddzielnej fazy testowania. Programiści pisali kod, potem sami go sprawdzali i analizowali pod kątem występowania błędów, naprawiali usterki i wypuszczali produkt na rynek.

Koncepcja wprowadzenia testowania oprogramowania jako oddzielnej fazy projektu była wprowadzana stopniowo, gdy okazało się, że defekty dostępnych na rynku produktów wpływają w znaczący sposób na budżety przedsiębiorstw. Zaczęto więc wprowadzać „testowanie funkcjonalne” i wydzielać odrębne grupy, których zadaniem było tylko testowanie produktu.
Branża zaczęła wykorzystywać model kaskadowy (wodospadu) do tworzenia oprogramowania, w którym cykl życia oprogramowania obejmuje sekwencje w kolejności Planowanie wymagań -> Projektowanie -> Implementacja (Programowanie) -> Testowanie -> Utrzymanie.

Model kaskadowy IT

Źródło: Waterfall Model (HINDI)

Posługując się tym modelem, cykl życia oprogramowania toczy się od lewej do prawej, a etap testowania jest na skraju (na końcu), po prawej stronie.

Koncepcja

Po pewnym czasie zorientowano się, jak duże znaczenie ma odpowiednie przetestowanie produktu oraz jakie słabości ma utrzymywanie procesu testowania po prawej stronie modelu. Koszty wykrytych defektów na tym późnym etapie były niezwykle wysokie. Naprawienie ich wymagało bardzo dużo wysiłku i zwyczajnie nie było już opłacalne.

Dochodziło do sytuacji, w których po wielu miesiącach projektowania i czasochłonnego kodowania, z powodu kluczowego błędu wykrytego pod koniec cyklu życia produktu, oprogramowanie nie mogło zostać wypuszczone na rynek i w efekcie firma ponosiła poważne straty finansowe.

W przypadku testowania produktu i wykrywania błędów właściwie na ostatniej prostej cyklu życia projektu albo wypuszczenie oprogramowania ulegało opóźnieniu, bo usterki trzeba było naprawić, albo lądowało w koszu, bo koszta i wysiłek potrzebne do usunięcia błędów były zbyt wysokie.

Wykres Software Development Phase

Źródło: Shift-left testing approach

Gdy uświadomiono sobie, że defekty wykryte wcześniej narażają firmę na mniejsze straty finansowe, zaowocowało to wielką rewolucją w branży oprogramowania i dało początek nowej koncepcji nazwanej „Shift-left”. Oznacza ona ni mniej, ni więcej, tylko przesunięcie fazy testowania ze strony prawej w stronę lewą i jednocześnie włączenie procesu testowania w każdy etap cyklu życia produktu. Przesunięcie testowania w lewo oznacza, że nie testuje się produktu tylko na końcu, ale na każdym etapie i proces ten jest ciągły (Continuous Testing).

Czym jest Shift-left Testing

Najważniejszym elementem zasady Shift-left jest to, że wspiera ona zespół testerski we współpracy ze wszystkimi interesariuszami już na wczesnym etapie rozwoju produktu. Dzięki temu są w stanie dokładnie zrozumieć wymagania i zaprojektować przypadki testowe, by pomóc wykryć usterki na bardzo wczesnym etapie produkcji.

Podejście to, to nic innego, jak znacznie wcześniejszy udział testerów w cyklu życia oprogramowania, co z kolei pozwala im zrozumieć wymagania, projekt oprogramowania, jego architekturę, kod źródłowy, funkcjonalności, dopytywać klientów o ich wizje i wymagania, zadawać trudne pytania analitykom biznesowym i programistom, szukać wyjaśnień i udzielać odpowiedzi, gdy to możliwe.

Takie zaangażowanie i stopień zrozumienia prowadzi testerów do uzyskania pełnej wiedzy o  produkcie, pozwala przemyśleć różne scenariusze testowe i zaprojektować je w czasie rzeczywistym na podstawie zachowania oprogramowania, co pomaga zespołowi zidentyfikować defekty lub słabe punkty jeszcze przed rozpoczęciem programowania.

Shift-left jest transformacją tego, w jaki sposób tworzymy oprogramowanie. Przez większą część mojej kariery pracowałam w sposób kaskadowy, w którym istniały etapy tworzenia oprogramowania, a następny etap nie rozpoczął się przed zakończeniem poprzedniego etapu – na przykład, gromadzenie wymagań, projektowanie, następnie rozwój, a następnie testowanie. Dzięki takiemu podejściu testowanie było zwykle ostatnim etapem przed udostępnieniem oprogramowania. Jednak przy bardziej nowoczesnym podejściu do rozwoju oprogramowania, krytyczne jest, aby testowanie odbywało się o wiele wcześniej w tym procesie, zasadniczo przesuwając się bardziej na lewo od etapów rozwoju, a nie na skrajnie prawy, jeden z ostatnich etapów.

Cytat z wypowiedzi Angie Jones, z wywiadu „It’s time for Testers to Own the Shift-left Narrative

Typy Shift-left Testing

Na stronie Wikipedia. The Free Encyclopedia znaleźć można podział Shift-left na typy. W tym artykule nie będziemy rozwodzić się nad tą kwestią. Chętnych odsyłamy pod podlinkowany adres, a w tym miejscu wymienimy typy tylko z nazwy, dla lepszego rozeznania w sprawie.
Typy Shift-left Testing:

  • Tradycyjny (Traditional Shift-left Testing)
  • Stopniowy/ Przyrostowy (Incremental Shift-left Testing)
  • Agile/ DevOps Shift-left Testing
  • Oparty na modelu (Model-Based Shift-left Testing)

Shift-left Testing w modelu kaskadowym

Kluczowe kwestie

  • Podejście „przesunięcia w lewo” skupia się na angażowaniu testerów nie tylko w krytyczne, ale właściwie we wszystkie etapy cyklu życia produktu. Dzięki temu testerzy mogą skupić się na wykrywaniu błędów, zapobieganiu im i kierowaniu biznesowymi celami programu
  • Shift-left zwraca uwagę na to, jak ważna jest rola testerów w projekcie. Dzięki temu znacznie wzrasta rola i odpowiedzialność zespołu testującego
  • Wraz ze zwiększaniem odpowiedzialności za całość wśród testerów, wzrasta koncentracja nie na „testowaniu oprogramowania w celu identyfikacji błędów”, a na aktywną współpracę z zespołem od pierwszych momentów tworzenia produktu, aby zaplanować i zbudować solidną i skuteczną strategię testowania, zapewniając doskonałe kierownictwo testowe i wskazówki dla zespołu, skupiając się na długoterminowej wizji produktu, a nie tylko na wzięciu na siebie odpowiedzialności za prace testowe.
  • Podejście to zapewnia możliwość, by w pierwszej kolejności zaprojektować testy koncentrujące się całkowicie na doświadczeniu klienta i jego oczekiwaniach, co z kolei umożliwi twórcom opracowanie oprogramowania na podstawie tych testów, a tym samym lepsze zaspokojenie potrzeb klienta.
  • Shift-left nie kończy się wyłącznie na testerach. Continuous Testing umożliwi programistom przejęcie większej odpowiedzialności za ich kod i zwiększenie odpowiedzialności za testowanie.
  • Zachęca testerów do zaadaptowania podejścia BDDTDD opartego na testach, co pomaga w zapobieganiu wprowadzania defektów do oprogramowania.
  • W przypadku korzystania z metod Agile: Shift-left wspiera tworzenie zespołów scrumowych, które obowiązkowo obejmują testerów i angażują ich w zwykłe stand-upy czy spotkania przeglądowe, dzięki którym mają więcej informacji związanych z programem, co pozwala im na angażowanie się w szczegółową analizę oprogramowania i dostarczanie szybkich informacji zwrotnych, które pomogłyby w zapobieganiu usterkom związanym z oprogramowaniem.

Metoda „przesunięcia w lewo” nakłania testerów do zaangażowania się wcześniej w procesie powstawania produktu. Zachęca do angażowania się w dyskusje i współpracę ze wszystkimi zespołami. Testerzy zaangażowani od początku w projekt pomagają zidentyfikować zagrożenia i z wyprzedzeniem je zminimalizować, co bezsprzecznie przyczynia się do zwiększenia możliwości powodzenia projektu w przyszłości.

A jeśli czujecie, że temat Shift-left nie został jeszcze w pełni omówiony, to… całkiem słusznie 😉 . Zapraszamy do drugiej części wpisu, która ukaże się już za dwa tygodnie. W niej przedstawimy zalecenia dla wszystkich testerów, którzy chcą poprawić efektywność swojej pracy w podejściu Shift-left i podamy 6 powodów, dla których warto korzystać z tej metody.

5
  •  
    3
    Shares
  • 3
  •  
  •  
  •