Przypadek testowy z abstrakcyjnymi warunkami wstępnymi, danymi wejściowych, warunkami wyjściowymi, oczekiwanymi rezultatami i odpowiednimi akcjami (o ile ma to zastosowanie).
Proces oceny modułu lub systemu oparty na jego zachowaniu podczas wykonania.
Technika analizy zorientowana na identyfikację podstawowych przyczyn defektów. Przez wprowadzenie ukierunkowanych miar na podstawowe przyczyny defektów ma się nadzieję, że prawdopodobieństwo ponownego wystąpienia defektu będzie zminimalizowane.
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.
Kategoria cech oprogramowania, które mają wpływ na jakość produktu prac.
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. .
Użycie oprogramowania do wykonania lub wspierania czynności testowych, np. zarządzania testami, projektowania testów, wykonania testów i sprawdzania wyników.
Zdarzenie, w którym moduł lub system nie wykonuje wymaganej funkcji w określonym zakresie.
Technika testowania oparta wyłącznie na wewnętrznej strukturze modułu lub systemu.
Technika testowania oparta wyłącznie na wewnętrznej strukturze modułu lub systemu.
Działanie człowieka powodujące powstanie nieprawidłowego rezultatu.
Przyczyna lub powód testowania.
Kategoria cech oprogramowania, które mają wpływ na jakość produktu prac.
Kategoria cech oprogramowania, które mają wpływ na jakość produktu prac.
Kategoria cech oprogramowania, które mają wpływ na jakość produktu prac.
Praktyka wytwarzania oprogramowania polegająca na automatycznym łączeniu, integrowaniu i testowaniu wszystkich zmian w oprogramowaniu w momencie ich wprowadzania.
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.
Technika testowania oparta na analizie specyfikacji modułu lub systemu.
Technika przeglądu, w której przeglądający oceniają produkt prac z różnych punktów widzenia
Dane niezbędne do wykonania testów.
Proces wyszukiwania, analizowania i usuwania przyczyn awarii w module lub systemie.
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.
Efekt wpływu urządzenia pomiarowego na moduł lub system podczas dokonywania pomiaru, np. poprzez narzędzie do testów wydajnościowych. Przykładowo wydajność testowanego oprogramowania może być nieznacznie gorsza, kiedy stosowane jest narzędzie do testów wydajnościowych.
Stopień wykorzystania zasobów w stosunku do osiąganych wyników.
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.
(1) Osoba odpowiedzialna za prowadzenie spotkań przeglądowych. (2) Osoba, która przeprowadza sesję testów użyteczności.
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.
Wymóg użytkownika lub biznesowy składający się z jednego zdania wyrażonego w języku codziennym lub biznesowym, określający funkcjonalność której potrzebuje użytkownik, uzasadnienie, wszelkie kryteria niefunkcjonalne, a także kryteria akceptacji.
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.
Stopień w jakim moduł lub system zapobiega nieautoryzowanemu dostępowi oraz modyfikacji modułu, systemu lub danych.
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.
Stopień, w jakim moduł, system lub proces spełnia określone wymagania i/lub spełnia potrzeby i oczekiwania klienta lub użytkownika.
Środowisko testowe składające się z zaślepek i sterowników potrzebnych do wykonania testu.
Dokument opisujący cel lub zadania dla sesji testów.
Dokument opisujący cel lub zadania dla sesji testów.
Osoba odpowiedzialna za zarządzanie działaniami testowymi, zasobami i oceną przedmiotu testów.
Podzbiór dziedziny wartości zmiennej w module lub systemie, dla którego zakłada się, na podstawie specyfikacji, że wszystkie wartości będą traktowane przez system w podobny sposób.
Podzbiór dziedziny wartości zmiennej w module lub systemie, dla którego zakłada się, na podstawie specyfikacji, że wszystkie wartości będą traktowane przez system w podobny sposób.
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.
Przypadek testowy z konkretnymi warunkami wstępnymi, wartościami wejściowymi, wynikami oczekiwanymi, warunkami wyjściowymi i odpowiednimi akcjami (o ile ma to zastosowanie).
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.
(1) Osoba odpowiedzialna za prowadzenie spotkań przeglądowych. (2) Osoba, która przeprowadza sesję testów użyteczności.
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.
Przypadek testowy z abstrakcyjnymi warunkami wstępnymi, danymi wejściowych, warunkami wyjściowymi, oczekiwanymi rezultatami i odpowiednimi akcjami (o ile ma to zastosowanie).
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).
Struktura, w której procesy tego samego rodzaju są sklasyfikowane w ogólnym modelu.
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.
Model pokazujący poprawę niezawodności modułu lub systemu w czasie jako wynik usuwania defektów.
(1) Osoba odpowiedzialna za prowadzenie spotkań przeglądowych. (2) Osoba, która przeprowadza sesję testów użyteczności.
Stopień, w jakim system jest zbudowany z oddzielnych elementów w ten sposób, że zmiana jednego elementu ma minimalny wpływ na inne elementy.
Aktywność polegająca na sprawdzaniu status aktywności testowych, identyfikowaniu odchylenia od planu lub oczekiwanego statusu oraz raportowaniu statusu do interesariuszy.
Działalność, która rozwija i stosuje działania naprawcze, aby utrzymać w toku testy projektu, gdy odbiegają one od tego, co zostało zaplanowane.
Technika analizy zorientowana na identyfikację podstawowych przyczyn defektów. Przez wprowadzenie ukierunkowanych miar na podstawowe przyczyny defektów ma się nadzieję, że prawdopodobieństwo ponownego wystąpienia defektu będzie zminimalizowane.
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 wspomagające zarządzanie testami i sterowanie częścią procesu testowego. Zwykle ma kilka funkcji takich jak: zarządzanie testaliami, planowanie testów w czasie, logowanie rezultatów, śledzenie postępu prac, zarządzanie incydentami oraz raportowanie wyników testów.
Oprogramowanie lub sprzęt, który obsługuje jedno lub więcej działań testowych.
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.
historyjka użytkownika, która ze względu na swój duży rozmiar nie może być dostarczona w ramach jednej iteracji lub jest na tyle duża, że może być podzielona na mniejsze historyjki użytkownika.
Oprogramowanie stanowiące produkt wytworzony na szeroki rynek, tj. dla dużej liczby klientów, które jest dostarczane wielu klientom w identycznej postaci. (COTS od ang. Commercial off-the-Shelf).
Oprogramowanie stanowiące produkt wytworzony na szeroki rynek, tj. dla dużej liczby klientów, które jest dostarczane wielu klientom w identycznej postaci. (COTS od ang. Commercial off-the-Shelf).
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.
Podejście do wytwarzania oprogramowania, w którym przypadki testowe są projektowane i wdrażane przed opracowaniem odpowiedniego modułu lub systemu.
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.
Pokrycie wykonywalnych instrukcji kodu.
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.
Rodzaj testów akceptacyjnych wykonywanych w celu ustalenia, czy operatorzy i / lub administratorzy systemu mogą go zaakceptować.
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.
Czynność wyprowadzania i specyfikowania przypadków testowych z warunków testowych.
Technika testowania oparta na analizie specyfikacji modułu lub systemu.
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.
Moduł lub system podlegający testowaniu.
Typ testowania statycznego, podczas którego produkt pracy lub proces jest oceniany przez jedną lub więcej osób w celu wykrycia problemów i wprowadzenia ulepszeń.
Technika przeglądu przeprowadzana nieformalnie bez ustrukturyzowanego procesu.
Typ przeglądu, który przebiega według zdefiniowanego procesu, z formalnie udokumentowanym wynikiem.
Przegląd wykonywany przez inne osoby o podobnych kwalifikacjach.
Rodzaj przeglądu bez formalnego procesu, nie posiadający formalnie udokumentowanych wyników.
Technika przeglądu oparta na liście pytań lub wymaganych atrybutów.
Technika przeglądu, w której przeglądający oceniają produkt prac z różnych punktów widzenia
Technika przeglądu, w której produkt pracy jest oceniany z perspektywy różnych interesariuszy.
Technika przeglądu, w której ocenia się produkt pracy w celu ustalenia jego zdolności do wykonywania określonych scenariuszy.
Typ formalnego przeglądu przeprowadzany przez wykwalifikowany zespół technicznych specjalistów, którzy sprawdzają jakość produktu prac oraz identyfikują odchylenia od specyfikacji i standardó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.
Łatwość, z jaką moduł lub system może zostać przeniesiony z jednego sprzętowego lub programistycznego środowiska do innego.
Ciąg możliwych zmian stanu obiektów danych.
Kolejność, w jakiej wykonywane są operacje podczas wykonywania elementu 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.
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.
Przypadek testowy z konkretnymi warunkami wstępnymi, wartościami wejściowymi, wynikami oczekiwanymi, warunkami wyjściowymi i odpowiednimi akcjami (o ile ma to zastosowanie).
Przypadek testowy z abstrakcyjnymi warunkami wstępnymi, danymi wejściowych, warunkami wyjściowymi, oczekiwanymi rezultatami i odpowiednimi akcjami (o ile ma to zastosowanie).
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.
Rodzaj raportu z testów, wykonywany w regularnych odstępach czasu o postępie w testach na podstawie podstawy testów, ryzyka i alternatyw wymagających decyzji.
Rodzaj raportu z testów, wykonywany w regularnych odstępach czasu o postępie w testach na podstawie podstawy testów, ryzyka i alternatyw wymagających decyzji.
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.
Rodzaj testu związanego ze zmianą przeprowadzonego po naprawieniu defektu w celu potwierdzenia, że awaria spowodowana przez ten defekt już nie występuje.
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.
Typ modelu cyklu wytwarzania oprogramowania, w którym kompletny system jest wytwarzany sekwencyjnie w oddzielnych, kolejnych, niezachodzących na siebie fazach.
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.
Tymczasowy moduł lub narzędzie, które zastępuje inny moduł i steruje lub wywołuje izolowany element testowy.
Tymczasowy moduł lub narzędzie, które zastępuje inny moduł i steruje lub wywołuje izolowany element testowy.
Dokumentacja zgodna z polityką testową, która opisuje ogólne wymagania dotyczące testowania oraz szczegółowe informacje na temat przeprowadzania testów w organizacji.
Dokumentacja zgodna z polityką testową, która opisuje ogólne wymagania dotyczące testowania oraz szczegółowe informacje na temat przeprowadzania testów w organizacji.
Technika testowania oparta wyłącznie na wewnętrznej strukturze modułu lub systemu.
Raport z testów, który zawiera ocenę odpowiednich pozycji testowych w odniesieniu do kryteriów wyjścia.
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).
Obliczona aproksymacja wyniku związana z różnymi aspektami testowania (takimi jak wysiłek, data zakończenia, poniesione koszty, ilość przypadków testowych itp.), która jest użyteczna, nawet gdy dane wejściowe są niekompletne, niepewne lub zakłócone.
Bazująca na wiedzy eksperckiej technika estymacji opierająca się na zbiorowej wiedzy członków zespołu polegająca na dokładnym szacowaniu.
Technika testowania oparta wyłącznie na wewnętrznej strukturze modułu lub systemu.
Technika testowania oparta tylko o doświadczenie, wiedzę i intuicję testera.
Technika testowania oparta tylko o doświadczenie, wiedzę i intuicję testera.
Technika testowania oparta wyłącznie na wewnętrznej strukturze modułu lub systemu.
Technika testowania oparta tylko o doświadczenie, wiedzę i intuicję testera.
Procedura używana do definiowania warunków testowych, projektowania przypadków testowych i określania danych testowych.
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.
Wykwalifikowany profesjonalista, zaangażowany w testowanie modułu lub systemu.
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.
Stopień, w jakim można ustalić warunki testowe dla modułu lub systemu oraz sprawdzić czy testy można przeprowadzić w celu ustalenia, czy warunki te zostały spełnione.
Proces składający się ze wszystkich czynności cyklu życia, zarówno statycznych, jak i dynamicznych, skoncentrowany na planowaniu, przygotowaniu i ewaluacji oprogramowania oraz powiązanych produktów w celu określenia, czy spełniają one wyspecyfikowane wymagania, na wykazaniu, że są one dopasowane do swoich celów oraz na wykrywaniu usterek.
Poziom testów zorientowany na ustalenie, czy zaakceptować system.
Rodzaj testu akceptacyjnego wykonywanego w celu ustalenia, czy użytkownicy dla których przeznaczony jest system, akceptują go.
Rodzaj testu akceptacyjnego wykonywanego w celu ustalenia, czy użytkownicy dla których przeznaczony jest system, akceptują go.
Rodzaj testów akceptacyjnych przeprowadzanych w celu sprawdzenia, czy system jest zgodny z prawem, odpowiednimi zasadami i przepisami.
Rodzaj testów akceptacyjnych przeprowadzonych w celu sprawdzenia, czy system spełnia wymagania umowy.
Rodzaj testów akceptacyjnych wykonywanych w środowisku testowym programisty przez osoby spoza organizacji wytwórczej.
Rodzaj testów akceptacyjnych przeprowadzanego poza środowiskiem testowym organizacji wytwórczej przez osoby spoza organizacji.
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.
Testowanie, podczas którego wykonywany jest kod modułu lub systemu.
Podejście do testowania, w którym testerzy dynamicznie projektują i przeprowadzają testy na podstawie swojej wiedzy, badania elementu testowego i wyników z poprzednich testów.
Testowanie wykonywane by ocenić czy moduł lub system spełnia wymagania funkcjonalne.
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.
Testy wykonywane w celu wykrycia usterek w interfejsach i interakcjach pomiędzy integrowanymi modułami.
Poziom testów koncentrujący się na interakcjach między modułami lub systemami.
Testowanie wykonywane w celu wykrycia defektów w interfejsach i interakcjach pomiędzy modułami lub systemami.
Poziom testów, który koncentruje się na poszczególnych modułach sprzętowych lub programowych.
Poziom testów, który koncentruje się na poszczególnych modułach sprzętowych lub programowych.
Poziom testów, który koncentruje się na poszczególnych modułach sprzętowych lub programowych.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Testowanie przeprowadzane w celu sprawdzenia zgodności modułu lub systemu z wymaganiami niefunkcjonalnymi.
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) .
Czarnoskrzynkowa technika testowania, w której przypadki testowe są projektowane w celu wykonywania zachowań przypadków użycia.
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.
Technika skryptowa wykorzystująca skrypty zawierające wysokopoziomowe słowa kluczowe oraz pliki wspomagające, zawierające niskopoziomowe skrypty implementujące te słowa kluczowe.
Technika skryptowa wykorzystująca skrypty zawierające wysokopoziomowe słowa kluczowe oraz pliki wspomagające, zawierające niskopoziomowe skrypty implementujące te słowa kluczowe.
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.
Rodzaj testu związanego ze zmianą przeprowadzonego po naprawieniu defektu w celu potwierdzenia, że awaria spowodowana przez ten defekt już nie występuje.
Testy wykonywane w celu wykrycia usterek w interfejsach i interakcjach pomiędzy integrowanymi modułami.
Czarnoskrzynkowa technika testowania, w której przypadki testowe są zaprojektowane tak, by wykonywać elementy modelu przejścia stanów.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Rodzaj testowania związanego ze zmianami mającego na celu wykrycie, czy defekty zostały wprowadzone lub odkryte w niezmienionych obszarach oprogramowania.
Czarnoskrzynkowa technika testowania, w której przypadki testowe są zaprojektowane tak, by wykonywać elementy modelu przejścia stanów.
Testowanie produktu prac bez uruchamiania kodu.
Technika skryptowa wykorzystująca pliki danych do przechowywania danych testowych i wyników oczekiwanych, które są potrzebne do wykonania skryptów testowych.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Poziom testów, który koncentruje się na sprawdzeniu, czy system jako całość spełnia określone wymagania.
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.
Czarnoskrzynkowa technika testowania, w której przypadki testowe są projektowane w celu wykonywania zachowań przypadków użycia.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Czarnoskrzynkowa technika testowania, w której przypadki testowe są projektowane w celu wykonania kombinacji wejść i wynikających akcji, ujęte w formie tablicy decyzyjnej.
Czarnoskrzynkowa technika testowania, w której przypadki testowe są projektowane w celu wykonywania zachowań przypadków użycia.
Podejście do testowania, w którym zadania testowe są planowane jako sesje testowe.
Testowanie mające na celu ustalenia współdziałania oprogramowania.
Proces testowy mający na celu określenie wydajności oprogramowania.
Testowanie mające na celu sprawdzenie zabezpieczeń oprogramowania.
Typ testowania inicjowany przez modyfikację modułu lub systemu.
Grupa czynności w testowaniu ukierunkowana na określone charakterystyki modułu lub systemu, oparta na specyficznych celach testowania.
Czynność obejmująca udostępnianie testaliów dla późniejszego użycia, pozostawianie środowisk testowych w zadowalającym stanie i komunikowanie wyników testowania odpowiednim interesariuszom.
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.
Wyrażenie logiczne, którego wartością może być prawda albo fałsz.
Wyrażenie logiczne, którego wartością może być prawda albo fałsz.
Testowalna własność modułu lub systemu zidentyfikowana jako podstawa do testowania.
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.
Jednoczesne wykonywanie wielu niezależnych wątków przez moduł lub system.
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.
Błąd dostępu do pamięci w logice programu wykonującego dynamiczną alokację pamięci polegający na niezwalnianiu pamięci po zaprzestaniu jej używania.
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.
Czynność polegająca na przeprowadzeniu testu modułu lub systemu, by otrzymać rzeczywiste wyniki.
Postanowienie zawierające kryteria, które należy spełnić.
Testowalna własność modułu lub systemu zidentyfikowana jako podstawa do testowania.
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.
Działania skoncentrowane na zapewnieniu, że wymagania jakościowe będą spełnione.
Proces rozpoznawania, rejestrowania, klasyfikacji, badania, rozwiązywania i usuwania defektów.
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.
Dyscyplina używająca technicznych i administracyjnych metod kierowania i nadzoru w celu określenia i udokumentowania charakterystyk funkcjonalnych i fizycznych elementów konfiguracji, kontroli zmian tych charakterystyk, zapisywania i raportowania wykonywania zmian i statusu implementacji oraz weryfikacji zgodności z wyspecyfikowanymi wymaganiami.
Proces radzenia sobie z ryzykiem.
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ł.
Zestaw wykonywanych przypadków testowych lub procedur testowych.
Zestaw wykonywanych przypadków testowych lub procedur testowych.
Zestaw wykonywanych przypadków testowych lub procedur testowych.
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".
Zgodność produktu pracy ze standardami, konwencjami lub przepisami prawnymi i innymi podobnymi przepisami.
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.
Stopień, w jakim produkt pracy może być użyty w więcej niż jednym systemie lub w budowie innych produktów prac.
Ś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.