![\"Graue](\"https:\/\/29forward.com\/wp-content\/uploads\/2023\/11\/line-grey.svg\")
\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/p>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/p>\n
Artyku\u0142 specjalistyczny<\/p>\n
Podczas opracowywania, dostosowywania lub instalowania nowego oprogramowania, testowanie jest cz\u0119sto przeprowadzane na p\u00f3\u017anym etapie. Mo\u017ce to prowadzi\u0107 do tego, \u017ce b\u0142\u0119dy, kt\u00f3re pojawiaj\u0105 si\u0119 podczas rozwoju, s\u0105 rozpoznawane i naprawiane dopiero na p\u00f3\u017anym etapie – co z kolei prowadzi do wy\u017cszych koszt\u00f3w naprawy. Kr\u00f3tko m\u00f3wi\u0105c: im wcze\u015bniej b\u0142\u0105d zostanie wykryty, tym ta\u0144sze b\u0119dzie jego naprawienie. W ci\u0105gu ostatniej dekady zwinne tworzenie oprogramowania w coraz wi\u0119kszym stopniu dominowa\u0142o nad klasycznymi procesami rozwoju w wielu firmach i bran\u017cach. Zalety metod zwinnych zostan\u0105 wyja\u015bnione w tym artykule.
\nJednym z klasycznych liniowych modeli rozwoju jest model kaskadowy, w kt\u00f3rym oprogramowanie jest podzielone na kolejne fazy projektu, a zako\u0144czenie jednej fazy inicjuje rozpocz\u0119cie nast\u0119pnej.
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t![\"Grafik](\"https:\/\/29forward.com\/wp-content\/uploads\/2024\/05\/29FORWARD-Artikel-Agiles-Testmanagement-Wasserfallmodell.webp\")
\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/p>\n
Z biegiem lat tradycyjne metody okaza\u0142y si\u0119 bardzo uci\u0105\u017cliwe i kosztowne, poniewa\u017c b\u0142\u0119dy w poszczeg\u00f3lnych fazach projektowania by\u0142y czasami identyfikowane dopiero po zaprogramowaniu, a zatem mo\u017cna je by\u0142o poprawi\u0107 dopiero na p\u00f3\u017anym etapie. Zwinne metody tworzenia oprogramowania, takie jak Scrum, maj\u0105 na celu zaradzenie tej sytuacji.<\/p>\n
\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t![\"Grafik](\"https:\/\/29forward.com\/wp-content\/uploads\/2024\/05\/29FORWARD-Artikel-Agiles-Testmangement-Agile-Softwareentwicklung.webp\")
\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/p>\n
W przeciwie\u0144stwie do tradycyjnych metod, podej\u015bcia zwinne zbieraj\u0105 wymagania za po\u015brednictwem w\u0142a\u015bciciela produktu. W\u0142a\u015bciciel produktu tworzy backlog z zebranych wymaga\u0144 i przekazuje go scrum masterowi. Nast\u0119pnie scrum master wraz z zespo\u0142em scrumowym decyduje, kt\u00f3re wymagania maj\u0105 zosta\u0107 wdro\u017cone w danym sprincie, a nast\u0119pnie w\u0142\u0105cza je do backlogu sprintu.<\/p>\n
\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t![\"Grafik](\"https:\/\/29forward.com\/wp-content\/uploads\/2024\/05\/29FORWARD-Artikel-Agiles-Testmangement-Agiles-Testen-in-agilen-Projekten.webp\")
\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/p>\n
W fazie pocz\u0105tkowej i planowania sprintu definiowane s\u0105 kryteria akceptacji, tj. ustalane jest, co nale\u017cy przetestowa\u0107 zgodnie z wymaganiami. Kryteria akceptacji stanowi\u0105 podstaw\u0119 dla przeprowadzanych test\u00f3w. W ka\u017cdym nowym sprincie kryteria i testy s\u0105 odpowiednio uzupe\u0142niane. Cele test\u00f3w i mo\u017cliwe pomys\u0142y na testy s\u0105 podsumowywane w karcie test\u00f3w.<\/p>\n
Nast\u0119pnie rozpoczyna si\u0119 sprint i przygotowywane s\u0105 wszystkie odpowiednie testy, tj. dostarczane s\u0105 dane testowe i \u015brodowisko testowe, a nast\u0119pnie przeprowadzane s\u0105 testy. Odbywa si\u0119 to r\u00f3wnolegle z rozwojem funkcji. Podczas codziennych Scrum\u00f3w, blokady testowe lub przeszkody testowe s\u0105 omawiane z zespo\u0142em Scrum. B\u0142\u0119dy wykryte podczas test\u00f3w s\u0105 natychmiast naprawiane.<\/p>\n
Deweloperzy tworz\u0105 testy jednostkowe i wykonuj\u0105 je w oparciu o test-driven development, podstawow\u0105 technik\u0119 programowania ekstremalnego. Testy s\u0105 konsekwentnie pisane przed komponentami, kt\u00f3re faktycznie maj\u0105 by\u0107 testowane (test-first). Dzi\u0119ki refaktoryzacji w odpowiednim czasie, skupiamy si\u0119 na tym, co najwa\u017cniejsze i nie tworzymy niepotrzebnego kodu z wyprzedzeniem. Kod i przypadki testowe s\u0105 sprawdzane dopiero po pomy\u015blnym zako\u0144czeniu lokalnych test\u00f3w jednostkowych, zapewniaj\u0105c w ten spos\u00f3b, \u017ce wszystko dzia\u0142a idealnie, zanim trafi do kompilacji. Ca\u0142y kod jest zintegrowany z kompilacj\u0105 i testowany razem. Odbywa si\u0119 to kilka razy dziennie w „codziennej kompilacji”, kt\u00f3ra jest automatycznie testowana w potoku ci\u0105g\u0142ego dostarczania przed wydaniem.<\/p>\n
Potok ci\u0105g\u0142ego dostarczania obejmuje ci\u0105g\u0142\u0105 integracj\u0119, dostarczanie i wdra\u017canie i jest cz\u0119sto okre\u015blany jako potok CI\/CD. Potok CI\/CD jest cz\u0119\u015bci\u0105 wi\u0119kszego \u0142a\u0144cucha narz\u0119dzi, kt\u00f3ry obejmuje zautomatyzowane testowanie i zarz\u0105dzanie wersjami. Potoki ci\u0105g\u0142ego dostarczania przenosz\u0105 kod aplikacji od dewelopera do u\u017cytkownika, a automatyzacja test\u00f3w jest podstaw\u0105 wszystkich nowoczesnych potok\u00f3w dostarczania. Po udanych testach jednostkowych deweloper sprawdza nowy\/zaktualizowany kod i rozpoczyna si\u0119 seria test\u00f3w automatycznych. Powinny one obejmowa\u0107 testy integracyjne, a tak\u017ce testy systemowe z testami funkcjonalnymi i niefunkcjonalnymi, kt\u00f3re sprawdzaj\u0105 na przyk\u0142ad wydajno\u015b\u0107, sie\u0107, zewn\u0119trzne interfejsy API, zale\u017cno\u015bci i bezpiecze\u0144stwo. Zapobiega to publikowaniu niestabilnego, ryzykownego lub niezabezpieczonego kodu i udost\u0119pnianiu go u\u017cytkownikom. Zautomatyzowany proces kompilacji rozpoczyna si\u0119 dopiero po pomy\u015blnym zako\u0144czeniu tych test\u00f3w. W szczeg\u00f3lno\u015bci testy niefunkcjonalne maj\u0105 d\u0142ugi czas dzia\u0142ania, wi\u0119c nie ma sensu planowa\u0107 wszystkich test\u00f3w dla ka\u017cdej codziennej kompilacji, ale okre\u015bli\u0107 ich wyb\u00f3r. Wszystkie bardziej z\u0142o\u017cone testy mo\u017cna przeprowadza\u0107 na przyk\u0142ad co tydzie\u0144 lub przed konkretnym wydaniem. To samo dotyczy test\u00f3w integracji systemu, kt\u00f3re r\u00f3wnie\u017c powinny by\u0107 testowane tylko wtedy, gdy jest to konieczne \u2013 na przyk\u0142ad podczas pod\u0142\u0105czania nowego interfejsu do systemu.<\/p>\n
W sprincie poprzedzaj\u0105cym wydanie, testy systemu odbywaj\u0105 si\u0119 w \u015brodowisku produkcyjnym, ewentualnie z testem akceptacyjnym przeprowadzanym przez dzia\u0142 specjalistyczny. Gdy testy te zostan\u0105 pomy\u015blnie zaakceptowane, produkt jest przekazywany do DevOps (Development Operations) lub ITIL (Information Technology Infrastructure Library) w celu zwolnienia do \u015brodowiska produkcyjnego. Jednostki centralne zapewniaj\u0105 us\u0142ugi mi\u0119dzyzespo\u0142owe z podstawowymi zadaniami zwi\u0105zanymi z testami, takimi jak zapewnienie \u015brodowisk testowych i danych testowych, utrzymanie narz\u0119dzi testowych lub po\u0142\u0105czenie z innymi aplikacjami.<\/p>\n
Oczywi\u015bcie istniej\u0105 r\u00f3wnie\u017c znacz\u0105ce r\u00f3\u017cnice w automatyzacji test\u00f3w w podej\u015bciu zwinnym w por\u00f3wnaniu z podej\u015bciem klasycznym. W klasycznych projektach, kt\u00f3re s\u0105 zorganizowane zgodnie z modelem kaskadowym lub V, obszerna faza testowa jest zwykle wymagana tylko na ko\u0144cu projektu. Z kolei w projektach zwinnych oprogramowanie musi by\u0107 poddawane fazie test\u00f3w i kontroli jako\u015bci po ka\u017cdym sprincie.<\/p>\n
W przeciwie\u0144stwie do wspomnianych powy\u017cej podej\u015b\u0107 sekwencyjnych, wprowadzenie test\u00f3w automatycznych jest warunkiem wst\u0119pnym udanego projektu w projektach zwinnych. W miar\u0119 jak oprogramowanie rozwija si\u0119 po ka\u017cdym sprincie, liczba test\u00f3w i wysi\u0142ek zwi\u0105zany z testowaniem r\u00f3wnie\u017c wzrastaj\u0105. Aby zapewni\u0107 jak najwi\u0119ksze pokrycie testami oprogramowania w trakcie trwania projektu, nale\u017cy od samego pocz\u0105tku zaplanowa\u0107 rozw\u00f3j frameworka do automatyzacji test\u00f3w i potoku CI\/CD. Nawet je\u015bli zakres test\u00f3w jest mniejszy na pocz\u0105tku projektu, a testy s\u0105 ograniczone do ni\u017cszych poziom\u00f3w testowych dla test\u00f3w komponent\u00f3w i modu\u0142\u00f3w, kryteria ramowe zdefiniowane z wyprzedzeniem stanowi\u0105 podstaw\u0119 udanego wdro\u017cenia.<\/p>\n
Fakt, \u017ce zwinny projekt nie jest wykonalny bez automatyzacji test\u00f3w, staje si\u0119 jasny najp\u00f3\u017aniej na etapie test\u00f3w systemowych. W ka\u017cdym sprincie nie tylko nowe funkcje s\u0105 sprawdzane w te\u015bcie systemu, ale wszystkie poprzednie funkcje musz\u0105 by\u0107 r\u00f3wnie\u017c brane pod uwag\u0119 jako test regresji. Podczas gdy programi\u015bci mog\u0105 nadal by\u0107 w stanie przeprowadzi\u0107 test modu\u0142u po ka\u017cdym sprincie, r\u0119czne testowanie systemu wykracza\u0142oby poza zakres zwinnego projektu pod wzgl\u0119dem wysi\u0142ku, czasu i bud\u017cetu. Opracowane oprogramowanie zwi\u0119ksza swoj\u0105 funkcjonalno\u015b\u0107 i z\u0142o\u017cono\u015b\u0107 z ka\u017cdym sprintem \u2013 ale liczba i z\u0142o\u017cono\u015b\u0107 test\u00f3w, zw\u0142aszcza test\u00f3w systemowych, wzrasta w tym samym stopniu. Wysi\u0142ek zwi\u0105zany z testowaniem mo\u017cna znacznie zmniejszy\u0107 dzi\u0119ki automatyzacji test\u00f3w i dzia\u0142aj\u0105cemu potokowi CI\/CD.<\/p>\n
Pracownicy zwykle nie maj\u0105 wystarczaj\u0105co du\u017co czasu na r\u0119czne testowanie systemu po ka\u017cdym sprincie. Pod koniec zwinnego projektu bez automatyzacji test\u00f3w mog\u0105 nagle i nieoczekiwanie pojawi\u0107 si\u0119 b\u0142\u0119dy. Dlatego tym wa\u017cniejsze w zwinnych projektach jest wdro\u017cenie zautomatyzowanej i ustrukturyzowanej struktury testowej od samego pocz\u0105tku, kt\u00f3ra rozwija si\u0119 wraz z oprogramowaniem. Nie zapominajmy te\u017c, \u017ce im wcze\u015bniej rozpocznie si\u0119 testowanie, tym wcze\u015bniej b\u0119dzie mo\u017cna naprawi\u0107 ewentualne b\u0142\u0119dy i tym ni\u017csze b\u0119d\u0105 koszty ca\u0142ego procesu rozwoju.<\/p>\n