<\/p>\n\n\n\n
Spis tre\u015bci:<\/p>\n
W klasycznych metodykach wytwarzania oprogramowania, takich jak Waterfall, proces testowania oprogramowania nast\u0119puje po fazie jego zaprojektowania i wytworzenia. Tym samym obiektem poddawanym testowaniu jest gotowy, ostateczny produkt. G\u0142\u00f3wnymi problemami, jakie to rodzi, s\u0105 d\u0142ugi czas naprawy b\u0142\u0119d\u00f3w, ich wysoki koszt, a tak\u017ce ryzyko, i\u017c wprowadzone zmiany wp\u0142yn\u0105 na inne funkcjonalno\u015bci (co z kolei niesie za sob\u0105 konieczno\u015b\u0107 ponownego wykonania wszystkich test\u00f3w, a tym samym wyd\u0142u\u017ceniu ulega ca\u0142y proces).<\/p>\n\n\n\n
W ostatnich latach state-of-the-art<\/em> w wytwarzaniu oprogramowania s\u0105 tzw. metodyki zwinne<\/a> (Scrum, Kanban itp.). Dzi\u0119ki iteracyjnemu podej\u015bciu procesowi testowania nie jest poddawany ca\u0142y, gotowy produkt, lecz jego fragmenty b\u0119d\u0105ce rozwini\u0119ciem poprzedniej wersji, nieb\u0119d\u0105ce jednak jego ostateczn\u0105 wersj\u0105.<\/p>\n\n\n\n Niestety, niepoprawne wdro\u017cenie metodyk zwinnych r\u00f3wnie\u017c niesie ryzyko powt\u00f3rzenia powy\u017cej opisanych b\u0142\u0119d\u00f3w. Przyk\u0142adem niech b\u0119dzie jeden z moich wcze\u015bniejszych projekt\u00f3w, gdzie w czasie trwania Sprintu by\u0142 wyra\u017any podzia\u0142 na faz\u0119 omawiania zada\u0144, development, a nast\u0119pnie testowanie. Czym si\u0119 ko\u0144czy\u0142 taki Scrumfall <\/em>pod koniec Sprintu?<\/p>\n\n\n\n Dodatkowo dochodzi\u0142o do sytuacji, gdzie na etapie testowania okazywa\u0142o si\u0119, \u017ce developer zrozumia\u0142 zadanie w jeden spos\u00f3b, tester w drugi, a klientowi chodzi\u0142o o co\u015b zupe\u0142nie innego. Tym samym zadanie, kt\u00f3re by\u0142o uznawane za \u201eprawie sko\u0144czone\u201d stawa\u0142o si\u0119 zadaniem \u201edo om\u00f3wienia\u201d (co wyd\u0142u\u017ca\u0142o proces jego dostarczenia).<\/p>\n\n\n\n Nie tylko b\u0142\u0119dne zrozumienie Agile w organizacji mo\u017ce zwi\u0119ksza\u0107 ryzyko niepowodzenia w projekcie. Problem planowania czasu na testy oprogramowania pojawia si\u0119 w wielu projektach bez wzgl\u0119du na stosowan\u0105 metodyk\u0119. Okazuje si\u0119 jednak, \u017ce istnieje podej\u015bcie, kt\u00f3re mo\u017ce by\u0107 je\u015bli nie \u201elekiem na ca\u0142e z\u0142o\u201d, to na pewno \u015brodkiem \u0142agodz\u0105cym objawy nieumiej\u0119tnego rozplanowania prac w projekcie. Mowa tu o shift-left testing. To podej\u015bcie m\u00f3wi\u0105ce o tym, \u017ceby proces testowania zaczyna\u0107 na jak najwcze\u015bniejszym etapie wytwarzania oprogramowania.<\/strong><\/p>\n\n\n\n Przejd\u017amy teraz przez wszystkie etapy wytwarzania oprogramowania i odpowiedzmy sobie na pytania:<\/p>\n\n\n\n \u201eCzy to jest wystarczaj\u0105co wcze\u015bnie na testy? A je\u017celi nie, to dlaczego?\u201d.<\/strong><\/p>\n\n\n\n Pytanie o testy na produkcji zawsze jest dyskusyjne i niejednokrotnie prowadzi do odpowiedzi: \u201eTo zale\u017cy\u201d. Czy warto testowa\u0107 na tym etapie? Moim zdaniem tak. Jednak\u017ce m\u00f3wimy tu w\u00f3wczas o tzw. smoke testach<\/em>. Za ich pomoc\u0105 sprawdzamy jedynie, czy kluczowe \u015bcie\u017cki dzia\u0142aj\u0105. Szczeg\u00f3\u0142owe testy powinny zosta\u0107 wykonane na wcze\u015bniejszych etapach \u2013 o ile jest to mo\u017cliwe.<\/strong> Kiedy nie jest? Przyk\u0142adowo: serwis nale\u017cy do zewn\u0119trznego dostawcy i na ni\u017cszych \u015brodowiskach jest on mockowany<\/a>. Kolejny przyk\u0142ad: wysy\u0142amy zapytanie do innego serwisu, kt\u00f3rego baza produkcyjna jest 1000-krotnie wi\u0119ksza ni\u017c na \u015brodowisku testowym (kilkana\u015bcie milion\u00f3w obiekt\u00f3w vs kilkana\u015bcie tysi\u0119cy), co znacz\u0105co wp\u0142ywa na rozmiar otrzymywanych danych i ich liczb\u0119. Jeszcze innym przyk\u0142adem test\u00f3w na produkcji mog\u0105 by\u0107 np. testy konfiguracji. W jednym z projekt\u00f3w dostali\u015bmy zadanie, aby zmieni\u0107 spos\u00f3b budowania aplikacji. Z poziomu u\u017cytkownika nic si\u0119 nie zmieni\u0142o. Dla zespo\u0142u developerskiego zmieni\u0142o si\u0119 wszystko, gdy\u017c wdro\u017cone zosta\u0142o nowe narz\u0119dzie wraz z now\u0105 konfiguracj\u0105. Dodatkowo okaza\u0142o si\u0119, \u017ce jego konfiguracje nieco r\u00f3\u017cni\u0142y si\u0119 na ka\u017cdym ze \u015brodowisk.<\/p>\n\n\n\n \u015arodowisko testowe to \u015brodowisko staraj\u0105ce si\u0119 odzwierciedli\u0107 w jak najwi\u0119kszym stopniu \u015brodowisko produkcyjne. Wykonujemy na nim testy regresji (w postaci test\u00f3w automatycznych uruchamianych co noc), kt\u00f3re maj\u0105 nie tylko sprawdzi\u0107 jak najszerszy zakres funkcjonalno\u015bci naszej us\u0142ugi, ale te\u017c jej integracj\u0119 z innymi serwisami. Takie podej\u015bcie pozwala nam upewni\u0107 si\u0119, \u017ce najnowsza wersja aplikacji mo\u017ce by\u0107 wydana na produkcj\u0119. Jednak\u017ce ten etap procesu wytwarzania r\u00f3wnie\u017c nie jest najwcze\u015bniejszym, na jakim wykonujemy testy.<\/strong> Traktujemy go bardziej jako element pewnego rodzaju \u201edouble check\u201d,<\/em> dodatkowego sprawdzenia zmiany. Takie podej\u015bcie wynika z faktu, i\u017c proces naprawy b\u0142\u0119du zajmuje sporo czasu ze wzgl\u0119du na konieczno\u015b\u0107 stworzenia nowej wersji kodu z poprawk\u0105, poddania jej procesowi code review<\/em>, scalenia oraz wydania nowej wersji aplikacji.<\/p>\n\n\n\n To \u015brodowisko wykorzystywane jest przez developer\u00f3w podczas codziennego wytwarzania oprogramowania. Charakteryzuje si\u0119 tym, i\u017c wdro\u017cona na nim wersja aplikacji mo\u017ce zmienia\u0107 si\u0119 bardzo cz\u0119sto (nawet kilkukrotnie w ci\u0105gu dnia) oraz tym, i\u017c nie musi ona dzia\u0142a\u0107 poprawnie (stabilnie). Jednak\u017ce w\u0142a\u015bnie ze wzgl\u0119du na bardzo kr\u00f3tki czas wdra\u017cania zmian jest to r\u00f3wnie\u017c wy\u015bmienite miejsce do przeprowadzania test\u00f3w funkcjonalnych<\/strong> (zar\u00f3wno wst\u0119pnych, jak i ca\u0142o\u015bciowych) oraz zgrubnych test\u00f3w regresji. Dzi\u0119ki testom na tym \u015brodowisku, jako tester, w bardzo kr\u00f3tkim czasie jestem w stanie powiedzie\u0107, czy dana wersja mo\u017ce wej\u015b\u0107 na \u015brodowisko testowe, czy jednak wymaga zmian. Niekiedy zmiany te wprowadzane s\u0105 niemal\u017ce w czasie rzeczywistym \u2013 developer obserwuje zachowanie aplikacji podczas test\u00f3w, analizuje przyczyn\u0119 problemu, wprowadza poprawk\u0119, a nast\u0119pnie wykonywany jest retest, kt\u00f3ry sprawdza, czy wszystko dzia\u0142a. Takie podej\u015bcie zdecydowanie skraca czas otrzymania informacji zwrotnej od testera. Skraca r\u00f3wnie\u017c proces code review<\/em>, poniewa\u017c oddawany kod dzia\u0142a tak, jak powinien, i nie trzeba go modyfikowa\u0107 celem poprawy b\u0142\u0119d\u00f3w (co tylko wyd\u0142u\u017cy\u0142oby jego przegl\u0105d).<\/p>\n\n\n\n Czy mo\u017cna testowa\u0107 dokumentacj\u0119 b\u0105d\u017a wymagania biznesowe? Oczywi\u015bcie! Bardzo cz\u0119sto spotykam si\u0119 z sytuacj\u0105, kiedy ustalane s\u0105 cele zada\u0144 i ich zakres, wszyscy m\u00f3wi\u0105, \u017ce rozumiej\u0105 i wiedz\u0105, co ma by\u0107 zrobione, po czym padaj\u0105 pytania: \u201eA czy to nie wp\u0142ywa na inny obszar aplikacji?\u201d, \u201eA czy ta logika na pewno jest zgodna z wymaganiami innych serwis\u00f3w?\u201d, \u201eA czy wiemy, sk\u0105d te dane mamy pobra\u0107?\u201d, \u201eA czy mamy makiety i t\u0142umaczenia tekst\u00f3w?\u201d. I nagle okazuje si\u0119, \u017ce zadanie, kt\u00f3re ju\u017c zosta\u0142oby wzi\u0119te w zakres Sprintu \u2013 jest z niego usuwane lub zostaje zablokowane celem dalszych wyja\u015bnie\u0144. Gdyby nie to, to bardzo prawdopodobna by\u0142aby sytuacja, w kt\u00f3rej te pytania zosta\u0142yby zadane ju\u017c w trakcie developmentu. A to skutkowa\u0142oby przed\u0142u\u017conym czasem rozwoju oprogramowania lub nawet niedostarczeniem funkcjonalno\u015bci.<\/p>\n\n\n\n Wydawa\u0107 by si\u0119 mog\u0142o, \u017ce okre\u015blanie wymaga\u0144 biznesowych to najwcze\u015bniejszy etap procesu wytwarzania oprogramowania, w kt\u00f3rym mo\u017cliwe s\u0105 testy oprogramowania. A co za tym idzie \u2013 nie da si\u0119 przesun\u0105\u0107 testowania bardziej w lewo. Ot\u00f3\u017c… nie jest to do ko\u0144ca prawda. Na konferencji TestWarez 2019 Marcus Merrell<\/a> w swoim wyst\u0105pieniu „Shift Left, Shift Right \u2013 Why These Buzzwords Matter\u201d<\/a> powiedzia\u0142, \u017ce kolejnym przesuni\u0119ciem testowania na wcze\u015bniejszy etap jest\u2026 \u015brodowisko produkcyjne. Ale jak to? Testowanie na produkcji? Ot\u00f3\u017c nie testowanie, a monitorowanie. A nast\u0119pnie wyci\u0105ganie wniosk\u00f3w i tworzenie na ich podstawie nowych zada\u0144 mog\u0105cych usprawni\u0107 dzia\u0142anie systemu.<\/p>\n\n\n\n Przyk\u0142adowo: w naszym projekcie jedn\u0105 z metryk, jakie zbieramy i analizujemy, jest rodzaj b\u0142\u0119d\u00f3w biznesowych wyst\u0119puj\u0105cych w aplikacji. Gdy kt\u00f3ry\u015b b\u0142\u0105d zaczyna si\u0119 pojawia\u0107 du\u017co cz\u0119\u015bciej, badamy, co jest jego przyczyn\u0105, i zastanawiamy si\u0119, co mo\u017cemy zrobi\u0107, aby zredukowa\u0107 jego wyst\u0119powanie.<\/p>\n\n\n\n Najbardziej oczywist\u0105 i podkre\u015blan\u0105 przez wszystkich zalet\u0105 podej\u015bcia shift-left testing jest wykrycie b\u0142\u0119d\u00f3w na wczesnym etapie developmentu. Niemniej podej\u015bcie to, w projekcie, jaki realizujemy w Inetum dla klienta z obszaru e-commerce, przynosi te\u017c inne zalety. Oto one:<\/p>\n\n\n\n W dyskusjach o automatyzacji test\u00f3w bardzo cz\u0119sto pojawia si\u0119 pytanie: \u201eKiedy zacz\u0105\u0107 automatyzowa\u0107?\u201d<\/strong>. Moja odpowied\u017a zawsze brzmi: \u201eJak najwcze\u015bniej\u201d. Przyk\u0142adowo \u2013 zadanie polega na wprowadzeniu nowego pola do formularza oraz dodaniu nowych walidacji. Czy musz\u0119 czeka\u0107, a\u017c developerzy przygotuj\u0105 backend i frontend, abym m\u00f3g\u0142 zacz\u0105\u0107 testowa\u0107 manualnie, a nast\u0119pnie stworzy\u0107 testy automatyczne? Nie. Na podstawie opisu zadania tworz\u0119 przypadki testowe<\/a>,<\/a> jakie b\u0119d\u0105 wykonane, wybieram te, kt\u00f3re zostan\u0105 zautomatyzowane, a nast\u0119pnie przygotowuj\u0119 kod test\u00f3w. W efekcie, kiedy developer oddaje mi zadanie do test\u00f3w, bardzo cz\u0119sto wystarczy, \u017ce uruchomi\u0119 taki kod i w bardzo kr\u00f3tkim czasie dostan\u0119 informacj\u0119, czy funkcjonalno\u015b\u0107 dzia\u0142a zgodnie z za\u0142o\u017ceniami, czy nie (niekiedy wr\u0119cz nie musz\u0119 wykonywa\u0107 test\u00f3w manualnych, poniewa\u017c automatyczne pokryj\u0105 wszystkie przypadki, a na dodatek b\u0119d\u0105 szybsze i dok\u0142adniejsze).<\/p>\n\n\n\n Automatyzacja na wczesnym etapie niesie ze sob\u0105 dodatkow\u0105 zalet\u0119, jak\u0105 jest podw\u00f3jne sprawdzenie funkcjonalno\u015bci. Tzn. zmiana testowana jest na \u015brodowisku developerskim, kod jest scalany, nowa wersja aplikacji jest wydawana i wgrywana na \u015brodowisko testowe. Przygotowane testy automatyczne maj\u0105 da\u0107 takie same wyniki na obu \u015brodowiskach. Czy tak si\u0119 dzieje? Zazwyczaj tak. Niestety, w projektach zdarza\u0142y si\u0119 sytuacje, kiedy jednego dnia scalonych zosta\u0142o kilka r\u00f3\u017cnych zmian, co w efekcie spowodowa\u0142o niepoprawne dzia\u0142anie ju\u017c przetestowanych funkcjonalno\u015bci. Na szcz\u0119\u015bcie codzienne uruchamianie test\u00f3w pozwoli\u0142o nam na szybkie wykrycie tego problemu i jego popraw\u0119.<\/p>\n\n\n\n W dzisiejszym \u015bwiecie bardzo cz\u0119sto podkre\u015bla si\u0119 znaczenie test\u00f3w w procesie wytwarzania oprogramowania. A jak jest naprawd\u0119? R\u00f3\u017cnie. Pokusz\u0119 si\u0119 o stwierdzenie, \u017ce co zesp\u00f3\u0142, to inne podej\u015bcie. W moim obecnym projekcie pocz\u0105tkowo tryb pracy by\u0142… typowy tzn. developer zaczyna\u0142 prac\u0119 nad zadaniem, przygotowywa\u0142 zmian\u0119, kod przechodzi\u0142 proces code review<\/em>, wydawana by\u0142a nowa wersja aplikacji i zadanie przechodzi\u0142o w etap test\u00f3w. Po kilku miesi\u0105cach pracy ten proces si\u0119 znacz\u0105co zmieni\u0142. Wypracowali\u015bmy podej\u015bcie, w kt\u00f3rym przed przesuni\u0119ciem zadania do code review<\/em> kod jest sprawdzany przez QA.<\/p>\n\n\n\n Czy podej\u015bcie shift-left zadzia\u0142a zawsze i w ka\u017cdym zespole?<\/strong><\/p>\n\n\n\n Moim zdaniem nie. Dlaczego u nas si\u0119 sprawdza? Jest kilka powod\u00f3w:<\/p>\n\n\n\n\n
Shift-left \u2013 co to takiego?<\/h2>\n\n\n\n
\u015arodowisko produkcyjne<\/h2>\n\n\n\n
\u015arodowisko testowe<\/h2>\n\n\n\n
\u015arodowisko developerskie<\/h2>\n\n\n\n
Analiza biznesowa i ustalanie wymaga\u0144<\/h2>\n\n\n\n
Czy mo\u017cna testowa\u0107 jeszcze wcze\u015bniej?<\/h2>\n\n\n\n
Shift-left testing \u2013 co nam to daje?<\/h2>\n\n\n\n
Wczesna automatyzacja<\/h3>\n\n\n\n
Podw\u00f3jne sprawdzenie<\/h3>\n\n\n\n
Wi\u0119ksza \u015bwiadomo\u015b\u0107 znaczenia test\u00f3w<\/h3>\n\n\n\n
Shift-left \u2013 dlaczego u nas dzia\u0142a?<\/h2>\n\n\n\n
\n