Testowanie w projekcie: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
m (cleanup bibliografii i rotten links)
m (cleanup bibliografii i rotten links)
Linia 61: Linia 61:
* Crispin L. (red.) (2009). Agile testing. A practical guide for testers and agile teams, Addison-Wesley, Boston
* Crispin L. (red.) (2009). Agile testing. A practical guide for testers and agile teams, Addison-Wesley, Boston
* Jędrzejewski K. (red.) (2012).[https://www.ee.pw.edu.pl/~sarwasg/PPIT/MPSI_SCRUM.pdf Zarządzanie projektami informarycznymi w metodyce Scrum], Politechnika Warszawska, Warszawa, s. 43
* Jędrzejewski K. (red.) (2012).[https://www.ee.pw.edu.pl/~sarwasg/PPIT/MPSI_SCRUM.pdf Zarządzanie projektami informarycznymi w metodyce Scrum], Politechnika Warszawska, Warszawa, s. 43
* Linz T. (2014).[https://images.nexto.pl/upload/virtualo/promise/e4904611f3b31f3d73e2d8e47733ad07f52cb208/free/e4904611f3b31f3d73e2d8e47733ad07f52cb208.pdf Testowanie w procesie Scrum. ], APN Promise, Warszawa, s. 24
* Linz T. (2014), ''[https://images.nexto.pl/upload/virtualo/promise/e4904611f3b31f3d73e2d8e47733ad07f52cb208/free/e4904611f3b31f3d73e2d8e47733ad07f52cb208.pdf Testowanie w procesie Scrum]'', APN Promise, Warszawa
* Wójcik P. (red.) (2017), ''Przepływ wiedzy w projektach informatycznych'', Zeszyty Naukowe Uniwersytetu Ekonomicznego w Katowicach, nr 341
* Wójcik P. (red.) (2017), ''Przepływ wiedzy w projektach informatycznych'', Zeszyty Naukowe Uniwersytetu Ekonomicznego w Katowicach, nr 341
* Ziółkowski A. (2012), ''[https://www.pbc.gda.pl/Content/18927/ArturZiolkowski-rozprawa_doktorska.pdf Adaptacyjny agentowy model zarządzania projektami informatycznymi]'', rozprawa doktorska, Politechnika Gdańska, Gdańsk
* Ziółkowski A. (2012), ''[https://www.pbc.gda.pl/Content/18927/ArturZiolkowski-rozprawa_doktorska.pdf Adaptacyjny agentowy model zarządzania projektami informatycznymi]'', rozprawa doktorska, Politechnika Gdańska, Gdańsk

Wersja z 22:51, 21 gru 2023

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):

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).


Testowanie w projekcieartykuły polecane
Feature-Driven DevelopmentInżynieria oprogramowaniaOgólna charakterystyka metodyki Prince 2Technika MoSCoWBacklog produktuAdaptacyjne zarządzanie projektamiMetodyka MSFMetodyka PMIDMAIC

Bibliografia


Autor: Olena Lunova