Całkowity proces identyfikacji ryzyk i ich oceny.
Proces oceny modułu lub systemu bez jego wykonywania, oparty na jego formie, strukturze, zawartości lub dokumentacji.
Czynność polegająca na identyfikowaniu warunków testowych w wyniku analizy podstawy testów.
Czarnoskrzynkowa technika testowania, w której przypadki testowe są projektowane w oparciu o wartości brzegowe.
Identyfikacja wszystkich produktów pracy na które zmiana ma wpływ, w tym oszacowanie zasobów potrzebnych do przeprowadzenia zmiany.
Dowolny stan, który odchodzi od oczekiwań bazujących na specyfikacji wymagań, dokumentacji projektowej, dokumentacji użytkownika, standardach, i innych albo od czyjejś percepcji lub doświadczenia. Anomalie mogą zostać znalezione podczas: przeglądów, testowania, analizy, kompilacji albo podczas użytkowania oprogramowania lub odpowiedniej dokumentacji.
Niezależne badanie produktu pracy, procesu lub zestawu procesów wykonywane przez stronę trzecią, mające na celu ocenę zgodności ze specyfikacjami, standardami, umowami lub innymi kryteriami. .
Zdarzenie, w którym moduł lub system nie wykonuje wymaganej funkcji w określonym zakresie.
Działanie człowieka powodujące powstanie nieprawidłowego rezultatu.
Instancja procesu testowego dotycząca pojedynczej, identyfikowalnej wersji przedmiotu testów.
Czynności wykonywane na każdym etapie wytwarzania oprogramowania oraz układ ich wzajemnych relacji logicznych i chronologicznych. (SDLC - od ang. software development lifecycle).
Okres czasu rozpoczynający się, kiedy pojawi się pomysł na oprogramowanie i kończący się, gdy oprogramowanie nie jest już dostępne do użytku. Zazwyczaj cykl życia oprogramowania zawiera fazę koncepcji, fazę wymagań, fazę projektowania, fazę implementacji, fazę testów, fazę instalacji i zastępowania, fazę wykorzystania produkcyjnego i pielęgnowania oraz - czasami - fazę wycofania. Uwaga: te fazy mogą na siebie nachodzić lub mogą być wykonywane iteracyjnie.
Typ instrukcji, w którym wybór między dwoma lub więcej możliwymi wynikami skutkuje wykonaniem określonego zestawu działań.
Niedoskonałość lub wada produktu pracy, polegająca na niespełnieniu wymagań.
Zbiór warunków definiujących kiedy można oficjalnie rozpocząć określone zadanie.
(1) Zdolność organizacji w odniesieniu do skuteczności i wydajności jej procesów i praktyk pracy. (2) Stopień, w jakim moduł lub system spełnia wymagania niezawodności w normalnym działaniu.
Stopień, w jakim moduł lub system może być używany przez ludzi z szerokim zakresem cech i możliwości, by osiągnąć określony cel w określonym kontekście użycia.
Osobiste doświadczenia i reakcje z użycia lub przewidywanego użycia produktu software'owego.
Zbiór warunków definiujących kiedy można oficjalnie uznać określone zadanie za ukończone.
Jakościowa lub ilościowa miara ryzyka zdefiniowana przez wpływ i prawdopodobieństwo.
Zbiór produktów pracy, które poddane są zarządzaniu konfiguracją i traktowane jako pojedyncza składowa w procesie zarządzania konfiguracją
Część przedmiotu testów wykorzystywana w procesie testowym.
Specyficzna instancja procesu testowego.
Stopień, w jakim moduł lub system zapewnia funkcje spełniające określone i domyślne potrzeby, gdy jest używany w określonych warunkach.
Rodzaj narzędzia testowego, które pozwala na wybranie danych z istniejącej bazy danych lub ich stworzenie, wygenerowanie, przetworzenie i edycję dla użycia w testowaniu.
Liczba defektów na jednostkę wielkości produktu pracy.
Liczba defektów na jednostkę wielkości produktu pracy.
Dokumentacja wystąpienia, charakteru i statusu incydentu.
Dokumentacja wystąpienia, charakteru i statusu incydentu.
Plan testów używany do koordynowania wielu poziomów testów lub typów testów.
Harmonogram wykonywania zestawów testowych w cyklu testowym.
Harmonogram opisujący kolejność wykonywania zestawów testowych w ramach cyklu testowego.
Czynność polegająca na przygotowaniu testaliów potrzebnych do wykonania testów, oparta na analizie i projektowaniu testów.
Organizacyjne artefakty niezbędne do przeprowadzenia testu, składające się ze środowisk testowych, narzędzi testowych, wyposażenia biurowego i procedur.
Typ formalnego przeglądu przeprowadzanego w celu identyfikacji problemów w produkcie prac, dostarczający dane pomiarowe pozwalające na ulepszenie procesu przeglądu oraz procesu wytwarzania oprogramowania.
Uczestnik przeglądu, który identyfikuje problemy w produkcie pracy.
Element języka programowania, który jest zwykle najmniejszą niepodzielną jednostką wykonania.
Wyrażenie w kodzie źródłowym, które po tłumaczeniu na kod binarny będzie wykonywane w sposób proceduralny.
Rodzaj interfejsu, w którym moduły lub systemy wymieniają informacje o określonej formalnej strukturze. (API - akronim od ang. Application Programing Interface).
Wszystkie moduły systemu, które dostarczają informacji i nadzorują użytkownika, by zrealizować określone zadania systemu.
Rodzaj cyklu wytwarzania oprogramowania, w którym moduł lub system jest wytwarzany w serii powtarzanych cykli.
Zbiór ryzyk pogrupowanych według jednej lub kilku kategorii.
Metryka wspierająca ocenę wydajności procesu.
Stopień, w jakim moduł lub system może wymieniać informacje z innymi modułami lub systemami lub wykonywać wymagane funkcje, współużytkując to samo środowisko sprzętowe lub programowe.
Podejście do testów, w którym zestaw testowy obejmuje wszystkie kombinacje wartości wejściowych i warunków wstępnych.
zestaw działań mających na celu ocenę jakości modułu lub systemu.
Uczestnik przeglądu, który identyfikuje problemy w produkcie pracy.
Całkowity koszt poniesiony na działania jakościowe, na który składają się koszty działań prewencyjnych, koszty wykrycia, koszty awarii wewnętrznych i koszty awarii zewnętrznych.
Kryteria, które moduł lub system musi spełniać, aby został zaakceptowany przez użytkownika, klienta lub inny uprawniony podmiot.
Zbiór warunków definiujących kiedy można oficjalnie uznać określone zadanie za ukończone.
Zbiór warunków definiujących kiedy można oficjalnie uznać określone zadanie za ukończone.
Zbiór warunków definiujących kiedy można oficjalnie rozpocząć określone zadanie.
Zbiór warunków definiujących kiedy można oficjalnie uznać określone zadanie za ukończone.
W większych projektach osoba, która raportuje do kierownika testów i jest odpowiedzialna za zarządzanie projektem w zakresie określonego poziomu testów lub określonych czynności testowych.
Skala pomiaru i sposób jej stosowania do pomiarów.
Liczba bądź kategoria przypisana do atrybutu/cechy obiektu poprzez wykonanie pomiaru.
Czynności wykonywane na każdym etapie wytwarzania oprogramowania oraz układ ich wzajemnych relacji logicznych i chronologicznych. (SDLC - od ang. software development lifecycle).
Sekwencyjny model cyklu życia oprogramowania opisujący relację jeden-do-jednego pomiędzy głównymi fazami wytwórczymi od specyfikacji wymagań biznesowych do dostarczenia, a odpowiadającymi im poziomami testów od testów akceptacyjnych do testów modułowych.
Narzędzie programistyczne albo sprzętowe, które działa równolegle z testowanym modułem lub systemem i nadzoruje, rejestruje i/lub analizuje zachowanie modułu lub systemu.
Rodzaj narzędzia testowego, które pozwala na wybranie danych z istniejącej bazy danych lub ich stworzenie, wygenerowanie, przetworzenie i edycję dla użycia w testowaniu.
narzędzie testowe, które generuje obciążenie dla wyznaczonego elementu testowego i które mierzy i rejestruje jego wydajność podczas wykonywania testu.
Narzędzie testowe, które wykonuje testy na wyznaczonym obiekcie testowym i ocenia wyniki w stosunku do oczekiwanych wyników i warunków końcowych.
Narzędzie programistyczne albo sprzętowe, które działa równolegle z testowanym modułem lub systemem i nadzoruje, rejestruje i/lub analizuje zachowanie modułu lub systemu.
Rozdzielenie odpowiedzialności, które sprzyja zapewnieniu obiektywności testowania.
Status wyniku testu, w którym rzeczywisty wynik nie zgadza się z wynikiem oczekiwanym.
Stopień, w jakim moduł lub system wykonuje określone funkcje w określonych warunkach przez określony czas.
Formalny, o ile to możliwe obowiązkowy, zbiór wymagań stworzony i używany do opisu zalecanego spójnego podejścia do sposobu pracy lub do dostarczania wytycznych (np. normy ISO/IEC, normy IEEE lub normy w organizacjach).
Obserwowalne przewidywane zachowanie przedmiotu testów w określonych warunkach, na podstawie jego podstawy testowej.
Obserwowalne przewidywane zachowanie przedmiotu testów w określonych warunkach, na podstawie jego podstawy testowej.
Wynik kontroli, który identyfikuje pewne istotne kwestie, problemy lub możliwości.
Stopień, w jakim system lub moduł może działać prawidłowo przy nieprawidłowych danych lub przy niekorzystnych warunkach środowiskowych.
Stopień, w jakim moduł lub system jest sprawny i dostępny, gdy jest wymagane jego użycie.
Proces modyfikacji modułu lub systemu po jego wydaniu, mający na celu poprawę defektów, charakterystyk jakościowych lub dostosowanie do zmienionego środowiska.
Dokumentacja opisująca cele testowe do osiągnięcia oraz środki i harmonogram ich realizacji, zorganizowana tak, by koordynować czynności testowe.
Czynność tworzenia planów testów lub wprowadzanie do nich zmian
Niedoskonałość lub wada produktu pracy, polegająca na niespełnieniu wymagań.
Implementacja strategii testowej w określonym projekcie.
Zasób wiedzy używany jako podstawa dla analizy i projektowania testów.
Przyczyna defektu, która – gdy zostanie wyeliminowana – wystąpienie tego typu defektu redukuje lub usuwa.
Czarnoskrzynkowa technika testowania, w której przypadki testowe są projektowane na podstawie klas równoważności poprzez wybór do testów po jednym reprezentancie z każdej klasy.
Czarnoskrzynkowa technika testowania, w której przypadki testowe są projektowane na podstawie klas równoważności poprzez wybór do testów po jednym reprezentancie z każdej klasy.
Technika szacowania oparta na kompromisie, zwykle używana do oszacowania nakładu pracy lub relatywnej wielkości historyjek użytkownika, wykorzystywana na ogół w zwinnym wytwarzaniu oprogramowania. Jest modyfikacją szerokopasmowej techniki delfickiej, używającą talii kart z wartościami reprezentującymi jednostki, w których zespół dokonuje szacowania.
Stopień, w jakim określone elementy pokrycia zostały określone lub sprawdzone przez zestaw testowy wyrażony w procentach.
Pokrycie wyników decyzji.
Miary pokrycia oparte na wewnętrznej strukturze modułu lub systemu.
Stopień, w jakim określone elementy pokrycia zostały określone lub sprawdzone przez zestaw testowy wyrażony w procentach.
Dokument wysokiego poziomu opisujący zasady, podejście i główne zadania w organizacji dotyczące testowania.
Dokument wysokiego poziomu opisujący zasady, podejście i główne zadania w organizacji dotyczące testowania.
Proces przypisania liczby bądź kategorii do obiektu, mający na celu opisanie danej właściwości obiektu.
Działanie człowieka powodujące powstanie nieprawidłowego rezultatu.
Jakościowa lub ilościowa miara ryzyka zdefiniowana przez wpływ i prawdopodobieństwo.
Specyficzna instancja procesu testowego.
Poziom (biznesowej) ważności określony dla elementu, np. defektu.
Sekwencja przypadków testowych w kolejności wykonywania oraz wszelkie powiązane działania, które mogą być wymagane do ustanowienia warunków wstępnych i wszelkich czynności podsumowujących po wykonaniu.
Zbiór powiązanych ze sobą czynności obejmujący: planowanie testów, monitorowanie i nadzor nad testami, projektowanie testów, implementację testów, wykonywanie oraz ukończenie testów.
Metodyka inżynierii oprogramowania używana w ramach zwinnego wytwarzania oprogramowania. Jej podstawowe praktyki to: programowanie w parach, wykonywanie dokładnych przeglądów kodu, testowanie modułowe całego kodu, jasność i przejrzystość kodu.
Osoba zapisująca informacje podczas spotkań przeglądowych.
Atrybut lub kombinacja atrybutów uzyskana z jednego lub więcej warunków testowych za pomocą techniki testowej.
Typ przeglądu, który przebiega według zdefiniowanego procesu, z formalnie udokumentowanym wynikiem.
Przegląd wykonywany przez inne osoby o podobnych kwalifikacjach.
Technika przeglądu oparta na liście pytań lub wymaganych atrybutów.
Uczestnik przeglądu, który identyfikuje problemy w produkcie pracy.
Typ przeglądu, w którym autor przechodzi z członkami przeglądu przez produkt pracy, a członkowie zadają pytania i zgłaszają uwagi na temat ewentualnych problemów.
Ciąg możliwych zmian stanu obiektów danych.
Stopień, w jakim moduł lub system zapewnia funkcje spełniające określone i domyślne potrzeby, gdy jest używany w określonych warunkach.
Zestaw warunków wstępnych, danych wejściowych, akcji (w stosownych przypadkach), oczekiwanych rezultatów i warunków końcowych opracowany w oparciu o warunki testowe.
Typ cyklu życia oprogramowania, w którym moduł lub system wytwarzany jest w serii cyklów.
Dokumentacja wystąpienia, charakteru i statusu usterki.
Dokumentacja wystąpienia, charakteru i statusu incydentu.
Dokumentacja podsumowująca działania testowe i wyniki.
Dokumentacja wystąpienia, charakteru i statusu usterki.
Zbieranie i analizowanie danych z aktywności testowych, a następnie konsolidacja tych danych w raporcie dla interesariuszy.
Komercyjna, adaptowalna struktura iteracyjnego wytwarzania oprogramowania składająca się z czterech faz życia projektu: rozpoczęcie, opracowanie, budowa i przekazanie.
Osoba zapisująca informacje podczas spotkań przeglądowych.
Konsekwencja/wynik wykonania testu.
Konsekwencja/wynik wykonania testu.
Czynnik, który w przyszłości może skutkować negatywnymi konsekwencjami.
Ryzyko związane z charakterystyką jakościową.
Ryzyko wpływające na jakość produktu.
Ryzyko wpływające na sukces projektu.
wytworzone/zaobserwowane zachowanie się modułu lub systemu, podczas gdy ten moduł lub system jest testowany.
wytworzone/zaobserwowane zachowanie się modułu lub systemu, podczas gdy ten moduł lub system jest testowany.
Typ przeglądu, w którym autor przechodzi z członkami przeglądu przez produkt pracy, a członkowie zadają pytania i zgłaszają uwagi na temat ewentualnych problemów.
Iteracyjna, przyrostowa struktura zarządzania projektem, powszechnie stosowana w zwinnym wytwarzaniu oprogramowania.
Nieprzerwany okres czasu poświęcony na testowanie.
Osoba zapisująca informacje podczas spotkań przeglądowych.
Ciąg instrukcji wykonujący zestaw testowy.
Zakres, w jakim osiągane są poprawne i pełne cele.
Dokumentacja zestawu jednego lub więcej przypadków testowych.
Spotkanie na końcu projektu, podczas którego członkowie zespołu projektowego oceniają projekt i wyciągają wnioski, które mogą być wykorzystane w następnym projekcie.
Spotkanie na końcu projektu, podczas którego członkowie zespołu projektowego oceniają projekt i wyciągają wnioski, które mogą być wykorzystane w następnym projekcie.
Środowisko, w skład którego wchodzi sprzęt, wyposażenie, symulatory, narzędzia programistyczne oraz inne elementy wspierające, potrzebne do wykonania testu.
Formalny, o ile to możliwe obowiązkowy, zbiór wymagań stworzony i używany do opisu zalecanego spójnego podejścia do sposobu pracy lub do dostarczania wytycznych (np. normy ISO/IEC, normy IEEE lub normy w organizacjach).
standard opisujący cechy projektu lub opis projektu danych lub modułów programu.
Narzędzie, które dostarcza środowisko do testów jednostkowych lub modułowych, w takim środowisku moduł może być testowany niezależnie (w izolacji) lub z użyciem odpowiednich zaślepek i sterowników. Dostarcza również innego rodzaju wsparcia dla programistów np. możliwość debugowania.
Urządzenie, program komputerowy albo system używany podczas testowania, który przy zadanym zbiorze wejść zachowuje się lub działa tak jak dany system.
Rodzaj przedmiotu testów będącego systemem. (SUT od ang. System Under Test).
Bazująca na wiedzy eksperckiej technika estymacji opierająca się na zbiorowej wiedzy członków zespołu polegająca na dokładnym szacowaniu.
Zestaw jednego lub więcej przypadków testowych.
Produkty prac stworzone w ramach procesu testowego, używane do planowania, projektowania, wykonywania, oceny i raportowania testów.
W większych projektach osoba, która raportuje do kierownika testów i jest odpowiedzialna za zarządzanie projektem w zakresie określonego poziomu testów lub określonych czynności testowych.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Białoskrzynkowa technika testowania, w której przypadki testowe są projektowane tak, by sprawdzać wyniki decyzji.
Testowanie mające na celu określenie czy użytkownik będący osobą niepełnosprawną może używać modułu lub systemu.
Podejście do testów, w którym zestaw testowy obejmuje wszystkie kombinacje wartości wejściowych i warunków wstępnych.
Białoskrzynkowa technika testowania, w której przypadki testowe projektuje się tak, by wykonały instrukcje.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Rodzaj testów wydajnościowych, których zadaniem jest ocena zachowania modułu lub systemu przy zmieniającym się obciążeniu, na ogół pomiędzy przewidywanymi warunkami niskiego, typowego i szczytowego poziomu wykorzystania.
Testowanie oparte na lub wykorzystujące modele. (MBT - od ang. Model-Based Testing) .
Testowanie, w którym zarządzanie, wybór, priorytetyzacja i wykorzystanie działań testowych i zasobów są oparte na odpowiednich na odpowiednich typach i poziomach ryzyka.
Testowanie zmian we wdrożonym systemie lub testowanie wpływu zmienionego środowiska na wdrożony system.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Testowanie mające na celu ocenę stopnia, w jakim system może być używany przez określonych użytkowników w sposób skuteczny, wydajny i przynoszący satysfakcję w określonym kontekście użycia
Testowanie w oparciu o doświadczenie, wiedzę i intuicję testera.
Technika projektowania testów oparta na doświadczeniu, w której doświadczony tester używa listy ogólnych zagadnień, które powinny być odnotowywane, sprawdzone, zapamiętane lub zbioru reguł bądź kryteriów, względem których produkt ma być sprawdzany.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Podejście do testowania, w którym zadania testowe są planowane jako sesje testowe.
Testowanie mające na celu ustalenia współdziałania oprogramowania.
Testowanie mające na celu sprawdzenie zabezpieczeń oprogramowania.
Zbiór ryzyk pogrupowanych według jednej lub kilku kategorii.
Grupa czynności w testowaniu ukierunkowana na określone charakterystyki modułu lub systemu, oparta na specyficznych celach testowania.
Program aktywności zaprojektowany tak, by poprawić wydajność i dojrzałość procesu testowego w organizacji.
Niedoskonałość lub wada produktu pracy, polegająca na niespełnieniu wymagań.
Stopień, w jakim moduł lub system może być modyfikowany przez wyznaczony personel.
Stopień, w jakim dany moduł lub system może być używany przez określonych użytkowników dla osiągnięcia określonych celów w określonym kontekście użytkowania.
Sprawdzanie poprawności i dostarczenie obiektywnego dowodu, że produkt procesu wytwarzania oprogramowania spełnia potrzeby i wymagania użytkownika.
Minimalna lub maksymalna wartość uporządkowanej klasy równoważności.
Wymagany stan elementu testowego i jego środowiska przed wykonaniem przypadku testowego.
Oczekiwany stan elementu testowego i jego środowiska po zakończeniu wykonywania przypadku testowego.
Stopień wpływu defektu na rozwój lub działanie modułu lub systemu.
Dane otrzymane przez moduł lub system z zewnętrznego źródła.
Sprawdzenie poprawności i dostarczenie obiektywnego dowodu, że produkt procesu wytwarzania oprogramowania spełnia zdefiniowane wymagania.
Technika umożliwiająca wirtualne dostarczanie usług, które są zdalnie wdrażane, dostępne i zarządzane
Metryka wspierająca ocenę wydajności procesu.
Stosunek liczby awarii w danej kategorii do określonej jednostki miary.
Stopień, w jakim dwa lub więcej modułów lub systemów może wymieniać między sobą informacje i wykorzystywać informacje, które zostały wymienione.
Stopień, w jakim moduł lub system wykorzystuje czas, zasoby i pojemność podczas wykonywania wyznaczonych funkcji.
Dane przesyłane przez moduł lub system do zewnętrznego miejsca przeznaczenia.
Postanowienie zawierające kryteria, które należy spełnić.
Konsekwencja/wynik wykonania testu.
Konsekwencja/wynik wykonania testu.
Źródło określające oczekiwane wyniki w celu porównania z faktycznym wynikiem testowanego systemu.
Źródło określające oczekiwane wyniki w celu porównania z faktycznym wynikiem testowanego systemu.
Stopień, w jakim moduł lub system chroni informacje i dane tak, aby osoby lub inne moduły lub systemy miały stopień dostępu odpowiedni do rodzajów i poziomów autoryzacji.
Stopień, w jakim moduł lub system chroni informacje i dane tak, aby osoby lub inne moduły lub systemy miały stopień dostępu odpowiedni do rodzajów i poziomów autoryzacji.
Odpowiedź modułu lub systemu na zestaw wartości wejściowych i warunków wstępnych.
Status wyniku testu, dla którego wynik rzeczywisty jest zgodny z wynikiem oczekiwanym.
Ogół skoordynowanych czynności mających na celu kierowanie organizacją i kontrolowanie jej pod kątem jakości obejmujących zdefiniowanie polityki jakościowej i celów jakościowych, planowanie jakości, kontrolowanie jakości, zapewnienie jakości i poprawę jakości.
Planowanie, harmonogramowanie, szacowanie, monitorowanie, raportowanie, nadzór i zamykanie czynności testowych.
Szkieletowa albo specjalna implementacja modułu używana podczas produkcji lub testów innego modułu, który tę zaślepkę wywołuje albo jest w inny sposób od niej zależny. Zaślepka zastępuje wywoływany moduł.
Technika testowania, w której testy są wyprowadzane w oparciu o wiedzę testera na temat przeszłych awarii lub generalną wiedzę o trybach możliwych awarii. Uwaga tłumaczy: ten termin powinien się nazywać "defect guessing" - zgadywanie defektów, nie został zmieniony ze względu rozpowszechnienie terminu "error guessing".
Dokumentacja wystąpienia, charakteru i statusu incydentu.
Stopień, w jakim projekt lub wewnętrzna struktura modułu lub systemu jest trudna do zrozumienia, utrzymania i zweryfikowania.
Proces, w którym podejmowane są decyzje i wdrażane środki ochronne w celu zmniejszenia lub utrzymania ryzyk na określonych poziomach.
Środowisko, w skład którego wchodzi sprzęt, wyposażenie, symulatory, narzędzia programistyczne oraz inne elementy wspierające, potrzebne do wykonania testu.
Ciąg sąsiednich krawędzi w grafie skierowanym.
Ciąg sąsiednich krawędzi w grafie skierowanym.
Stopień, w jakim można ustalić relację pomiędzy dwoma lub większą liczbą produktów prac.
Środowisko dla modułu lub systemu planowane do wykorzystania w produkcji.
Środowisko, w skład którego wchodzi sprzęt, wyposażenie, symulatory, narzędzia programistyczne oraz inne elementy wspierające, potrzebne do wykonania testu.