test plan tutorial guide write software test plan document from scratch
Kompletny przewodnik po dokumencie planu testów oprogramowania:
Ten samouczek wyjaśni Ci wszystko na temat dokumentu planu testów oprogramowania i poprowadzi Cię przez sposoby pisania / tworzenia szczegółowego planu testowania oprogramowania od podstaw wraz z różnice między planowaniem testów a wykonywaniem testów.
Projekt na żywo w ramach szkolenia Project QA 3 - Po zapoznaniu naszych czytelników z aplikacją na żywo naszego darmowe szkolenie online z testowania oprogramowania , dowiedzieliśmy się jak przeglądać SRS i pisać scenariusze testowe . A teraz jest właściwy moment, aby zagłębić się w najważniejszą część cyklu życia testowania oprogramowania - tj. Planowanie testów .
Lista WSZYSTKICH samouczków z tej serii:
Dokument planowania testów:
Samouczek nr 1: Jak napisać dokument dotyczący planu testów (Ten samouczek)
Samouczek nr 2: Zawartość szablonu prostego planu testów
Samouczek nr 3: Przykład planu testów oprogramowania
Samouczek nr 4: Różnica między planem testów a strategią testów
Samouczek nr 5: Jak napisać dokument dotyczący strategii testów
Wskazówki dotyczące planowania testów:
Samouczek nr 6: Zarządzanie ryzykiem podczas planowania testów
Samouczek nr 7: Co robić, gdy nie ma wystarczająco dużo czasu na testy
Samouczek nr 8: Jak skutecznie planować i zarządzać projektami testowymi
Planowanie testów na różnych etapach STLC:
Samouczek nr 9: Planowanie testów regresji
Samouczek nr 10: Plan testów UAT
Samouczek nr 11: Plan testów akceptacyjnych
Planowanie automatyzacji testów:
Samouczek nr 12: Plan testów automatyzacji
Samouczek nr 13: Planowanie testów aplikacji ERP
Samouczek nr 14: Planowanie testów HP ALM
Samouczek nr 15: Planowanie testów mapy myśli
Samouczek nr 16: Plan testów JMeter i WorkBench
Czego się nauczysz:
Tworzenie planu testów - najważniejsza faza testowania
Ten samouczek informacyjny wyjaśni Ci sposoby i procedury związane z pisaniem dokumentu planu testów.
Pod koniec tego samouczka udostępniliśmy plik 19-stronicowy dokument zawierający plan testów który został stworzony specjalnie dla projektu na żywo OrangeHRM, którego używamy do tego za darmo Seria szkoleń QA
Co to jest plan testów?
Plan testów jest dokumentem dynamicznym . Sukces projektu testowego zależy od dobrze napisanego dokumentu planu testów, który jest zawsze aktualny. Plan testów jest mniej więcej podobny plan, jak przebiega testowanie mieć miejsce w projekcie.
Poniżej podano kilka wskazówek dotyczących planu testów:
# 1) Plan testów to dokument, który działa jako punkt odniesienia i tylko w oparciu o to testowanie jest przeprowadzane w zespole ds. Kontroli jakości.
#dwa) Jest to również dokument, który udostępniamy analitykom biznesowym, kierownikom projektów, zespołowi deweloperów i innym zespołom. Pomaga to zwiększyć poziom przejrzystości pracy zespołu kontroli jakości dla zespołów zewnętrznych.
# 3) Jest to dokumentowane przez kierownika ds. Zapewnienia jakości / kierownika ds. Zapewnienia jakości na podstawie informacji uzyskanych od członków zespołu ds. Zapewnienia jakości.
# 4) Planowanie testów jest zwykle przydzielane z 1/3r & Dczasu potrzebnego na całe zaangażowanie w kontrolę jakości. Pozostała 1/3r & Djest przeznaczony do projektowania testów, a reszta do wykonywania testów.
# 5) Ten plan nie jest statyczny i jest aktualizowany na żądanie.
# 6) Im bardziej szczegółowy i wszechstronny jest plan, tym skuteczniejsze będą testy.
Proces STLC
Jesteśmy teraz w połowie naszej serii projektów na żywo. Dlatego cofnijmy się o krok od aplikacji i przyjrzyjmy się procesowi cyklu życia testowania oprogramowania (STLC).
STLC można z grubsza podzielić na 3 części:
- Planowanie testów
- Projektowanie testów
- Wykonanie testu
W naszym wcześniejszym samouczku dowiedzieliśmy się, że w praktycznym projekcie kontroli jakości zaczęliśmy od przeglądu SRS i pisania scenariusza testowego - co jest właściwie drugim krokiem w procesie STLC. Projekt testu zawiera szczegółowe informacje o tym, co i jak testować.
Dlaczego nie zaczęliśmy od planowania testów?
Planowanie jest rzeczywiście pierwszą i najważniejszą czynnością, która ma miejsce w każdym projekcie testowym.
jaka jest różnica między serwerem sql i sql
Planowanie testów w fazach SDLC
Faza SDLC | Planowanie testów |
---|---|
Harmonogramy => | Przygotowanie scenariusza testowego |
Zainicjować | W idealnym przypadku zespół QA powinien zaangażować się podczas zbierania zakresu projektu od klienta / klienta w postaci wymagań biznesowych. Ale w prawdziwym świecie tak nie jest. Z praktycznego punktu widzenia zaangażowanie zespołu QA to NIL. Pod koniec tej fazy, BRD jest sfinalizowane i tworzony jest podstawowy plan projektu. |
Definiować | SRS jest tworzony z BRD. Zostaje utworzona wstępna wersja robocza planu testów. W tym momencie, ponieważ zespół QA nie przeprowadził przeglądu SRS, zakres testów nie jest jasny. Tak więc TP na tym etapie będzie zawierał tylko informacje o tym, kiedy testy mają się odbyć, informacje o projekcie i informacje o zespole (jeśli je mamy). |
Projekt | Przeprowadzany jest przegląd SRS i określany jest zakres testów. Mamy znacznie więcej informacji na temat tego, co przetestować i dobre oszacowanie liczby przypadków testowych, które możemy otrzymać itp. Tworzona jest druga wersja planu testów zawierająca wszystkie te informacje. |
Z powyższej tabeli jasno wynika, że plan testowania to nie tylko dokument, który można stworzyć wszystko naraz i używać go odtąd.
Składniki Planu Dokumentu
Pozycje w szablonie planu testów | Co one zawierają? |
---|---|
Zakres => | Scenariusze testowe / cele testów, które zostaną zweryfikowane. |
Poza zakresem => | Większa przejrzystość tego, czego nie będziemy omawiać |
Założenia => | Wszystkie warunki, które muszą być spełnione, abyśmy mogli pomyślnie działać |
Dokumentacja testowa - przypadki testowe / dane testowe / środowisko konfiguracyjne | |
Wykonanie testu | |
Cykl testowy - ile cykli | |
Data rozpoczęcia i zakończenia cykli | |
Role i obowiązki => | Lista członków zespołu |
Kto ma co robić | |
lista właścicieli modułów i ich dane kontaktowe | |
Elementy dostarczane => | Jakie dokumenty (artefakty testowe) zostaną utworzone w jakich ramach czasowych? |
Czego można się spodziewać po każdym dokumencie? | |
Środowisko => | Jakie są wymagania środowiskowe? |
Kto będzie dowodził? | |
Co robić w przypadku problemów? | |
Narzędzia => | Na przykład JIRA do śledzenia błędów |
Zaloguj sie | |
Jak korzystać z JIRA? | |
Zarządzanie defektami => | Komu zamierzamy zgłosić usterki? |
Jak mamy to zgłosić? | |
Czego oczekujemy - czy udostępniamy zrzut ekranu? | |
Ryzyko i zarządzanie ryzykiem => | Ryzyka są wymienione |
Ryzyka są analizowane - prawdopodobieństwo i wpływ są dokumentowane | |
Opracowywane są plany ograniczania ryzyka | |
Kryteria wyjścia => | Kiedy przestać testować? |
Ponieważ wszystkie powyższe informacje są najbardziej krytyczne dla codzienna praca nad projektem kontroli jakości , ważne jest, aby dokument planu był aktualizowany od czasu do czasu.
Przykładowy dokument planu testów dla aktywnego projektu
Przykładowy dokument szablonu planu testów jest tworzony dla naszego „ ORANGEHRM WERSJA 3.0 - MÓJ MODUŁ INFORMACYJNY ” Projekt i załączone poniżej. Proszę spojrzeć na to. Dodatkowe komentarze zostały dodane do dokumentu w kolorze czerwonym, aby wyjaśnić sekcje.
Ten plan testów dotyczy zarówno fazy funkcjonalnej, jak i fazy UAT. Wyjaśnia również proces zarządzania testami za pomocą narzędzia HP ALM.
Pobierz przykład planu testów:
Format dokumentu => Kliknij tutaj, aby pobrać plan testów w formacie Doc jest to ten, który stworzyliśmy dla projektu OragngeHRM na żywo i używamy go również w naszym kursie awaryjnym z testowania oprogramowania.
Format PDF => Kliknij tutaj, aby pobrać plan testów w formacie PDF .
Pliki arkuszy roboczych (.xls), o których mowa w powyższych wersjach doc / pdf => Pobierz Odniesienie do plików XLS w powyższym planie testów
Powyższy szablon jest bardzo obszerny i szczegółowy. Dlatego prosimy o dokładne przeczytanie, aby uzyskać najlepsze wyniki.
Ponieważ plan jest również dobrze stworzony i wyjaśniony, przejdźmy do następnej fazy zarówno w SDLC, jak i STLC.
Kod SDLC:
Podczas gdy reszta projektu spędzała czas na tworzeniu TDD, my QA określiliśmy zakres testowania (scenariusze testowe) i stworzyliśmy pierwszy niezawodny projekt planu testów. Następną fazą SDLC jest sprawdzenie, kiedy nastąpi kodowanie.
Programiści są głównym punktem zainteresowania całego zespołu w tej fazie. Zespół QA oddaje się również najważniejszemu zadaniu, które jest niczym innym „Tworzenie przypadku testowego” .
Gdyby scenariusze testowe brzmiały „Co testować”, wówczas przypadki testowe dotyczą „Jak testować”. Tworzenie przypadków testowych jest dominującą częścią fazy projektowania testów w STLC. Dane wejściowe dla czynności tworzenia przypadku testowego to scenariusze testowe i dokument SRS.
Dla Testerów takich jak my Przypadki testowe to prawdziwa okazja - to rzeczy, w których spędzamy większość czasu. Tworzymy je, sprawdzamy, wykonujemy, utrzymujemy, automatyzujemy - i dobrze, masz obraz. Bez względu na to, jak bardzo jesteśmy doświadczeni i jaką rolę odgrywamy w projekcie - nadal będziemy pracować z przypadkami testowymi.
Planowanie testów a wykonanie testów
Planowanie testów oprogramowania rezerwuje znacznie lepszy zakres w porównaniu z Faza STLC . Zespół testujący zapewnia dostarczanie wysokiej jakości oprogramowania. Decyzję o tym, co należy zrobić podczas testowania, decyduje się na etapie planowania testów.
Ta sekcja zapewni pełny przegląd i ilustracje przedstawiające znaczenie planowania testów i faza realizacji . Po przeczytaniu tego zrozumiesz znaczące znaczenie fazy planowania w porównaniu z fazą realizacji z większą liczbą przykłady na żywo i studia przypadków dla ilustracji .
Planowanie testów
Poniżej podano kilka podstawowych rzeczy, na które należy zwrócić uwagę podczas planowania:
Planowanie testu jest najważniejszą częścią cyklu testowania. Wynik fazy testowania zostanie określony przez jakość i zakres planowania przeprowadzonego na potrzeby testów.
Planowanie testu zwykle ma miejsce na etapie rozwoju, aby zaoszczędzić czas potrzebny na wykonanie testów za obopólną zgodą wszystkich zaangażowanych stron.
Niektóre ważne fakty, na które należy zwrócić uwagę, obejmują:
- Planowanie należy rozpocząć równolegle z rozwojem, pod warunkiem, że wymagania zostały zamrożone.
- Wszyscy interesariusze, tacy jak projektanci, programiści, klienci i testerzy, muszą być zaangażowani w finalizowanie planu.
- Planowanie nie może zostać opracowane dla niepotwierdzonych lub niezatwierdzonych potrzeb biznesowych.
- Podobne plany testów zostaną zastosowane do nowych wymagań, których będzie wymagać firma.
Przykład 1
Zespół programistów pracuje nad oprogramowaniem XYZ po otrzymaniu kilku wymagań od klientów. Zespół testowy prawie rozpoczął przygotowania do fazy definiowania lub planowania testów. Planowanie testów musi być zaprojektowane tak, aby sprostać początkowym wymaganiom przedstawionym przez klientów. Zrobił to zespół testujący.
Żaden z pozostałych zainteresowanych stron nie był zaangażowany na tym etapie, a planowanie zostało zamrożone.
Zespół programistów wprowadził teraz pewne zmiany w przepływie biznesowym, aby rozwiązać kilka problemów w swojej pracy za zgodą klienta. Teraz oprogramowanie trafiło do zespołu testującego w celu przetestowania. Z planem testowania zgodnym ze starym przepływem biznesowym, zespół testujący rozpoczął rundę testów. Wpłynęło to na wyniki testów z wieloma opóźnieniami, ponieważ zmodyfikowany przepływ biznesowy nie został udostępniony zespołowi testowemu.
Obserwacja z przykładu 1:
Z powyższego przykładu można wywnioskować pewne spostrzeżenia.
Oni są:
- Zrozumienie nowego przepływu biznesowego zajęło dużo czasu.
- Opóźnienia w produktach projektu.
- Przeróbka planowania i innych zadań w fazie.
Wszystkie te obserwacje muszą zostać przekształcone w podstawowe potrzeby w celu uzyskania skutecznego produktu testowego.
Główne komponenty w fazie planowania
Poniżej podano główne elementy, które są zaangażowane na etapie planowania.
- Strategia testów: To jedna z najważniejszych sekcji, która może wyjaśnić strategię, która będzie używana podczas testowania.
- Pokrycie testowe: Jest to zasadniczo wymagane i umożliwia mapowanie zgodności potrzeb biznesowych i przypadków testowych, aby można było upewnić się, czy całe oprogramowanie zostało przetestowane, czy nie.
- Cykle testowe i czas trwania: Może to stać się bardzo krytyczne w zależności od rund rozwoju i czasu na ukończenie każdej rundy.
- Kryteria zaliczenia / niepowodzenia: Jest to bardzo wymagane rozwiązanie, w którym zdefiniowane są kryteria zaliczenia i niezaliczenia. Kilka razy zostanie to również określone przez klientów.
- Wymagania biznesowe i techniczne: Potrzeba posiadania oprogramowania i cele, którym służy, zostaną jasno zdefiniowane wraz z wyjaśnieniami niskiego poziomu.
Ograniczenia
Jest kilka rzeczy, które mogą faktycznie kontrolować fazę testowania oprogramowania, zwłaszcza fazę planowania.
Oto kilka obszarów:
- Funkcje, które należy i nie należy testować: To jasno wskaże, co należy przetestować, a czego nie.
- Kryteria zawieszenia i wymagania dotyczące wznowienia: To jest decydent w sprawie opracowanego oprogramowania i kryteriów określonych w celu zawieszenia lub wznowienia testów.
- Obowiązki: Tester będzie miał wiele obowiązków w zakresie zapewniania problemów, błędów i defektów w testowanym oprogramowaniu. Ponadto błędy muszą zostać sprawdzone przez programistów, aby mogli je naprawić.
- Ryzyka i zdarzenia nieprzewidziane: Ryzyko związane z testowaniem powinno być jasno wymienione, a odpowiednie zdarzenia awaryjne w czasie muszą być bardzo jasno zdefiniowane.
Studium przypadku nr 1
Zespół programistów z Przykład 1 planuje wydanie oprogramowania XYZ w 2 fazach. Faza 1 ma wiele funkcji do przetestowania i kilka nie do przetestowania. Ponownie oprogramowanie zostało udostępnione do testowania bez informowania zespołu testującego o funkcjach, które nie zostały jeszcze opracowane.
Teraz zespół testujący rozpoczyna wykonywanie w oparciu o plany testów, które już opracowali. Wymyślają dużą liczbę błędów. Po zatwierdzeniu przez zespół programistów większość z nich traci ważność.
Obserwacje z powyższego studium przypadku:
- Zespół programistów do wydania oprogramowania zespołowi testującemu z uwagami do wydania i informacjami o pokryciu wymagań (uwagi do wydania).
- Funkcje, które mają być testowane, a które nie mają być testowane, muszą zostać uwzględnione na podstawie udostępnionego oprogramowania przed testowaniem.
- Kryteria zawieszenia i wznowienia badań muszą być odpowiednio zdefiniowane.
- Ryzyko i plany awaryjne związane z niedostępnością oprogramowania muszą być doskonale odwzorowane.
Przeczytaj także=> Jak zarządzać ryzykiem podczas fazy planowania testów
Plan wykonania testów
Wykonywanie przypadków testowych jest jednym z kroków w fazie STLC. Będzie to musiało być wykonane zgodnie z wcześniej opracowanymi planami. Dlatego planowanie zawsze dominuje w całej fazie testowania. Poniżej znajduje się przykład, w którym na zespół testujący wpływają zmiany w planach testów.
Przykład nr 2
Testowanie oprogramowania A rozpoczęto na podstawie planu 1 opracowanego przez zespół. Później, ze względu na potrzeby biznesowe i zmiany, plan testów musiał ulec pewnym zmianom. To z kolei wymusiło zmianę przypadków testowych lub wykonania.
Obserwacje:
kod c ++ drzewa wyszukiwania binarnego
- Plan testowania określi wykonanie przypadku testowego.
- Część wykonawcza zmienia się zgodnie z planem.
- Dopóki plan i wymagania są ważne, przypadki testowe również są ważne.
Sposoby rozwiązywania problemów podczas wykonywania
Testerzy częściej spotykają się z różnymi scenariuszami podczas wykonywania testów. To wtedy testerzy będą musieli zrozumieć i znać sposoby rozwiązania problemu lub przynajmniej znaleźć obejście problemu.
Przykład nr 3
Podczas wykonywania przypadku testowego oprogramowania B zespół testujący napotyka wiele problemów. Niewiele z nich to zatyczki do pokazów. Wymagają od programistów pomocy w rozwiązaniu problemu. Zdarzyło się to kilka razy, a rezultatem tego jest opóźnienie w testowaniu produktów.
Obserwacje:
- Istnieje zależność od rozwiązywania problemów i problemów środowiskowych.
- Od testerów wymagana jest właściwa znajomość środowiska.
- Należy udokumentować często występujące i znane problemy, aby można je było rozwiązać w przyszłości.
Kontrola i zarządzanie wersjami
Kontrola wersji zarządzanie planami testowania i przypadkami testowymi jest naprawdę ważne w celu zaprezentowania terminowych wyników. Ma to większe znaczenie i często odbywa się za pomocą narzędzia do kontroli wersji.
Narzędzie do kontroli wersji nie tylko pomaga im kontrolować plany testowania, ale także pomaga w zarządzaniu defektami. W przypadku projektów testowych z wieloma cyklami i wydaniami narzędzia te mogą naprawdę bardzo pomóc w obniżeniu wskaźników dotyczących obsługi produktów testowych.
Przeczytaj także=> Zarządzanie ryzykiem na etapie wykonywania testów
Różnica między planowaniem testów a wykonywaniem testów
Poniżej przedstawiono kilka ważnych obszarów, które wskażą, czym planowanie będzie się różniło od fazy wykonywania testów.
Obszar porównawczy | Planowanie testów | Wykonanie testu |
---|---|---|
Dostarczane pozycjonowanie | Plan testów zostanie uznany za główny produkt do wykonania testów. Będzie to pierwszy krok w procesie testowania. | Będzie to ostatni element ławki w fazie testów. Po wykonaniu stan defektów / błędów wraz ze stanem wykonania przypadku testowego zostanie udostępniony jako jeden z produktów testowych |
Osoba odpowiedzialna | Kierownik testów przygotuje plan testów i udostępni go wszystkim interesariuszom w celu ich przeglądu. | Zwykle wykonuje to tester, pamiętając, że przygotowane przypadki testowe zostały zatwierdzone i podpisane. |
Główny cel | Obszary, na których koncentruje się plan testów, to sposób przeprowadzania testów, co należy wziąć pod uwagę, a czego nie, środowisko, którego można używać, harmonogramy testów itp. | Wykonywanie testów koncentruje się głównie na wykonaniu przypadków testowych przeznaczonych do przetestowania w oprogramowaniu. |
Tryb cykliczny lub iteracyjny | To jest czynność jednorazowa. Powiedziawszy, że może, ale nie musi, wymagać modyfikacji w przyszłych wersjach oprogramowania. | Istnieją 3 części w tym obszarze, kiedy mówimy o iteracji. 1. Testy funkcjonalne. 2. Testowanie regresji. 3. Ponowne testowanie. |
Wejścia | Dane wejściowe do stworzenia planu testów są naprawdę wymagane i muszą być dostarczone przez analityków biznesowych, architektów, klientów itp., | Dokument przypadku testowego jest głównym wejściem. |
Okres, w którym można go uruchomić | Aby uzyskać skuteczny wynik i zaoszczędzić czas, należy go rozpocząć wraz z cyklem rozwoju. Ale istnieje kilka modeli, takich jak model wodospadu, w którym faza testowania rozpocznie się dopiero po zakończeniu fazy rozwojowej. | Wykonanie należy rozpocząć dokładnie po zakończeniu opracowywania oprogramowania. |
Okres zamknięcia | Plan testów nie będzie miał takiego okresu zamknięcia. Ogólnie rzecz biorąc, zostaną dostarczone podpisy wszystkich zainteresowanych stron dotyczące oprogramowania. | Wykonanie dla określonego wydania lub cyklu zostanie uznane za zakończone, gdy wszystkie przypadki testowe zostaną wykonane dla oprogramowania. |
Wykorzystanie narzędzi | Nie będzie wielu narzędzi, ponieważ planowanie będzie obejmowało więcej dyskusji i dokumentacji. Aby śledzić wszelkie zmiany w planie, kierownicy testów zwykle używają dowolnego narzędzia do kontroli wersji, takiego jak VSS lub czegoś innego. | Będzie to zależeć od trybu wykonania. W przypadku obsługi ręcznej żadne narzędzie nie zostanie użyte do wykonania. Ale do rejestrowania defektów i zarządzania nimi będą używane niektóre narzędzia. W przypadku testów automatyzacyjnych wykonanie zostanie wykonane przy pomocy takich narzędzi jak QTP, SELENIUM itp. |
Wpływ na wyniki | Będzie to miało większy wpływ na wszystkie fazy testowania | Będzie to miało wpływ na kolejny cykl lub testowaną wersję. |
Powyższe ilustracje mogłyby lepiej wyjaśnić znaczenie czynności związanych z planowaniem testów niż wykonywania testów. W pewnym sensie faza wykonania jest rodzajem podzbioru planu testowania.
W oparciu o strategię testowania, podejście i inne rzeczy, plan testowania ma większe prawdopodobieństwo zmodyfikowania go, aby dać miejsce na zmiany. Jest rzeczą jednoznaczną, że wykonanie testu zależy od przypadków testowych. Przypadki testowe są oparte na planach. Stąd zmiany w planach zapewnią zmiany w przypadkach testowych.
Ale na odwrót, zmiany w przypadkach testowych nie muszą koniecznie szukać zmian. Jest to jeden z głównych powodów, dla których planowanie utrzymuje się w porównaniu z fazą wykonywania testów.
Nasz nadchodzący samouczek wyjaśni Ci więcej na temat tworzenia przypadków testowych? Czym oni są? I jak możemy sprawić, by działały dla nas wraz z różnymi innymi aspektami związanymi z przypadkami testowymi.
NEXT Tutorial=> Szkolenie QA dzień-4: Pisanie przypadków testowych z dokumentu SRS
Czy jesteś ekspertem w pisaniu dokumentu planu testów? W takim razie jest to właściwe miejsce, aby podzielić się cennymi wskazówkami dotyczącymi ulepszeń dla przyszłych testerów. Zapraszam do wyrażenia z nami swoich przemyśleń w sekcji komentarzy poniżej !!
rekomendowane lektury
- Przykładowy szablon planu testów oprogramowania z formatem i zawartością
- Podręcznik dokumentacji testowania oprogramowania (dlaczego jest to ważne)
- Materiały i pliki do pobrania dotyczące testowania oprogramowania do kontroli jakości
- Przykładowy dokument planu testów (przykład planu testów ze szczegółami każdego pola)
- Wykonywanie testów w testowaniu oprogramowania: dokładny proces i plan na przykładzie
- Jak napisać dokument dotyczący strategii testów (z przykładowym szablonem strategii testów)
- Pisanie przypadków testowych z dokumentu SRS (POBIERZ przykładowe przypadki testowe projektu na żywo)
- Sylabus kursu testowania oprogramowania - szczegółowy plan szkolenia kursu online