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

Z Encyklopedia Zarządzania
m (Dodanie TL;DR)
m (cleanup bibliografii i rotten links)
 
(Nie pokazano 12 wersji utworzonych przez 2 użytkowników)
Linia 1: Linia 1:
{{infobox4
''' 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).
|list1=
<ul>
<li>[[Feature-Driven Development]]</li>
<li>[[Inżynieria oprogramowania]]</li>
<li>[[Ogólna charakterystyka metodyki Prince 2]]</li>
<li>[[Technika MoSCoW]]</li>
<li>[[Backlog produktu]]</li>
<li>[[Adaptacyjne zarządzanie projektami]]</li>
<li>[[Metodyka MSF]]</li>
<li>[[Metodyka PMI]]</li>
<li>[[DMAIC]]</li>
</ul>
}}
 
 
 
''' 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 24: Linia 7:
* testowanie,
* testowanie,
* konserwacja.
* konserwacja.
<google>t</google>


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 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).  
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==
==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.
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.
<google>n</google>


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


W Scrumie, który jest praktycznym podejściem do zasad Agile, [[odpowiedzialność]] w projekcie jest podzielona między:
W Scrumie, który jest praktycznym podejściem do zasad Agile, [[odpowiedzialność]] w projekcie jest podzielona między:
Linia 47: Linia 29:
* ScrumMastrem,
* ScrumMastrem,
* Wlaścicielem Produktu.
* 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ół 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.
[[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==
 
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.  


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.
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==
==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ń,
Linia 67: Linia 47:
* wdrożenie.
* 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.  
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.  
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.  
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).
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).
{{infobox5|list1={{i5link|a=[[Feature-Driven Development]]}} &mdash; {{i5link|a=[[Inżynieria oprogramowania]]}} &mdash; {{i5link|a=[[Ogólna charakterystyka metodyki Prince 2]]}} &mdash; {{i5link|a=[[Technika MoSCoW]]}} &mdash; {{i5link|a=[[Backlog produktu]]}} &mdash; {{i5link|a=[[Adaptacyjne zarządzanie projektami]]}} &mdash; {{i5link|a=[[Metodyka MSF]]}} &mdash; {{i5link|a=[[Metodyka PMI]]}} &mdash; {{i5link|a=[[DMAIC]]}} }}


==Bibliografia==
==Bibliografia==
* Crispin L. (red.) (2009). Agile testing. A practical guide for testers and agile teams, Addison-Wesley, Boston
<noautolinks>
* Jędrzejewski K. (red.) (2012).[http://www.ee.pw.edu.pl/~sarwasg/PPIT/MPSI_SCRUM.pdf Zarządzanie projektami informarycznymi w metodyce Scrum], Politechnika Warszawska, Warszawa, s. 43
* Crispin L. (red.) (2009), ''Agile testing, A practical guide for testers and agile teams'', Addison-Wesley, Boston
* Linz T. (2014).[http://images.nexto.pl/upload/virtualo/promise/e4904611f3b31f3d73e2d8e47733ad07f52cb208/free/e4904611f3b31f3d73e2d8e47733ad07f52cb208.pdf Testowanie w procesie Scrum. ], APN Promise, Warszawa, s. 24
* 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
* Ziółkowski A. (2012). Adaptacyjny agentowy model zarządzania projektami informatycznymi, Politechnika Gdańska, Gdańsk, s. 183
* 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
</noautolinks>


{{a|Olena Lunova}}
{{a|Olena Lunova}}
[[Kategoria:Negocjacje]]
[[Kategoria:Kontrola w projekcie]]
[[Kategoria:Zarządzanie projektami]]
 
{{#metamaster:description|Przegląd testowania w projekcie IT i efektywne metodyki testowe. Dowiedz się, jak sprawdzić poprawność działania oprogramowania.}}

Aktualna wersja na dzień 00:21, 10 sty 2024

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