Shift-left Testing

Dyskusja kiedy i ile testować trwa od wielu lat i podejście to zmienia się w zależności od stopnia dojrzałości danej organizacji, specyfiki projektu i osób składających się na zespół deweloperski. Pytanie „kiedy” można podzielić na dwa kolejne – na jakich etapach i przede wszystkim – kiedy zacząć.

Przy wielu projektach dalej wyznawana jest zasada podejścia kaskadowego – zaczynamy od planowania i analizy, potem następuje etap projektowania i implementacji i dopiero po tym wszystkim wchodzą testy. Jednak zauważono, że błąd niezweryfikowany na poziomie planowania czy projektowania rozwiązania może nie tylko opóźnić projekt, ale też wiele kosztować - i pieniędzy i nerwów całego zespołu J. Jakie są więc sposoby na rozwiązanie tego problemu?

Pierwszym, co przychodzi na myśl, jest Agile. Podejście zwinne eliminuje ten problem, ponieważ w danym sprincie skupiamy się na „kawałku” oprogramowania i od razu się go weryfikuje, a testerzy są cały czas zaangażowani w projekt. Mimo, że agile z dzisiejszym tematem ma cechy wspólne (a nawet się z nim łączy), to jednak dziś nie o tym. Jest inne podejście, rozwiązujące problemy modelu kaskadowego, a mianowicie „shift-left testing”.

Jest to nic innego, jak zaangażowanie osób odpowiedzialnych za jakość oprogramowania na jak najwcześniejszym etapie cyklu wytwarzania oprogramowania. „Przesunięcie w lewo” to przesunięcie testowania na te właśnie wcześniejsze etapy cyklu. Najbardziej oczywistą i podkreślaną przez wszystkich zaletą podejścia shift-left testing jest wykrycie błędów na wczesnym etapie developmentu, a jak wiadomo, są one wtedy tańsze do naprawienia. Dzięki nie tylko wczesnemu, ale i częstemu testowaniu można w znacznym stopniu ograniczyć ich ilość, szczególnie tych określanych jako krytyczne. Zwiększa się też zaangażowanie testerów. Dzięki temu, że od samego początku są częścią zespołu, mogą lepiej zrozumieć wymagania projektu i jego architekturę oraz ułatwia to komunikację między nimi a programistami oraz klientami.

Oczywiście takie zmiany muszą przyjść „z góry” – sam zespół testerski nie może podejmować takich decyzji. Wiąże się to ze zmianą całego podejścia do wytwarzania oprogramowania i zmienia system pracy całego zespołu. Odpowiedzialność za takie kroki spoczywa więc na barkach kierownika projektu. Patrząc na to, jakie korzyści może to przynieść dla wszystkich zaangażowanych w projekt, warto rozważyć takie rozwiązanie.