Testowanie w projekcie: Różnice pomiędzy wersjami
m (cleanup bibliografii i rotten links) |
m (Czyszczenie tekstu) |
||
| Linia 14: | Linia 14: | ||
}} | }} | ||
''' Testowanie ''' | ''' Testowanie ''' - seria zadań, które realizowane są przez testerów w celu sprawdzenia prawidłowości funkcjonowania oprogramowania tworzonego w projekcie informatycznym (A. Ziółkowski 2012, s. 19). | ||
Każdy złożony [[wyrób]] produkowany obecnie jest sterowany przez oprogramowanie, a wiele usług komercyjnych opiera się na systemach informatycznych (T. Linz 2014, s. 3). Realizując [[projekt]] IT niezbędnym jest [[posiadanie]] wiedzy specjalistycznej, kwalifikacji i doświadczenia w zakresie informatyki. Według PMI [[zarządzanie]] projektem polega na tym, że projekt informatyczny przechodzi kolejno przez następujące po sobie fazy (project life cycle): | Każdy złożony [[wyrób]] produkowany obecnie jest sterowany przez oprogramowanie, a wiele usług komercyjnych opiera się na systemach informatycznych (T. Linz 2014, s. 3). Realizując [[projekt]] IT niezbędnym jest [[posiadanie]] wiedzy specjalistycznej, kwalifikacji i doświadczenia w zakresie informatyki. Według PMI [[zarządzanie]] projektem polega na tym, że projekt informatyczny przechodzi kolejno przez następujące po sobie fazy (project life cycle): | ||
| Linia 32: | Linia 32: | ||
==Testowanie oprogramowania z Agile== | ==Testowanie oprogramowania z Agile== | ||
Zespoły używające metodyk Agile w projektach informatycznych składają się z programistów, testerów i analityków. Programista pisze test dla niewielkiej części projektu po czym sprawdza czy testy wypadają poprawnie, następnie pisze kod, który spełni warunki zawarte w testach. | Zespoły używające metodyk Agile w projektach informatycznych składają się z programistów, testerów i analityków. Programista pisze test dla niewielkiej części projektu po czym sprawdza czy testy wypadają poprawnie, następnie pisze kod, który spełni warunki zawarte w testach. | ||
| Linia 38: | Linia 37: | ||
==Testowanie w Scrum== | ==Testowanie w Scrum== | ||
W tworzeniu oprogramowania, Agile stał się synonimem określonego sposobu działania według zasad [[Scrum]]. Scrum z kolei obejmuje procesy podejmowania decyzji na podstawie informacji nadchodzącej w czasie rzeczywistym. W tym podejściu [[zakres]] projektu jest dzielony na mniejsze grupy zadań, które nazywają się product [[backlog]]. | W tworzeniu oprogramowania, Agile stał się synonimem określonego sposobu działania według zasad [[Scrum]]. Scrum z kolei obejmuje procesy podejmowania decyzji na podstawie informacji nadchodzącej w czasie rzeczywistym. W tym podejściu [[zakres]] projektu jest dzielony na mniejsze grupy zadań, które nazywają się product [[backlog]]. | ||
| Linia 51: | Linia 49: | ||
==Testowanie w metodach tradycyjnych== | ==Testowanie w metodach tradycyjnych== | ||
Testowanie w metodach tradycyjnych odróżnia się od testowania w metodach Agile. Różnica ta polega na tym, że testerzy nie uczestniczą ani w bliskiej współpracy z programistami ani w pracach projektowych, które trwają na początku projektu. Ten fakt wynika z tego, że tradycyjne zespoły zajmują się niewielkim obszarem testowania. Po ustaleniu wymagań dotyczących projektu nie istnieje możliwość, aby zmienić te wymagania, a jedyne co można zrobić, to uwzględnić zmiany wymagań w następnych projektach. | Testowanie w metodach tradycyjnych odróżnia się od testowania w metodach Agile. Różnica ta polega na tym, że testerzy nie uczestniczą ani w bliskiej współpracy z programistami ani w pracach projektowych, które trwają na początku projektu. Ten fakt wynika z tego, że tradycyjne zespoły zajmują się niewielkim obszarem testowania. Po ustaleniu wymagań dotyczących projektu nie istnieje możliwość, aby zmienić te wymagania, a jedyne co można zrobić, to uwzględnić zmiany wymagań w następnych projektach. | ||
| Linia 57: | Linia 54: | ||
==Porównanie tradycyjnego testowania z testowaniem Agile== | ==Porównanie tradycyjnego testowania z testowaniem Agile== | ||
Według autorów L. Crispin i J. Gregory [[model]] tradycyjnego zarządzania projektami, model kaskadowy (waterfall model), składa się z następujących faz: | Według autorów L. Crispin i J. Gregory [[model]] tradycyjnego zarządzania projektami, model kaskadowy (waterfall model), składa się z następujących faz: | ||
* określenie wymagań, | * określenie wymagań, | ||
Wersja z 12:32, 2 lis 2023
| Testowanie w projekcie |
|---|
| Polecane artykuły |
Testowanie - seria zadań, które realizowane są przez testerów w celu sprawdzenia prawidłowości funkcjonowania oprogramowania tworzonego w projekcie informatycznym (A. Ziółkowski 2012, s. 19).
Każdy złożony wyrób produkowany obecnie jest sterowany przez oprogramowanie, a wiele usług komercyjnych opiera się na systemach informatycznych (T. Linz 2014, s. 3). Realizując projekt IT niezbędnym jest posiadanie wiedzy specjalistycznej, kwalifikacji i doświadczenia w zakresie informatyki. Według PMI zarządzanie projektem polega na tym, że projekt informatyczny przechodzi kolejno przez następujące po sobie fazy (project life cycle):
- określenie wymagań,
- projektowanie,
- wdrożenie,
- testowanie,
- konserwacja.
W klasycznej metodzie zarządzania projektem informatycznym testowanie jest oddzielną fazą, która następuje po fazie wdrożenia. Istnieją projekty IT, które charakteryzują się zmiennością uwarunkowań technologicznych i różnorodnością przedsięwzięć, co z kolei wymaga zastosowania innych metodyk zarządzania projektami.
W odniesieniu do przedsięwzięć informatycznych aktualnie najbardziej efektywnymi metodami prowadzenia projektów są metodyki zwinne (Agile), w których przebieg projektów charakteryzuje się adaptacyjnością (adaptive). W metodyce zwinnej zarządzania projektami informatycznymi dla określenia fazy testowania wprowadza się pojęcie "Definition of Done”, które ma na celu ukazać co zostało zrobione. Z kolei za wykonane możemy uznać takie, które spełnia wszystkie kryteria wysunięte przez klienta (K. Jędrzejewski i in. 2012, s. 26).
TL;DR
Artykuł omawia testowanie oprogramowania w kontekście zarządzania projektami informatycznymi. W metodach Agile, testowanie jest wykonywane przez testerów, którzy działają w bliskiej współpracy z programistami. Metodyka Scrum pozwala testerom działać przez całą iterację i współpracować bezpośrednio z klientem. W tradycyjnych metodach testowanie jest oddzielone od pracy programistów i koncentruje się na dostarczeniu finalnego produktu. Metodyka Agile polega na reagowaniu na zmiany i dostosowywaniu się do indywidualnych potrzeb klientów. Testy są pisane na podstawie dokumentu wymagań i prowadzone są próby eksploracyjne oraz testy demonstracyjne.
Testowanie oprogramowania z Agile
Zespoły używające metodyk Agile w projektach informatycznych składają się z programistów, testerów i analityków. Programista pisze test dla niewielkiej części projektu po czym sprawdza czy testy wypadają poprawnie, następnie pisze kod, który spełni warunki zawarte w testach.
Samo testowanie w Agile jest wykonywane przez testerów. Testowanie zawiera testy, które prowadzą analizę produktu i przyczyniają się do wykrycia braków, które można poprawić w gotowym produkcie (K. Jędrzejewski i in. 2012, s. 30).
Testowanie w Scrum
W tworzeniu oprogramowania, Agile stał się synonimem określonego sposobu działania według zasad Scrum. Scrum z kolei obejmuje procesy podejmowania decyzji na podstawie informacji nadchodzącej w czasie rzeczywistym. W tym podejściu zakres projektu jest dzielony na mniejsze grupy zadań, które nazywają się product backlog.
W Scrumie, który jest praktycznym podejściem do zasad Agile, odpowiedzialność w projekcie jest podzielona między:
- Zespołem,
- ScrumMastrem,
- Wlaścicielem Produktu.
Zespół projektowy działa iteracyjnie i określa, które zadania należy wykonać w kolejnych iteracjach (P. Wójcik i in. 2017, s. 380). Oprócz tego zespoły prowadzone w metodykach Agile są zorientowane na dostarczenie produktu do klienta, który spełnia wszystkie jego wymogi.
Zespół w metodyce Scrum jest odpowiedzialny za ustalenie wymagań dotyczących produktu, a właściciel produktu ustala priorytet tych wymagań. Testowanie w Scrum polega na tym, że testerzy nie czekają aż kod będzie napisany. Testerzy mają za zadanie działać przez całą iterację, a Scrum umożliwia ich bezpośrednią współpracę z klientem, co z kolei doprowadza do dostarczenia oprogramowania o lepszej jakości.
Testowanie w metodach tradycyjnych
Testowanie w metodach tradycyjnych odróżnia się od testowania w metodach Agile. Różnica ta polega na tym, że testerzy nie uczestniczą ani w bliskiej współpracy z programistami ani w pracach projektowych, które trwają na początku projektu. Ten fakt wynika z tego, że tradycyjne zespoły zajmują się niewielkim obszarem testowania. Po ustaleniu wymagań dotyczących projektu nie istnieje możliwość, aby zmienić te wymagania, a jedyne co można zrobić, to uwzględnić zmiany wymagań w następnych projektach.
Zespoły stosujące metodę tradycyjną koncentrują się na tym, aby produkty były dostarczone w finalnej wersji. Zazwyczaj zespół rozwojowy nie ma informacji o dodatkowych funkcjonalnościach produktu i klient myśli, że będą się one w nim znajdowały. W takiej sytuacji testerzy opracowują dużą ilość dokumentów, żeby napisać własny plan testów, a potem już następuje właściwe testowanie.
Porównanie tradycyjnego testowania z testowaniem Agile
Według autorów L. Crispin i J. Gregory model tradycyjnego zarządzania projektami, model kaskadowy (waterfall model), składa się z następujących faz:
- określenie wymagań,
- konkretyzacja wymagań,
- kodowanie,
- testowanie,
- wdrożenie.
Model kaskadowy opiera się na tym, że czas przeznaczony na każdą z poszczególnych faz jest równy. Jest to podejście nieco idealistyczne, bo kodowanie zwykle zajmuje więcej czasu, niż zaplanowano, co oznacza, że faza testowania jest przez to skrócona.
Co dotyczy metodyki Scrum, to jest ona przeciwieństwem do tradycyjnych metod ponieważ testerzy sprawdzają każdy kod po kolei jak tylko poprzedni jest uważany za skończony. Czas każdej iteracji jest nie określony i może trwać dowolnie długo. Działalność zespołu polega na budowaniu i testowaniu małej części kodu, a kiedy grupa upewni się, że wszystko działa poprawnie buduje i testuje następną część kodu. W Agile nie ma znaczenia wielkość projektu.
Ważnym jest aby reagować na zmiany oraz pamiętać, że dwóch takich samych klientów nie istnieje i do każdego z nich należy podejść w różny sposób, na tym głównie polega metodyka Agile.
Pisanie testów w Agile bazuje na podstawie dokumentu wymagań tworzonych przez analityka biznesowego i trwa już przed rozpoczęciem pisania kodu. Na podstawie szczególnych przypadków testerzy prowadzą próby eksploracyjne w celu odnalezienia najważniejszych błędów. Także przez testerów prowadzone są testy demonstracyjne, które sprawdzają czy funkcjonalność projektu jest spełniona (K. Jędrzejewski i in. 2012, s. 31-34).
Bibliografia
- Crispin L. (red.) (2009). Agile testing. A practical guide for testers and agile teams, Addison-Wesley, Boston
- Jędrzejewski K. (red.) (2012).Zarządzanie projektami informarycznymi w metodyce Scrum, Politechnika Warszawska, Warszawa, s. 43
- Linz T. (2014).Testowanie w procesie Scrum. , APN Promise, Warszawa, s. 24
- Wójcik P. (red.) (2017). Przepływ wiedzy w projektach informatycznych, "Zeszyty Naukowe Uniwersytetu Ekonomicznego w Katowicach”, nr 341
- Ziółkowski A. (2012). Adaptacyjny agentowy model zarządzania projektami informatycznymi, Politechnika Gdańska, Gdańsk, s. 183
Autor: Olena Lunova
