Shift-left testing, czyli testuj jak najwcześniej

Shift-left testing, czyli testujmy jak najwcześniej

Zapewniać jakość możemy, stosując wiele podejść, jednym z nich jest shift-left, czyli próba jak najwcześniejszego zapewnienia jakości.

Poruszając temat kosztu błędu, który znajdziesz we wpisie: https://projectquality.it/koszt-bledu/

Możemy zauważyć, że wraz z wcześniejszym etapem, na jakim zapewniamy jakość, cena kosztu błędu spada.

Tradycyjny model

W tradycyjnym modelu testowania, testowanie najczęściej następowało po developmencie zadania. Tester otrzymuje gotową funkcjonalność/zmianę od programisty, a następnie sprawdza jej działanie.

Takie podejście może powodować różne zagrożenia, jednym z nich może być zbyt duża ilość pracy w zbyt krótkim okresie czasu dla jednego testera co może spowodować opóźnienie wydania aplikacji na produkcję. Często również stosując to podejście, ciężko jest wyważyć, jakie jest odpowiednie ratio testerów do programistów, szczególnie gdy ilość pracy jest mocno zmienna podczas trwania sprintu. Wszystko to może powodować opóźnienia w dostarczeniu nowych funkcjonalności/naprawieniu błędów na produkcję.

Zagrożeniem w tym modelu może być również przypadek gdzie po oddaniu oprogramowania z fazy developmentu do testowania pojawi się defekt krytyczny, którego naprawa może zająć więcej czasu i napisanie samego rozwiązania.

Wszystkie zachowania jak wyżej mogą powodować między innymi niestabilność estymacji i problemy z dotrzymaniem terminów w kontekście dostarczania.

Tradycyjny model:

Shift-left, testuj jak najwcześniej

W modelu shift-left większość wysiłku związanego z zapewnieniem jakości jest skierowana na etap, który znajduje się jeszcze przed zaczęciem implementacji. Daje nam to możliwość zapobieganiu powstania defektom, a nie jak w przypadku tradycyjnego modelu ich wykrywaniu.

Prewencja przed powstawianiem defektów w podejściu shift-left może obejmować wiele działań, jest to między innymi statyczna analiza, analiza wymagań, przygotowywanie scenariuszy testowych, analizowanie ryzyk.

Dodatkową różnicą, jaka jeszcze występuje, jest fakt, że programiści muszą brać większą odpowiedzialność za swój kod, ponieważ po fazie developmentu testerzy nie skupiają się już tak bardzo na wykrywaniu defektów. Przewagom jednak w takim scenariuszu jest perspektywa, że praca włożona w aspekt jakości i prewencję przed rozpoczęciem fazą developmentu powinna przynieść zysk w postaci pracy zawierającą mniejszą ilość defektów.

Shift-left testing:

Shift-left daje nam to korzyści takie jak:

• możliwość statycznego testowania jeszcze przed zaczęciem implementacji
• w razie wykrycia defektu koszt jest zdecydowanie niższy.
• zaprojektowanie testów na wczesnym etapie
• współpraca ze wszystkimi interesariuszami biznesowymi

Recepta na wszystko – czemu więc shift-left nie jest tak popularnym kierunkiem?

Czemu więc skoro shift-left jest rozwiązaniem dużej ilości problemów związanych z wytwarzaniem software’u nie jest stosowane aż tak często? Czy jest to kwestia przyzwyczajenia do kaskadowego wytarzania oprogramowania?

Z drugiej strony nawet jeśli tester chciałby spróbować wdrażać shift-left to najprawdopodobniej będzie potrzebował zgody od kogoś na wyższym stanowisku (oczywiście zależy to od wielkości projektu), co nie zawsze może być takie proste. Często może wymagać to zmiany na poziomie projektu/organizacji gdzie zmiana kierunku nie zawsze musi być tak dynamiczna.

Mieliście do czynienia z projektem, który stosował podejście shift-left testing, a może z hybrydą testowania na początku i klasycznie po developmencie. Koniecznie dajcie znać w komentarzach.

Photo by Nick Fewings on Unsplash