Przypadek testowy z abstrakcyjnymi warunkami wstępnymi, danymi wejściowych, warunkami wyjściowymi, oczekiwanymi rezultatami i odpowiednimi akcjami (o ile ma to zastosowanie).
Stopień, w jakim funkcje ułatwiają realizację określonych zadań i celów.
Strategia testowa, podczas której zespół testowy analizuje podstawę testów, by zidentyfikować te warunki testowe, które należy pokryć.
Metoda używana do analizy przyczyn usterek (defektów). Technika modeluje wizualnie jak związki logiczne pomiędzy awariami, błędami człowieka i zewnętrznymi zdarzeniami mogą powodować powstawanie specyficznych defektów. (FTA - akronim od angielskiego Fault Tree Analysis)
Metoda używana do analizy przyczyn usterek (defektów). Technika modeluje wizualnie jak związki logiczne pomiędzy awariami, błędami człowieka i zewnętrznymi zdarzeniami mogą powodować powstawanie specyficznych defektów. (FTA - akronim od angielskiego Fault Tree Analysis)
Proces oceny modułu lub systemu oparty na jego zachowaniu podczas wykonania.
Statystyczna technika podejmowania decyzji, używana do wyboru ograniczonej liczby czynników, które powodują znaczący ogólny efekt. Wyrażona w kategoriach poprawy jakości brzmi następująco: większość problemów (80%) jest powodowana przez stosunkowo niewielką liczbę przyczyn (20%).
Rodzaj analizy statycznej przeprowadzanej w oparciu o cykl życia zmiennych.
Forma analizy statycznej oparta na reprezentacji unikalnych ścieżek wykonywanych podczas działania modułu lub systemu.
Systematyczne podejście do identyfikacji i analizy ryzyka polegające na wskazywaniu możliwych stanów awarii i zapobieganiu ich wystąpieniu.
Systematyczne podejście do identyfikacji i analizy ryzyka polegające na wskazywaniu możliwych stanów awarii i zapobieganiu ich wystąpieniu.
Czarnoskrzynkowa technika projektowania przypadków testowych, w której przypadki te są projektowane na podstawie grafów przyczynowo-skutkowych.
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.
Metoda umożliwiająca szacowanie czasu testów oparta na analizie punktów funkcyjnych. (TPA - akronim od angielskiego Test Point Analysis)
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.
Analiza kodu źródłowego przeprowadzona bez wykonywania oprogramowania.
Czynność polegająca na identyfikowaniu warunków testowych w wyniku analizy podstawy testów.
Analiza transakcji pomiędzy ludźmi oraz wewnątrz ich umysłów, transakcja jest zdefiniowana jako bodziec i reakcja. Transakcja ma miejsce pomiędzy ludźmi a stanami ego (częściami osobowości) w umyśle osoby.
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.
Narzędzie wykonujące analizę statyczną.
Narzędzie wykonujące analizę statyczną.
Ewaluacja użyteczności, podczas której reprezentatywna próbka użytkowników jest proszona do zgłaszania subiektywnych uwag w kwestionariuszu w oparciu o ich doświadczenie w używaniu modułu lub systemu.
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.
Oprogramowanie używane do wykrywania i niszczenia złośliwego oprogramowania (malware).
Powtarzalna akcja, proces, struktura lub rozwiązanie wielokrotnego użytku, które początkowo wydawało się korzystne i jest często używane, ale jest nieskuteczne i/lub nieproduktywne w zastosowaniu.
(1) Osoba, która definiuje zalecenia i kierunki strategiczne dla organizacji testów i jej związków z innymi dziedzinami. (2) Osoba która definiuje sposób, w jaki testy są modelowane dla danego systemu, włączając w to takie zagadnienia jak narzędzia testowe i zarządzanie danymi testowymi.
Instancja ogólnej architektury testów automatycznych definiująca rozwiązania testów automatycznych, tzn. jej warstw, modułów, usług i interfejsów.
Przechwycenie, naśladowanie lub modyfikowanie oraz następnie przesłanie wiadomości (np. transakcji kartą kredytową) przez stronę trzecią w ten sposób, że użytkownik pozostaje nieświadomy jej istnienia.
Próba uzyskania nieautoryzowanego dostępu do modułu lub systemu, zasobów, informacji lub próba naruszenia integralności systemu.
Osoba lub proces, który ma zamiar mieć dostęp do danych, funkcji lub innych zastrzeżonych obszarów systemu bez autoryzacji, potencjalnie ze złośliwą intencją.
Stopień, w jakim interfejs użytkownika umożliwia przyjemną i satysfakcjonującą interakcję dla użytkownika.
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. .
Audyt sprawdzający procesy zabezpieczeń oraz infrastrukturę w organizacji.
Stopień, w jakim można udowodnić tożsamość podmiotu lub zasobu.
Użycie oprogramowania do wykonania lub wspierania czynności testowych, np. zarządzania testami, projektowania testów, wykonania testów i sprawdzania wyników.
Użycie oprogramowania, np. narzędzia rejestrująco-odtwarzającego, w celu kontrolowania wykonania testu, porównania rezultatów rzeczywistych z oczekiwanymi, ustawienia warunków wstępnych testu i innych funkcji kontroli i raportowania testu.
Zgoda udzielana użytkownikowi lub procesowi do dostępu do zasobów.
Zdarzenie, w którym moduł lub system nie wykonuje wymaganej funkcji w określonym zakresie.
Brak nieuzasadnionego ryzyka spowodowanego zagrożeniami wynikającymi z nieprawidłowego działania układów elektrycznych / elektronicznych (E/E)
Brak nieuzasadnionego ryzyka spowodowanego zagrożeniami wynikającymi z nieprawidłowego działania układów elektrycznych / elektronicznych (E/E)
Strategia testowa, zgodnie z którą zespół testowy polega na danych dostarczanych przez jednego lub kilku kluczowych interesariuszy przy określaniu szczegółów strategii.
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.
Atak na zabezpieczenia, mający na celu przeładowanie systemu żądaniami tak, by uprawnione żądania nie mogły być obsługiwane.(od ang. DoS Denial of Service)
Sieć zaatakowanych komputerów, zwanych botami lub robotami, sterowana przez osoby trzecie i używana do przesyłania zagrożeń lub spamu lub do przeprowadzania ataków.
Testowanie komponentu lub systemu niezgodnie z jego przeznaczeniem.
Działanie człowieka powodujące powstanie nieprawidłowego rezultatu.
Podejście do mierzenia oprogramowania przy użyciu trzypoziomowego modelu: poziom konceptualny (cel), poziom operacyjny (pytanie) i poziom ilościowy (metryka).
Przyczyna lub powód testowania.
Proces potwierdzający, że moduł, system lub osoba spełnia określone wymagania.
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.
Podejście obejmujące proces wczesnego, częstego, szerokiego, automatycznego testowania w celu otrzymania możliwie szybko informacji zwrotnej o poziomie ryzyka biznesowego związanego z aplikacją przed jej wydaniem
Atak, który pozwala atakującemu na wstrzykniecie złośliwego kodu w czyjąś dotychczas bezpieczną stronę internetową.
Iteracyjny, czterokrokowy (zaplanuj – wykonaj – sprawdź – zastosuj) proces rozwiązywania problemów, mający zastosowanie w doskonaleniu procesów.
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.
ilość czasu wymagana do tego, by użytkownik zidentyfikował i wykonał kolejną akcję w sekwencji swoich działań.
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.
Narzędzie używane przez programistów do odtwarzania awarii, śledzenia stanu programu i odszukiwania usterek. Debugery umożliwiają programistom wykonywanie programów krok po kroku, zatrzymywanie wykonania programu na dowolnej instrukcji oraz sprawdzanie i ustawianie wartości zmiennych.
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.
Faza w modelu IDEAL, podczas której określa się aktualny stan w stosunku do pożądanego. Faza diagnozowania składa się z czynności charakteryzujących stany bieżący i pożądany oraz opracowanie rekomendacji.
Graficzny model używany do organizowania i przedstawienia związków pomiędzy różnymi możliwymi podstawowymi przyczynami problemu. Możliwe przyczyny rzeczywistego lub potencjalnego defektu lub awarii są porządkowane w kategoriach i podkategoriach poziomej struktury drzewiastej, z (potencjalnym) defektem lub awarią umieszczoną w korzeniu drzewa.
Graf skierowany przedstawiający wszystkie możliwe przebiegi sterowania w module lub systemie.
Graficzny model używany do organizowania i przedstawienia związków pomiędzy różnymi możliwymi podstawowymi przyczynami problemu. Możliwe przyczyny rzeczywistego lub potencjalnego defektu lub awarii są porządkowane w kategoriach i podkategoriach poziomej struktury drzewiastej, z (potencjalnym) defektem lub awarią umieszczoną w korzeniu drzewa.
Graficzny model używany do organizowania i przedstawienia związków pomiędzy różnymi możliwymi podstawowymi przyczynami problemu. Możliwe przyczyny rzeczywistego lub potencjalnego defektu lub awarii są porządkowane w kategoriach i podkategoriach poziomej struktury drzewiastej, z (potencjalnym) defektem lub awarią umieszczoną w korzeniu drzewa.
(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 zapewnia prawidłowe wyniki z wymaganą precyzją.
Program czynności zaprojektowanych w celu poprawy wydajności i dojrzałości procesów wytwarzania oprogramowania w organizacji oraz wyniki tego programu. (SPI - od ang. Software Process Improvement) .
Osoba wprowadzająca udoskonalenia w procesie testowym zgodnie z planem doskonalenia testów.
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.
Drzewo obrazujące dziedziny danych przedmiotu testów.
Menedżer wyższego szczebla zarządzający kierownikami testów.
Faza w modelu IDEAL, podczas której ulepszenia są opracowywane, wdrażane i stosowane w organizacji. Faza „działania” składa się z następujących czynności: tworzenie rozwiązania, wdrożenie pilotowe/testowe rozwiązania, ulepszenie rozwiązania, pełne wdrożenie rozwiązania.
Chronologiczny zapis szczegółów związanych z wykonaniem testów.
Wskaźnik, który wskazuje na adres, który jest poza zakresem tego wskaźnika lub który nie istnieje.
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.
Nieformalny przegląd użyteczności, w którym przeglądający są ekspertami. Ekspertami mogą być eksperci od użyteczności i/lub przedmiotowi.
Nieproporcjonalny wzrost liczby przypadków testowych wraz ze wzrostem wielkości podstawy testów, przy zastosowaniu określonej techniki projektowania testów. Eksplozja przypadków testowych może również zdarzyć się przy systematycznym stosowaniu techniki projektowania testów po raz pierwszy.
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.
Urządzenie, program komputerowy lub system, który przyjmuje takie same wejścia i generuje takie same wyjścia jak dany system.
Stopień, w jakim interfejs użytkownika umożliwia przyjemną i satysfakcjonującą interakcję dla użytkownika.
Specyficzna instancja procesu testowego.
Tester zabezpieczeń używający technik hakerskich.
(1) Osoba odpowiedzialna za prowadzenie spotkań przeglądowych. (2) Osoba, która przeprowadza sesję testów użyteczności.
Wyróżniony zbiór aktywności testowych zebrany w podlegającą zarządzaniu fazę projektu, np. wykonanie testów na jakimś poziomie testów.
Moduł lub zbiór modułów, które kontrolują ruch sieciowy - wchodzący i wychodzący - zgodnie z określonymi z góry zasadami bezpieczeństwa.
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.
Technika testowania oprogramowania używana do wykrywania zagrożeń zabezpieczeń przez wprowadzanie bardzo dużej liczby losowych danych, zwanych "fuzz" (ang. farfocle), do modułu lub systemu.
Przeniesienie sterowania z miejsca w kodzie będącego instrukcją decyzyjną do innego miejsca w kodzie.
Narzędzie generujące obciążenie dla testowanego 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.
proces symulowania określonego zbioru czynności pod określonym obciążeniem, które mają być wykonane przez moduł lub system.
Graficzna reprezentacja wejść i/lub bodźców (przyczyn) z odpowiadającymi im wyjściami (skutkami), które mogą być wykorzystane do projektowania przypadków testowych.
Abstrakcyjna reprezentacja przedstawiająca odwołania pomiędzy procedurami i funkcjami w programie.
Rodzaj interfejsu, który umożliwia użytkownikom interakcję z komponentem lub systemem za pomocą graficznych ikon i wizualnych wskaźników. (GUI od ang. Graphical User Interface).
Zespół specjalistów (od testów), którzy ułatwiają zdefiniowanie, pielęgnowanie i poprawianie procesu testowego używanego w organizacji. (TPG - od ang. Test Process Group)
Liczba defektów na jednostkę wielkości produktu pracy.
Gęstość defektów modułu zawierającego kod testów automatycznych.
Liczba defektów na jednostkę wielkości produktu pracy.
Dokumentacja wystąpienia, charakteru i statusu incydentu.
Dokumentacja wystąpienia, charakteru i statusu incydentu.
Osoba, która kieruje procesem oceny. W pewnych przypadkach, np. w CMMI oraz TMMi, gdy dokonywana jest formalna ocena, główny oceniający musi być akredytowany i formalnie przeszkolony.
Plan testów używany do koordynowania wielu poziomów testów lub typów testów.
Osoba lub organizacja aktywnie zaangażowana w ataki na zabezpieczenia, na ogół z intencją szkodzenia. .
Harmonogram wykonywania zestawów testowych w cyklu testowym.
Harmonogram opisujący kolejność wykonywania zestawów testowych w ramach cyklu testowego.
Transformacja zmiennej znakowej o zmiennej długości do na ogół krótszej, o stałej długości lub na klucz. Zhaszowane wartości, hasze, są często używane przy sprawdzeniu w tabeli lub bazie danych. Kryptograficzne funkcje haszujące są używane do zabezpieczania danych.
Ogólnie rozpoznawalna praktyczna zasada wspomagająca osiągnięcie celu.
Wskaźnik w dokumencie elektronicznym, który stanowi odwołanie do innego dokumentu elektronicznego.
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.
Model doskonalenia organizacji, który może być wykorzystywany jako harmonogram przy rozpoczynaniu, planowaniu i wdrażaniu ulepszeń. Nazwa modelu IDEAL jest akronimem od angielskich nazw pięciu faz opisywanych przez model: rozpoczęcie (ang. initializing), diagnozowanie (ang. diagnosis), ustanawianie (ang. establishing), działanie (ang. acting) oraz uczenie się (ang. learning).
Proces znajdowania, rozpoznawania i opisywania ryzyka.
Czynność polegająca na przygotowaniu testaliów potrzebnych do wykonania testów, oparta na analizie i projektowaniu testów.
Każde zdarzenie wymagające zbadania.
Każde zdarzenie wymagające zbadania.
Każde zdarzenie wymagające zbadania.
Praktyka określająca dlaczego atak na zabezpieczenia się powiódł i oceniająca wyrządzone szkody.
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.
Stopień, w jakim moduł lub system może zostać pomyślnie zainstalowany lub odinstalowany w określonym środowisku.
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.
Zdolność, umiejętność i biegłość w identyfikowaniu, ocenie i zarządzaniu emocjami własnymi, innych ludzi lub grup.
Rodzaj interfejsu, w którym informacje są przekazywane w postaci linii komend. (CLI od ang. Command-Line Interface).
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.
Komercyjna usługa analizy stron internetowych, dostarczająca kwestionariusz do pomiaru satysfakcji użytkowników i oceny realizacji celów biznesowych online. (WAMMI - od ang. Website Analysis and MeasureMent Inventory).
Oparte na kwestionariuszach narzędzie do testowania użyteczności, które mierzy i porównuje doświadczenie użytkowników. (SUMI – od ang. Software Usability Measurement Inventory).
Osoba odpowiedzialna za projektowanie, implementację i pielęgnację architektury testów automatycznych, jak też za techniczny rozwój skutecznych rozwiązań testów automatycznych.
Systematyczna ocena procesu pozyskiwania, dostarczania, wytwarzania eksploatacji lub pielęgnacji oprogramowania przez kierownictwo lub w jego imieniu, monitorująca postęp, określająca status planów i harmonogramów, potwierdzająca wymagania i ich alokację systemową lub oceniająca skuteczność podejść do zarządzania w celu osiągnięcia przydatności do określonego celu.
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.
Spojrzenie na jakość, w którym pojęcie jakości jest oparte na dobrze zdefiniowanym zbiorze atrybutów jakości, te atrybuty muszą być mierzalne w sposób obiektywny i ilościowy. Różnice w jakości produktów tego samego typu muszą się dawać prześledzić aż do sposobu, w jaki konkretne atrybuty jakości zostały urzeczywistnione.
Spojrzenie na jakość, zgodnie z którym jakość nie może być dokładnie zdefiniowana, ale rozpoznajemy ją, gdy ją widzimy lub jesteśmy świadomi jej braku, gdy nie występuje. Jakość zależy od percepcji oraz odczucia jednostki lub grupy w stosunku do produktu.
Spojrzenie na jakość, zgodnie z którym jakość to zdolność zaspokojenia potrzeb, pragnień i wymagań użytkownika (użytkowników). Jest to warunkowe, uzależnione od kontekstu podejście do jakości, ponieważ różne właściwości biznesowe wymagają różnych jakości produktu.
Spojrzenie na jakość, zgodnie z którym jakość jest zdefiniowana przez cenę. Jakość produktu lub usługi rozumiemy jako to, co dostarcza pożądanego wykonania przy akceptowalnym koszcie. Jakość jest określana w procesie decyzyjnym interesariuszy na zasadzie "coś za coś", czynniki brane pod uwagę to czas, pracochłonność i koszt.
Spojrzenie na jakość, zgodnie z którym jakość jest mierzona przez stopień, w jakim produkt lub usługa jest zgodna z zamierzonym projektem i wymaganiami. Jakość wynika z użytego procesu (użytych procesów).
Środowisko testowe składające się z zaślepek i sterowników potrzebnych do wykonania testu.
Statystyczne narzędzie zarządzania procesem, używane do monitorowania procesu i określania, czy jest on statystycznie kontrolowany. Pokazuje graficznie wartość średnią oraz górną i dolną granicę kontrolną procesu (najwyższe i najniższe dopuszczalne wartości).
Dokument opisujący cel lub zadania dla sesji testów.
Dokument opisujący cel lub zadania dla sesji testów.
Statystyczne narzędzie zarządzania procesem, używane do monitorowania procesu i określania, czy jest on statystycznie kontrolowany. Pokazuje graficznie wartość średnią oraz górną i dolną granicę kontrolną procesu (najwyższe i najniższe dopuszczalne wartości).
Zbiór ryzyk pogrupowanych według jednej lub kilku kategorii.
Osoba odpowiedzialna za zarządzanie działaniami testowymi, zasobami i oceną przedmiotu testów.
Osoba odpowiedzialna za planowanie i nadzór nad wytworzeniem i rozwojem rozwiązań dla testów automatycznych.
Pokrycie klas równoważności.
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.
Transformacja zmiennej znakowej o zmiennej długości do na ogół krótszej, o stałej długości lub na klucz. Zhaszowane wartości, hasze, są często używane przy sprawdzeniu w tabeli lub bazie danych. Kryptograficzne funkcje haszujące są używane do zabezpieczania danych.
Zespół interesariuszy reprezentujących różne specjalności, który zarządza zgłaszanymi defektami od momentu zgłoszenia do końcowego rozwiązania (usunięcia defektu, odroczenia lub anulowania zgłoszenia). W niektórych przypadkach to także rada kontroli zmian.
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.
Stopień, w jakim strona lub aplikacja internetowa może działać pod różnymi wersjami przeglądarek i łagodnie obniżać jakość swego działania, gdy przeglądarka nie posiada odpowiednich cech lub posiada je w niewystarczającym stopniu.
Podejście do testów, w którym zestaw testowy obejmuje wszystkie kombinacje wartości wejściowych i warunków wstępnych.
stopień, w jakim zestaw funkcji obejmuje wszystkie określone zadania i cele użytkownika.
Oparte o wykorzystanie komputerów procesy, techniki i narzędzia wspomagające testowanie. (CAST od ang. Computer Aided Software Testing)
Przypadek testowy z konkretnymi warunkami wstępnymi, wartościami wejściowymi, wynikami oczekiwanymi, warunkami wyjściowymi i odpowiednimi akcjami (o ile ma to zastosowanie).
Strategia testowa, zgodnie z którą zespół testowy polega na danych dostarczanych przez jednego lub kilku kluczowych interesariuszy przy określaniu szczegółów strategii.
Zespół interesariuszy reprezentujących różne specjalności, który zarządza zgłaszanymi defektami od momentu zgłoszenia do końcowego rozwiązania (usunięcia defektu, odroczenia lub anulowania zgłoszenia). W niektórych przypadkach to także rada kontroli zmian.
Użytkownicy, zadania, wyposażenie (sprzęt, oprogramowanie i materiały) oraz fizyczne i społeczne środowiska, w których oprogramowanie jest używane.
zestaw działań mających na celu ocenę jakości modułu lub systemu.
Uczestnik przeglądu, który identyfikuje problemy w produkcie pracy.
Przedstawienie – przy pomocy tablicy rozdzielczej – statusu organizacji i kondycji przedsiębiorstwa.
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.
Kryteria używane do kierowania tworzeniem przypadków testowych lub wyboru przypadków testowych mające na celu ograniczenie wielkości testów.
Zbiór warunków definiujących kiedy można oficjalnie uznać określone zadanie za ukończone.
Reguły decyzyjne wykorzystywane do określenia czy element testowy zaliczył test.
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.
Model usprawniania procesu testowego oparty na zawartości, zbudowany w oparciu o dwanaście procesów krytycznych. Zawierają one bardzo widoczne procesy, przy pomocy których pracownicy i kierownictwo oceniają kompetencje, oraz najważniejsze procesy, których wydajność wpływa na zysk i reputację organizacji. (CTP - od ang. Critical Testing Processes)
Element niezbędny w organizacji lub projekcie do wypełnienia jej/jego misji. Krytyczne czynniki sukcesu to te czynniki lub aktywności, które są niezbędne do zapewnienia powodzenia.
Model klasyfikacji typów/poziomów testów według czterech grup odniesionych do dwóch wymiarów celów testowania: wspieranie zespołu vs. krytyka produktu oraz cel technologiczny vs. cel biznesowy.
Fizyczne miejsce, w którym przeprowadza się bezinwazyjne obserwacje reakcji uczestników oraz ich odpowiedzi na działanie oprogramowania.
Maksymalna liczba liniowo niezależnych ścieżek w programie.
(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.
Chronologiczny zapis szczegółów związanych z wykonaniem testów.
Przypadek testowy z abstrakcyjnymi warunkami wstępnymi, danymi wejściowych, warunkami wyjściowymi, oczekiwanymi rezultatami i odpowiednimi akcjami (o ile ma to zastosowanie).
Czynność tworzenia dziennika (logu) testowego.
Dwuwymiarowa tabela, która koreluje dwa pojęcia (np. wymagania i przypadki testowe). Macierz ta umożliwia śledzenie w tył i w przód połączenia między elementami, tym samym umożliwiając określenie pokrycia oraz szacowanie wpływu proponowanych zmian.
Określenie zasad, które leżą u podstaw zwinnego wytwarzania oprogramowania. Te zasady to: ludzie i współpraca ponad procesy i narzędzia, działające oprogramowanie ponad obszerną dokumentację, współpraca z klientem ponad formalne ustalenia, reagowanie na zmiany ponad podążaniem za planem.
Deklaracja naśladująca manifest zwinnego wytwarzania oprogramowania określająca wartości ważne dla poprawy procesu testowego. Są to: elastyczność ponad szczegółowe procesy, ukierunkowanie na praktykę ponad ukierunkowanie na procesy, przeglądy koleżeńskie zamiast (departamentów) zarządzania jakością, ukierunkowanie na biznes ponad ukierunkowanie się na model.
Macierz przedstawiająca udział różnych ról w wykonywaniu zadań lub produktów w projekcie lub procesie. Jest ona szczególnie użyteczna w wyjaśnianiu ról i odpowiedzialności. RACI jest akronimem wyprowadzonym z czterech kluczowych najczęściej używanych odpowiedzialności: Odpowiedzialny (ang. Responsible), Rozliczany (ang. Accountable), Konsultowany (ang. Consulted) i Informowany (ang. Informed).
Testowanie w oparciu o modele, zgodnie z którym przypadki testowe są generowane i od razu wykonywane.
Czarnoskrzynkowa technika, w której przypadki testowe projektowane są za pomocą drzewa klasyfikacji.
Metoda, według której cele są definiowane bardzo konkretnie, a nie ogólnie. SMART jest akronimem wyprowadzonym z atrybutów celu, które należy zdefiniować: Specific (konkretny), Measurable (mierzalny), Attainable (osiągalny), Relevant (trafny), Timely (terminowy).
strategia testowa, zgodnie z którą zespół testowy używa predefiniowanego zbioru warunków testowych, takich jak standard jakości, lista wyboru lub zbiór uogólnionych, logicznych przypadków testowych które mogą być powiązane z jakąś dziedziną, aplikacją lub typem testów.
Skala pomiaru i sposób jej stosowania do pomiarów.
Pokrycie sekwencji N+1-przejść.
Liczba bądź kategoria przypisana do atrybutu/cechy obiektu poprzez wykonanie pomiaru.
Miara, która pokazuje postęp w kierunku zdefiniowanego kryterium, np. zbieżność całkowitej liczby wykonanych testów do całkowitej liczby zaplanowanych testów.
Cel testowania w organizacji, często dokumentowany jako część polityki 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).
Ustrukturalizowany zbiór elementów opisujący pewne aspekty dojrzałości organizacji, stanowiący również pomoc w definiowaniu i rozumieniu procesów w organizacji.
Nienormatywny model zarządzania jakością w organizacji, zdefiniowany i utrzymywany przez Europejską Fundację Zarządzania Jakością, oparty o pięć kryteriów „otwierających możliwości” (pokrywających to, co organizacja robi) i cztery kryteria „wynikowe” (pokrywających to, co organizacja osiąga).
dowolny model używany w testowaniu opartym na modelu.
Model procesu zawierający szczegółowy opis dobrych praktyk inżynierskich, np. praktyk stosowanych w testowaniu.
Struktura, w której procesy tego samego rodzaju są sklasyfikowane w ogólnym modelu.
Model opisujący testalia używane do testowania testowanego modułu lub systemu.
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.
: Testy dynamiczne przy użyciu modelu symulacyjnego systemu wykonywane w symulowanym środowisku.(MiL od ang. model in the loop).
Model pokazujący poprawę niezawodności modułu lub systemu w czasie jako wynik usuwania defektów.
abstrakcja rzeczywistego środowiska modułu lub systemu, w tym innych modułów, procesów i warunków środowiska, wykorzystywana do symulacji w czasie rzeczywistym.
Pokrycie elementów modelu.
(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.
Stopień, w jakim moduł lub system można zmienić bez wprowadzania defektów lub obniżania jakości istniejącego produktu.
Aktywność polegająca na sprawdzaniu status aktywności testowych, identyfikowaniu odchylenia od planu lub oczekiwanego statusu oraz raportowaniu statusu do interesariuszy.
Model odniesienia procesu i powiązany model oceny procesu w przemyśle motoryzacyjnym, który jest zgodny z wymaganiami normy ISO/IEC 33002: 2015.
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.
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.
Narzędzie wykonujące analizę statyczną.
Narzędzie używane przez programistów do odtwarzania awarii, śledzenia stanu programu i odszukiwania usterek. Debugery umożliwiają programistom wykonywanie programów krok po kroku, zatrzymywanie wykonania programu na dowolnej instrukcji oraz sprawdzanie i ustawianie wartości zmiennych.
Narzędzie do posiewu (tzn. celowego dodawania) usterek w module lub systemie.
Narzędzie do posiewu (tzn. celowego dodawania) usterek w module lub systemie.
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 używane do sprawdzania, czy na stronie internetowej są wadliwie (działające nieprawidłowo) hiperłącza.
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ędzia ułatwiające rejestrację incydentów i śledzenie ich statusów.
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.
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.
Podejście do automatyzacji testów, w którym wejścia do przedmiotu testów są nagrywane podczas testów manualnych w celu wygenerowania automatycznych skryptów, które mogą być uruchomione później.
Narzędzie programistyczne, które jest dostępne dla wszystkich potencjalnych użytkowników w postaci kodu źródłowego, zwykle poprzez Internet, na ogół w postaci licencji na badanie, zmienianie, poprawianie i czasami dystrybuowanie oprogramowania.
Podejście do automatyzacji testów, w którym wejścia do przedmiotu testów są nagrywane podczas testów manualnych w celu wygenerowania automatycznych skryptów, które mogą być uruchomione później.
Oprogramowanie lub sprzęt, który obsługuje jedno lub więcej działań testowych.
Niezamierzone przerwanie wykonania modułu lub systemu przed zakończeniem.
organizacja odpowiedzialna za testowanie i certyfikowanie oprogramowania, sprzętu, oprogramowania wbudowanego, platform i systemów operacyjnych zgodnie z przepisami prawa dla miejsca, w którym produkt będzie używany.
Rozdzielenie odpowiedzialności, które sprzyja zapewnieniu obiektywności testowania.
Status wyniku testu, w którym rzeczywisty wynik nie zgadza się z wynikiem oczekiwanym.
Niezamierzone przerwanie wykonania modułu lub systemu przed zakończeniem.
Stopień w jakim można udowodnić podjęcie działań lub zajście zdarzeń tak, by nie można było zaprzeczyć ich wystąpieniu.
Stopień, w jakim w przypadku przerwy w pracy lub awarii moduł lub system może odzyskać dane bezpośrednio dotknięte tym problemem i przywrócić pożądany stan systemu.
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).
Typ oceny zaprojektowany i używany do poprawy jakości modułu lub systemu, zwłaszcza kiedy jest jeszcze ciągle w fazie projektowania.
Ocena produktu pracy wykorzystująca heurystyki.
Typ oceny zaprojektowanej i używanej do gromadzenia wniosków o jakości modułu lub systemu, głownie wtedy, gdy projekt podstawowej jego części jest gotowy.
Uporządkowana ocena procesów wytwarzania oprogramowania w organizacji w stosunku do modelu wzorcowego.
Proces oceny zidentyfikowanego ryzyka i oceny poziomu ryzyka.
Proces, podczas którego gromadzone są informacje dotyczące użyteczności, mający na celu poprawianie systemu (co jest znane jako ocena formatywna) lub do oszacowania zalet lub wartości (co jest znane jako ocena podsumowująca).
Osoba przeprowadzająca ocenę. Dowolny członek zespołu oceniającego.
stopień, w jakim moduł lub system chroni użytkowników przed popełnianiem błędów.
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.
Każde zdarzenie wymagające zbadania.
Badanie docelowych obszarów mające na celu zbieranie informacji, które mogą być użyte do ataku.
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.
Liczba defektów wykrytych na poziomie testowania podzielona przez liczbę defektów wykrytych w całym cyklu życia oprogramowania (na poziomie testów i później).
Liczba defektów wykrytych na poziomie testowania podzielona przez liczbę defektów wykrytych w całym cyklu życia oprogramowania (na poziomie testów i później).
Stopień, w jakim w przypadku przerwy w pracy lub awarii moduł lub system może odzyskać dane bezpośrednio dotknięte tym problemem i przywrócić pożądany stan systemu.
Testowanie w oparciu o modele, zgodnie z którym przypadki testowe są generowane do repozytorium w celu późniejszego użycia.
Reprezentacja warstw, modułów i interfejsów architektury testów automatycznych, umożliwiająca strukturalne i modułowe podejście do implementacji testów automatycznych.
Proces definiowania i implementacji profilu produkcyjnego.
Testowanie w oparciu o modele, zgodnie z którym przypadki testowe są generowane i od razu wykonywane.
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).
Testy dynamiczne wykonywane przy użyciu prawdziwego oprogramowania w symulowanym środowisku lub na eksperymentalnym sprzęcie.
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.
Połączenie definicji zmiennej i jej późniejszego użycia.
Atak na zabezpieczenia mający na celu przekierować ruch ze strony internetowej na fałszywą stronę internetową bez wiedzy lub zgody użytkownika.
Usiłowanie zdobycia osobistej lub istotnej informacji poprzez podawanie się za wiarygodny podmiot w komunikacji elektronicznej.
Proces modyfikacji modułu lub systemu po jego wydaniu, mający na celu poprawę defektów, charakterystyk jakościowych lub dostosowanie do zmienionego środowiska.
Graficzny model reprezentujący relacje między ilością testów a poziomem testów, z większą ilością testów dla niższych poziomów i mniejszą dla wyższych.
Plan osiągnięcia celów doskonalenia procesu testowego oparty na zrozumieniu aktualnych mocnych i słabych stron procesów testowych w organizacji i aktywów procesu testowego.
Dokument opisujący podejście, zasoby i harmonogram zamierzonych czynności związanych z przeglądem. Identyfikuje on m.in. dokumenty i kod podlegający przeglądowi, typy przeglądów do wykorzystania, uczestników, kryteria wejścia i wyjścia, które będą stosowane w przeglądach formalnych, a także uzasadnienie ich wyboru. Jest zapisem procesu planowania przeglądu.
Dokumentacja opisująca cele testowe do osiągnięcia oraz środki i harmonogram ich realizacji, zorganizowana tak, by koordynować czynności testowe.
Plan testu, który odnosi się do jednego poziomu testowania.
Czynność tworzenia planów testów lub wprowadzanie do nich zmian
Niedoskonałość lub wada produktu pracy, polegająca na niespełnieniu wymagań.
Stopień, w jakim moduł lub system można zmienić bez wprowadzania defektów lub obniżania jakości istniejącego produktu.
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.
Stopień, w jakim można dokonać oceny modułu lub systemu pod kątem wpływu jednej lub więcej zamierzonych zmian, diagnozy braków lub przyczyn awarii lub identyfikacji elementów (części) do zmodyfikowania.
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.
Pokrycie wszystkich możliwych kombinacji wszystkich wyników pojedynczych warunków w ramach jednej instrukcji.
Pokrycie wszystkich możliwych kombinacji wszystkich wyników pojedynczych warunków w ramach jednej instrukcji.
Pokrycie sekwencji N+1-przejść.
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.
Pokrycie wyników warunków.
Pokrycie wyników warunków.
Pokrycie wszystkich pojedynczych wyników warunków, których zmiana wpływa niezależnie na wynik decyzji. (MC/DC od ang. modified condition/decision coverage).
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.
Wysokopoziomowy dokument opisujący zasady, podejście i podstawowe cele w organizacji dotyczące zabezpieczeń.
Podejście do testowania, w którym motywatorami są grywalizacja i nagrody za wykryte defekty.
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.
Stopień, w jakim moduł lub system zapewnia prawidłowe wyniki z wymaganą precyzją.
Proces celowego dodawania defektów do już istniejących w module lub systemie w celu monitorowania efektywności ich wykrywania i usuwania oraz szacowania liczby defektów niewykrytych.
Proces celowego dodawania defektów do już istniejących w module lub systemie w celu monitorowania efektywności ich wykrywania i usuwania oraz szacowania liczby defektów niewykrytych.
Stopień, w jakim moduł lub system zapewnia dostęp do danych tylko tym osobom, które mają do tego uprawnienia.
Odsetek defektów, które zostały usunięte w tej samej fazie cyklu życia oprogramowania, w której zostały wprowadzone.
Stopień w procesie doskonalenia względem wcześniej zdefiniowanego zbioru obszarów procesowych, dla których mają być spełnione wszystkie cele w zbiorze.
Jeden z czterech poziomów określających niezbędne wymagania obiektu lub elementu ISO 26262 oraz środki bezpieczeństwa w celu uniknięcia nieuzasadnionego ryzyka rezydualnego. (ASIL od ang. automotive safety integrity level).
Jakościowa lub ilościowa miara ryzyka zdefiniowana przez wpływ i prawdopodobieństwo.
Specyficzna instancja procesu testowego.
Poziom, do którego przedmiot testów jest modyfikowany poprzez dostosowanie go celem uzyskania testowalności.
Zapasowy tryb operacyjny, w którym funkcje systemu, gdy stają się one niedostępne, są przejmowane przez system pomocniczy.
Prawdopodobieństwo, że ryzyko wystąpi jako rzeczywisty wynik lub zdarzenie.
Prawdopodobieństwo, że ryzyko wystąpi jako rzeczywisty wynik lub zdarzenie.
Poziom (biznesowej) ważności określony dla elementu, np. defektu.
Systematyczne podejście do testowania opartego na ryzyku, które wykorzystuje identyfikację i analizę ryzyka produktowego do stworzenia macierzy ryzyka produktowego, w której rozważa się prawdopodobieństwo i wpływ. Nazwa pochodzi od ang. Product RISk MAnagement.
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 kroków potrzebnych do zaimplementowania polityki zabezpieczeń oraz kroków, które powinny być podjęte w przypadku incydentu z zabezpieczeniami.
Ustrukturalizowana metodyka testowania, wykorzystywana również jako model doskonalenia procesu testowania oparty o zawartość. Nie wymaga ona, by poprawę przeprowadzać w zadanym porządku. (STEP od ang. Systematic Test and Evaluation Process)
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ć.
Dokumentacja definiująca określoną liczbę wirtualnych użytkowników, którzy przetwarzają określony zestaw transakcji w zadanym przedziale czasowym, którego testowany moduł lub system może doświadczyć podczas produkcji.
Rzeczywisty lub przewidywany wzór użycia modułu lub systemu.
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.
Podejście do projektowania, ukierunkowane na uczynienie oprogramowania bardziej użytecznym poprzez ukierunkowanie na jego użycie i zastosowanie czynnika ludzkiego, ergonomii oraz wiedzy i technik z zakresu użyteczności
Osoba zapisująca informacje podczas spotkań przeglądowych.
Zabezpieczenie informacji umożliwiających identyfikację osoby lub innych danych wrażliwych przed niepowołanym ujawnieniem.
Wykonanie zestawu testów na określonej wersji przedmiotu testów.
Atrybut lub kombinacja atrybutów uzyskana z jednego lub więcej warunków testowych za pomocą techniki testowej.
Moduł lub system podlegający testowaniu.
W zarządzaniu ryzykiem projektowym - okres czasu, podczas którego musi zostać podjęte działanie, by skutecznie zredukować wpływ ryzyka.
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.
Systematyczna ocena procesu zakupu, dostawy, wytworzenia, działania lub utrzymania oprogramowania wykonywana przez albo w imieniu kierownictwa, obejmująca monitorowanie postępów, określanie statusu planów i harmonogramów, zatwierdzanie wymagań oraz ich alokacji, ocenę skuteczności metod zarządzania mających na celu osiągnięcie zakładanych celów/funkcjonalności.
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.
Stopień, w jakim maksymalne wartości graniczne parametru modułu lub systemu spełniają wymagania.
ilość danych przetwarzanych przez moduł lub system w określonym przedziale czasu.
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.
Działanie polegające na wybieraniu danych z istniejących baz danych lub tworzeniu, generowaniu, przetwarzaniu i edycji danych do testowania.
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).
Przypadek użycia, w którym pewni aktorzy mający intencję szkodzenia powodują uszkodzenia w systemie lub przeszkadzają innym aktorom.
Typ cyklu życia oprogramowania, w którym moduł lub system wytwarzany jest w serii cyklów.
technika zwiększania obciążenia systemu w mierzalny i kontrolowany sposób.
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.
Dokument podsumowujący wyniki oceny, np. wnioski, zalecenia oraz ustalenia.
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.
Strategia testowa, zgodnie z którą zespół testowy czeka z projektowaniem i implementacją testów aż oprogramowanie zostanie dostarczone, reagując na aktualne testowane oprogramowanie.
Podejście do testów automatycznych polegające na tym, że wejścia do przedmiotu testów są rejestrowane podczas ręcznego testowania w celu stworzenia zautomatyzowanego skryptu testowego, który będzie wykonywany później.
Osoba zapisująca informacje podczas spotkań przeglądowych.
Badanie docelowych obszarów mające na celu zbieranie informacji, które mogą być użyte do ataku.
Struktura modelu dojrzałości organizacyjnej, w której poziomy dojrzałości określają jedynie zalecaną kolejność usprawnień procesów w określonym obszarze procesowym.
Struktura modelu, w którym osiągnięcie celów zbioru obszarów procesowych określa poziom dojrzałości, każdy poziom stanowi podstawę dla następnych poziomów.
Rodzaj testu związanego ze zmianą przeprowadzonego po naprawieniu defektu w celu potwierdzenia, że awaria spowodowana przez ten defekt już nie występuje.
Ustrukturalizowane podejście do zapoznania się z wyciągniętymi wnioskami i stworzenia konkretnych planów działań mających na celu poprawę następnego projektu lub następnego etapu projektu.
Konsekwencja/wynik wykonania testu.
Test, w którym nie zidentyfikowano obecności usterki występującej w testowanym obiekcie.
Test, w którym zaraportowano defekt, który nie występuje.
Test, w którym zaraportowano defekt, który nie występuje.
Test, w którym nie zidentyfikowano obecności usterki występującej w testowanym obiekcie.
Konsekwencja/wynik wykonania testu.
Stopień w jakim działania danej jednostki można jednoznacznie przypisać do tej jednostki.
Faza w modelu IDEAL, podczas której wypracowywana jest podstawa do zapewnienia sukcesu procesu doskonalenia. Faza rozpoczęcia składa się z następujących czynności: określenie kontekstu, zdobycie sponsorów, i nakreślenie infrastruktury.
Realizacja/implementacja architektury dla testów automatycznych, tzn. kombinacji modułów implementujących misję określonych testów automatycznych. Moduły mogą zawierać komercyjne, kupione narzędzia testowe, strukturę do testów automatycznych, jak i sprzęt testowy.
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.
ryzyko jakości związane z zabezpieczeniami.
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.
Nakład pracy potrzebny do wykonania testów manualnie.
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.
Sesja testów w testach użyteczności, podczas której ich uczestnik wykonuje testy, prowadzona przez moderatora i obserwowana przez pewną liczbę obserwatorów.
Prosta, dziesięciostopniowa skala opisująca subiektywną ocenę użyteczności. (SUS od ang. System Usability Scale),
Stopień w jakim moduł lub system może być dostosowany do zmieniającego się obciążenia.
Statyczny analizator używany do wykrywania bezbronności bezpieczeństwa w kodzie.
Analiza statyczna mająca na celu wykrycie i usuniecie złośliwego kodu otrzymanego przez interfejs.
Osoba zapisująca informacje podczas spotkań przeglądowych.
Dokument specyfikujący sekwencję czynności potrzebnych do wykonania testu użyteczności. Używany przez moderatora do utrzymania toku odprawy i pytań przed-sesyjnej ankiety, zadań testów użyteczności oraz pytań posesyjnej ankiety.
Ciąg instrukcji wykonujący zestaw testowy.
Osoba wykonująca ataki na zabezpieczenia stworzone przez innych hakerów zamiast swoich własnych.
Prosta technika skryptowa bez żadnych struktur sterujących w skrypcie testowym.
Zakres, w jakim osiągane są poprawne i pełne cele.
Stopień, w jakim ilości i rodzaje zasobów używanych przez produkt lub system spełniają wymagania podczas wykonywania jego funkcji.
Technika kryptograficzna, w której dodaje się dane losowe (tzw. sól) do danych użytkownika przed haszowaniem.
Technika rozwoju oprogramowania, w której specyfikacja jest definiowana poprzez przykłady.
Dokumentacja określająca testowane cechy i odpowiadające im warunki testowe.
Dokumentacja zestawu jednego lub więcej przypadków testowych.
Kompletna dokumentacja projektu testów, przypadków testowych i skryptów testowych dla określonego elementu testowego.
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.
technika zmniejszania obciążenia systemu w mierzalny i kontrolowany sposób.
Środowisko, w skład którego wchodzi sprzęt, wyposażenie, symulatory, narzędzia programistyczne oraz inne elementy wspierające, potrzebne do wykonania testu.
testy dynamiczne przeprowadzone przy użyciu prawdziwego sprzętu ze zintegrowanym oprogramowaniem w symulowanym środowisku. (HiL od ang.hardware in the loop ).
Rodzaj wstrzyknięcia kodu w zapytanie języka SQL.
Fizyczny lub funkcjonalny przejaw awarii.
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.
Stopień, w jakim użytkownicy mogą rozpoznać, czy moduł lub system jest odpowiedni do ich potrzeb.
Stopień, w jakim funkcje ułatwiają realizację określonych zadań i celów.
Strategia testowa, zgodnie z którą zespół testowy stosuje różne techniki do zarządzania ryzykiem regresji, takie jak funkcjonalne i niefunkcjonalne automatyczne testy regresji na jednym lub kilku poziomach.
Strategia testowa, zgodnie z którą zespół testowy wywodzi testalia z modeli.
Strategia testowa, zgodnie z którą zespół testowy postępuje zgodnie ze zbiorem pre-definiowanych procesów, przy pomocy których adresuje takie kwestie jak: dokumentacja, właściwa identyfikacja i użycie podstawy testów oraz wyroczni testowej (testowych), organizacja zespołu testowego.
Strategia testowa, zgodnie z którą zespół testowy postępuje zgodnie ze standardem. Wykorzystywane standardy mogą być ważne np. w kraju (standardy legislacyjne), w dziedzinie biznesowej (standardy dziedzinowe) lub być międzynarodowe (standardy organizacyjne).
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.
Wysokopoziomowy plan osiągnięcia długoterminowych celów przez testy automatyczne przy zadanych ograniczeniach.
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.
Podsieć ze zdefiniowanym poziomem zaufania. Na przykład Internet lub strefy publiczne powinny być rozważane jako pozbawione zaufania.
Fizyczna lub logiczna podsieć, która zawiera i udostępnia zewnętrzne serwisy organizacji dla niezaufanej sieci, na ogół dla Internetu. (DMZ od ang. Demilitarized Zone)
Narzędzie dostarczające środowisko do testów automatycznych. Na ogół zawiera jarzmo testowe i biblioteki testowe.
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.
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).
Złożone, heterogeniczne, rozproszone systemy, które mogą być zagnieżdżone w sieciach na wielu poziomach i w wielu połączonych dziedzinach, ukierunkowane na rozwiązywanie interdyscyplinarnych problemów i zamierzeń o wielkiej skali, na ogół bez wspólnej struktury zarządczej.
System, który monitoruje działalność na wszystkich 7 warstwach modelu OSI od poziomu sieci do poziomu aplikacji, by wykrywać naruszenia w polityce bezpieczeństwa. (IDS od ang. Intrusion Detection System).
System, w którym działanie sterujące lub wejście jest niezależne od wyjścia lub zmian w wyjściu.
System, w którym działanie sterujące lub wejście zależą od wyniku lub zmian w wyniku.
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.
Maksymalna wydajność operacyjna modułu lub systemu.
Bazująca na wiedzy eksperckiej technika estymacji opierająca się na zbiorowej wiedzy członków zespołu polegająca na dokładnym szacowaniu.
Proces kodowania informacji w ten sposób, by tylko upoważnione strony mogły pobierać oryginalną informację, na ogół przy użyciu określonego klucza dekodującego lub specjalnego procesu.
Tabela zawierająca różne podejścia testowe, techniki testowania i typy testów, które są wymagane w zależności od poziomu nienaruszalności bezpieczeństwa samochodowego (ASIL od ang. Automotive Safety Integrity Level) i kontekstu przedmiotu testów.
Przedstawienie dynamicznych miar wydajności operacyjnej pewnej organizacji lub pewnego działania, przy użyciu metaforycznych metryk, takich jak wizualne zegary, liczniki i inne wskaźniki podobne do tych na desce rozdzielczej samochodu, tak żeby skutki zdarzeń i działań były zrozumiałe i mogły być w prosty sposób powiązane z celami operacyjnymi.
Lista kategorii zaprojektowana w celu identyfikacji i klasyfikacji defektów.
Lista kategorii zaprojektowana w celu identyfikacji i klasyfikacji defektów.
Czarnoskrzynkowa technika, w której przypadki testowe projektowane są za pomocą drzewa klasyfikacji.
Technika testowa, w której przypadki testowe projektuje się na podstawie wiedzy o określonym typie defektów.
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 testowa, w której przypadki testowe projektuje się na podstawie wiedzy o określonym typie defektów.
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.
Technika testowa, w której przypadki testowe projektuje się na podstawie wiedzy o określonym typie defektów.
Zestaw jednego lub więcej przypadków testowych.
Zestaw testów obejmujący główną funkcjonalność modułu lub systemu sprawdzający, czy działa ona poprawnie przed rozpoczęciem planowanych testów.
Zestaw testów obejmujący główną funkcjonalność modułu lub systemu sprawdzający, czy działa ona poprawnie przed rozpoczęciem planowanych testów.
Testy przeprowadzone na kompletnym, zintegrowanym oprogramowaniu w celu potwierdzenia zgodności z wymaganiami na oprogramowanie.
Testowanie przeprowadzane na kompletnym, zintegrowanym systemie złożonym z komponentów oprogramowania, sprzętu oraz mechaniki mające na celu dostarczenia dowodu na zgodność z wymaganiami systemowymi oraz gotowości całego systemu do wdrożenia.
Wskaźnik preferencji psychologicznych reprezentujący różne typy osobowości i style komunikacji. (MBTI od ang. Myers-Briggs Type Indicator).
Zestaw testów obejmujący główną funkcjonalność modułu lub systemu sprawdzający, czy działa ona poprawnie przed rozpoczęciem planowanych testów.
Zbiór automatycznych testów, które walidują (sprawdzają) integralność każdej nowej wersji i weryfikują jej kluczową/podstawową funkcjonalność, stabilność i testowalność. (BVT od ang. build verification test).
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.
Testowanie przeprowadzane przez wprowadzanie poleceń do testowanego oprogramowania poprzez bezpośrednie wykorzystanie interfejsu tej aplikacji.
Testowanie w celu określenia, czy muzyka i efekty dźwiękowe w grze komputerowej będą odpowiednio angażować użytkownika w tę grę.
Testowanie w celu porównania dwóch lub więcej wariantów elementu testowego lub modelu symulacyjnego tego samego elementu testowego poprzez wykonanie tych samych przypadków testowych na wszystkich wariantach i porównanie wyników.
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.
Testowanie przeprowadzane przez wprowadzanie poleceń do testowanego oprogramowania z wykorzystaniem dedykowanego interfejsu linii komend. (CLI od ang. Command-Line Interface)
Białoskrzynkowa technika testowania, w której przypadki testowe są projektowane tak, by sprawdzać wyniki decyzji.
Testowanie mające zapewnić dopasowanie oprogramowania do potrzeb.
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.
Rodzaj testowania, w którym procesy biznesowe są testowane od początku do końca w warunkach zbliżonych do produkcyjnych.
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.
Testowanie wykonywane przez współdziałanie z testowanym oprogramowaniem poprzez graficzny interfejs użytkownika. (od ang. GUI Graphical User Interface)
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.
Forma testowania integracyjnego, która testuje pary współpracujących ze sobą modułów według ich rozmieszczenia w grafie wywołań.
Poziom testów koncentrujący się na interakcjach między modułami lub systemami.
Typ testowania integracyjnego, w którym wszystkie węzły połączone z danym węzłem stanowią podstawę do testowania integracyjnego.
Testowanie wykonywane w celu wykrycia defektów w interfejsach i interakcjach pomiędzy modułami lub systemami.
Typ testów integracyjnych wykonywanych w celu sprawdzenia poprawności przekazywania danych i sterowania pomiędzy modułami lub systemami.
Poziom testów, który koncentruje się na poszczególnych modułach sprzętowych lub programowych.
Białoskrzynkowa technika testowania, w której przypadki testowe są projektowane tak, aby wykonać kombinacje wyników warunków atomowych.
Białoskrzynkowa technika testowania, w której przypadki testowe są projektowane tak, aby wykonać kombinacje wyników warunków atomowych.
Czarnoskrzynkowa technika testowania, w której przypadki testowe są projektowane tak, by wykonywać określoną kombinację wartości wielu parametrów.
Rodzaj testowania, w którym procesy biznesowe są testowane od początku do końca w warunkach zbliżonych do produkcyjnych.
Poziom testów, który koncentruje się na poszczególnych modułach sprzętowych lub programowych.
Czarnoskrzynkowa technika projektowania przypadków testowych, w której przypadki testowe są dobierane przy pomocy algorytmu generującego wartości pseudolosowe tak, aby były zgodne z profilem operacyjnym.
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 komponentu lub systemu niezgodnie z jego przeznaczeniem.
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.
Technika testowania oprogramowania używana do wykrywania zagrożeń zabezpieczeń przez wprowadzanie bardzo dużej liczby losowych danych, zwanych "fuzz" (ang. farfocle), do modułu lub systemu.
Rodzaj testów, w których klient testowy jest używany do zmiany identyfikatora agenta-użytkownika (ang. user-agent string) i przedstawia się jako inny klient podczas wykonywania zestawów testowych.
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.
Typ testowania, w którym zestawy testowe wykonywane są na fizycznych lub wirtualnych urządzeniach.
Podejście do testów, w którym przypadki testowe są projektowane w oparciu o wymagania.
Technika testowania mająca na celu odkrycie słabych punktów zabezpieczeń (znanych lub nie), by uzyskać nieautoryzowany dostęp.
Testowanie zmian we wdrożonym systemie lub testowanie wpływu zmienionego środowiska na wdrożony system.
Typ testów wykonywanych w celu upewnienia się, że wydanie zostało przeprowadzone poprawnie i aplikacja może być wdrożona.
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.
Typ testowania wydajnościowego wykonywany, by określić jak system lub jego moduł pracuje na przewidywanej lub wyspecyfikowanej granicy obciążenia lub poza nią lub też przy ograniczonym dostępie do pamięci lub serwerów.
Czarnoskrzynkowa technika testowania, w której przypadki testowe są zaprojektowane tak, by wykonywać elementy modelu przejścia stanów.
Testowanie mające na celu ocenę przepustowości systemu.
Białoskrzynkowa technika testowania, w której przypadki testowe są projektowane tak, aby wykonywać ścieżki definicja-użycie dla poszczególnych zmiennych.
Białoskrzynkowa technika testowania, w której przypadki testowe są projektowane w oparciu o przepływy sterowania.
Testowanie mające na celu określenia, czy wielu graczy może jednocześnie wchodzić w interakcję ze światem gry hazardowej, z komputerowo sterowanymi przeciwnikami, serwerami gry i ze sobą nawzajem, zgodnie z założeniami projektu gry.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Testowanie, które dynamicznie reaguje na zachowanie przedmiotu testów i na otrzymane wyniki testowania.
Rodzaj testowania związanego ze zmianami mającego na celu wykrycie, czy defekty zostały wprowadzone lub odkryte w niezmienionych obszarach oprogramowania.
Testowanie mające na celu określenie skalowalności oprogramowania.
Testowanie oceniające zdolność systemu do powrotu do stanu równowagi po nagłym skoku i spadku obciążenia.
Testowanie (ręczne lub automatyczne) wykonywane zgodnie ze skryptem testowym.
Czarnoskrzynkowa technika projektowania przypadków testowych, w której przypadki testowe są projektowane tak, by wykonać pary parametrów wejściowych.
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 określenia, czy gra zwraca poprawne matematycznie wyniki na ekran, na konto gracza oraz na konto kasyna.
Testowanie mające na celu określenie zgodności modułu albo systemu.
Testowanie mające na celu określenie zgodności modułu albo 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
Technika testowania użyteczności, podczas której uczestnicy testu dzielą się swoimi pomysłami z moderatorem i obserwatorami myśląc głośno podczas rozwiązywania zadań testów użyteczności. Głośne myślenie jest użyteczne do zrozumienia uczestników testów.
Testowanie w oparciu o doświadczenie, wiedzę i intuicję testera.
Czarnoskrzynkowa technika projektowania testów, w której przypadki testowe są projektowane w oparciu o historyjki użytkownika, by zweryfikować poprawność ich implementacji.
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 mające na celu określenie zgodności modułu albo systemu.
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, w którym dwie osoby równocześnie współpracują nad testowaniem produktu prac.
Podejście do testowania, w którym zadania testowe są planowane jako sesje testowe.
Podejście do testowania, w którym testowanie jest dystrybuowane do dużej grupy testerów.
Typ testów przeprowadzanych w celu oceny zachowania systemu w docelowym środowisku, w warunkach rzeczywistej interakcji.
Testowanie komponentu lub systemu niezgodnie z jego przeznaczeniem.
Białoskrzynkowa technika projektowania przypadków testowych polegająca na sprawdzaniu wyników warunków i wyników decyzji.
Białoskrzynkowa technika testowania w której przypadki testowe są zaprojektowane tak, sprawdzić pojedyncze wyniki warunków, których zmiana niezależnie wpływa na wynik decyzji.
Białoskrzynkowa technika testowania, w której przypadki testowe są projektowane tak, aby wykonać kombinacje wyników warunków atomowych.
Testowanie mające na celu ocenę poprawności zachowania modułu lub systemu wykorzystującego mechanizmy współbieżności.
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 określenie stabilności systemu podlegającego testowaniu w warunkach znacznego obciążenia w długim okresie czasu w kontekście eksploatacji systemu.
Testowanie przeprowadzane przez testerów przyjmujących role graczy, aby ocenić satysfakcję gracza z gry.
Testowanie mające na celu sprawdzenie zabezpieczeń oprogramowania.
Testy wykonywane przez osoby, które pracują w zespole projektowym, ale nie są zatrudnione w organizacji.
Testowanie mające na celu określenie zgodności modułu albo systemu.
Testowanie wykonywane przez osoby, które nie pracują w tej samej lokalizacji co zespół projektowy i nie są zatrudnione w organizacji.
Podejście do testowania stosowane w projektach korzystających z metodyk zwinnych, stosujące techniki i metody takie jak programowanie ekstremalne (XP), traktujące wytwarzanie jako "klienta testowania" i kładące nacisk na metodę „najpierw testuj”.
Typ testowania inicjowany przez modyfikację modułu lub systemu.
Białoskrzynkowa technika testowania, w której przypadki testowe są zaprojektowane tak, by wykonać ścieżki grafu przepływu sterowania.
Testowanie oceniające poprawność implementacji tablicy wypłat, wyników działania generatorów liczb losowych i teoretycznego procentu zwrotu z wygranej w grze.
Typ testów mających na celu potwierdzenie, że czujniki mogą wykryć bliskie obiekty bez fizycznego kontaktu.
Stopień, w jaki moduł lub system może kontynuować prawidłowe działanie pomimo podania błędnych danych wejściowych.
Stopień, w jakim moduł lub system działa zgodnie z przeznaczeniem, pomimo występowania awarii sprzętu lub oprogramowania.
Ciągła (nie etapowa) struktura doskonalenia procesu testowego z biznesowego punktu widzenia, opisująca kluczowe elementy efektywnego i skutecznego procesu testowego.
Czarnoskrzynkowa technika projektowania przypadków testowych, w której przypadki te są projektowane na podstawie grafów przyczynowo-skutkowych.
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.
Środki, które osłaniają i bronią informacje i systemy informacyjne poprzez zapewnienie ich dostępności, integralności, uwierzytelniania, poufności i niezaprzeczalności. Te środki obejmują warunkowe odtwarzanie systemów informacyjnych poprzez włączenie możliwości ochrony, wykrywania i reakcji.
Faza w modelu IDEAL, podczas której uczymy się na podstawie doświadczeń i doskonalimy nasze możliwości adaptowania nowych procesów i technologii w przyszłości. Faza uczenia się składa się z następujących czynności: analiza i ocena, oraz propozycja działań w przyszłości.
Reprezentatywny użytkownik rozwiązujący typowe zadania w testach użyteczności.
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.
Faza w modelu IDEAL, podczas której planuje się jak organizacja osiągnie swoje zamierzenia. Ta faza składa się z czynności ustalenia priorytetów, opracowania podejścia oraz planowania działań.
Niedoskonałość lub wada produktu pracy, polegająca na niespełnieniu wymagań.
Usterka nie wykryta przez czynność testową, która mogła tę usterkę znaleźć.
Proces stopniowego (krok za krokiem) redukowania zagrożeń zabezpieczeń systemu poprzez stosowanie polityki zabezpieczeń i różnych poziomów ochrony.
Stopień, w jakim moduł lub system może być modyfikowany przez wyznaczony personel.
Procedura określająca, czy osoba lub proces jest naprawdę tym, lub czym deklaruje, że jest.
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.
Warstwa w architekturze testów automatycznych, która dostarcza niezbędnego kodu do adaptowania skryptów testowych na odpowiednim poziomie abstrakcji do różnych komponentów, konfiguracji lub interfejsów testowanego oprogramowania.
Warstwa w ogólnej architekturze testów automatycznych wspomagająca implementację testów poprzez dostarczanie definicji zestawów testowych i/lub przypadków testowych, np. proponując wzorce lub wskazówki.
Warstwa w ogólnej architekturze testów automatycznych wspomagająca projektowanie manualnych lub automatycznych zestawów testów i/lub przypadków testowych.
Warstwa w ogólnej architekturze testów automatycznych wspomagająca wykonanie zestawów testowych i/lub przypadków testowych.
pokrycie wartości brzegowych.
Minimalna lub maksymalna wartość uporządkowanej klasy równoważności.
Wartość danej wejściowej.
Wyrażenie logiczne, którego wartością może być prawda albo fałsz.
Warunek nie zawierający operatorów logicznych.
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.
Pokrycie wszystkich możliwych kombinacji wszystkich wyników pojedynczych warunków w ramach jednej instrukcji.
Stopień wpływu defektu na rozwój lub działanie modułu lub systemu.
Uproszczona technika prowadzenia warsztatów, która pomaga określić krytyczne cechy rozwoju nowego produktu. (QFD od ang. Quality Function Deployment)
Dane otrzymane przez moduł lub system z zewnętrznego źródła.
Ścieżka lub środek, dzięki któremu atakujący może uzyskać dostęp do systemu w złośliwych celach.
Sprawdzenie poprawności i dostarczenie obiektywnego dowodu, że produkt procesu wytwarzania oprogramowania spełnia zdefiniowane wymagania.
Złożone, heterogeniczne, rozproszone systemy, które mogą być zagnieżdżone w sieciach na wielu poziomach i w wielu połączonych dziedzinach, ukierunkowane na rozwiązywanie interdyscyplinarnych problemów i zamierzeń o wielkiej skali, na ogół bez wspólnej struktury zarządczej.
Technika umożliwiająca wirtualne dostarczanie usług, które są zdalnie wdrażane, dostępne i zarządzane
Symulacja działań wykonywanych przez użytkownika określonego w profilu operacyjnym.
Proces celowego dodawania defektów do już istniejących w module lub systemie w celu monitorowania efektywności ich wykrywania i usuwania oraz szacowania liczby defektów niewykrytych.
Szkoda, jaka powstanie jeżeli ryzyko zmaterializuje się jako rzeczywisty skutek lub zdarzenie.
Szkoda, jaka powstanie jeżeli ryzyko zmaterializuje się jako rzeczywisty skutek lub zdarzenie.
Słabość w systemie, która może umożliwić udany atak na zabezpieczenia.
Cześć serii wskazówek dotyczących dostępu do strony internetowej publikowana przez Web Accessibility Initiative (WAI) z World Wide Web Consortium (W3C), głównej światowej organizacji standaryzującej Internet. Składa się ze zbioru wskazówek jak uczynić zawartość strony internetowej dostępną, głównie dla osób niepełnosprawnych. (WCAG od ang. Web Content Accesssibility Guidelines).
Niskopoziomowa, szczegółowa reguła lub rekomendacja do projektowania interfejsu użytkownika nie pozostawiająca miejsca na interpretację, więc projektant wdraża ją podobnie. Często używana do zapewnienia zgodności wyglądu i zachowania się interfejsu w systemach produkowanych w organizacji.
Dana, która określa lokalizację innej zmiennej.
Miara, która zapewnia oszacowanie lub ocenę określonych atrybutów uzyskanych z modelu w odniesieniu do zdefiniowanych potrzeb informacyjnych.
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.
Stopień, w jakim moduł lub system może wykonywać wymagane funkcje, dzieląc środowisko i zasoby z innymi modułami lub systemami bez negatywnego wpływu na żaden z nich.
Proces zamierzonego dodawania defektów do systemu w celu wykrycia, czy system może wykryć defekt i pracować mimo jego występowania. Wstrzykiwanie błędów stara się imitować błędy, które mogą wystąpić w produkcji.
Rodzaj ataku bezpieczeństwa polegający na wprowadzeniu do aplikacji poprzez jej interfejs złośliwego kodu, aby wykorzystać nieprawidłową obsługę niezaufanych danych.
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.
Technika skryptowa, w której skrypty są ustrukturalizowane w scenariusze reprezentujące przypadki użycia testowanego oprogramowania. Skrypty mogą być parametryzowane danymi testowymi.
Technika skryptowa, w której tworzy się i używa skrypty (lub ich część) z biblioteki skryptów wielokrotnego użycia.
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.
Wymaganie dotyczące użyteczności modułu lub systemu.
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.
Iteracyjny i przyrostowy proces rozwoju oprogramowania sterowany z perspektywy funkcjonalności (cech) wartościowych dla klienta. Najczęściej podejście to wykorzystywane jest w zwinnym wytwarzaniu oprogramowania.
Technika tworzenia oprogramowania, w której przypadki testowe są opracowywane, a często także automatyzowane, po czym oprogramowanie jest rozwijane stopniowo tak, aby te przypadki testowe były zaliczone. (TDD od ang. Test Driven Development)
Wspólne podejście do wytwarzania oprogramowania, w którym zespół i klienci używają języka dziedzinowego klienta aby zrozumieć jego wymagania, co tworzy podstawę do testowania modułu lub systemu. (ATDD – od ang. Acceptance Test-Driven Development).
Wspólne podejście do wytwarzania oprogramowania, w którym zespół skupia się na dostarczeniu klientowi oczekiwanego zachowania modułu lub systemu stanowiącego podstawę dla testowania. (BDD od ang. Behavior-Driven Development).
Model procesu zawierający szczegółowy opis dobrych praktyk inżynierskich, np. praktyk stosowanych w testowaniu.
Zbiór testów eksploracyjnych dotyczących określonego zagadnienia.
Narzędzie softwarowe wytworzone specjalnie dla grupy użytkowników lub klientów.
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.
Stopień, w jakim moduł lub system może wykonać swoje funkcje w ramach określonych czasów odpowiedzi, czasów przetwarzania oraz przepustowości.
Nadmierna emocjonalna lub psychologiczna zależność od innej osoby, szczególnie w próbach zmiany aktualnego (niepożądanego) zachowania tej osoby, przy równoczesnym wspieraniu jej w kontynuowaniu tegoż zachowania. Na przykład, w testowaniu oprogramowania, narzekanie na opóźnione dostawy i równocześnie radowanie się z koniecznego „heroizmu” wymagającego pracy po godzinach, by nadrobić opóźnienie, co wzmacnia tylko opóźnienia.
Programowany, dostosowany do potrzeb interfejs umożliwiający automatyczne testowanie przedmiotu testów.
Czynność podczas wykonywania testów użyteczności zdefiniowana przez moderatora, która powinna być realizowana przez uczestnika testów użyteczności przez zadany okres czasu.
Zagrożenie zabezpieczeń, mające swe źródło w organizacji, często będące autoryzowanym użytkownikiem systemu.
Status wyniku testu, dla którego wynik rzeczywisty jest zgodny z wynikiem oczekiwanym.
Przekształcenie danych w ten sposób, by utrudnić człowiekowi poznanie danych oryginalnych.
Faza testów, w której zbierane są dane z zakończonych aktywności w celu podsumowania doświadczeń, testaliów, faktów i liczb. Faza zamknięcia testów składa się z finalizowania i archiwizacji testaliów i oceny procesu testowego, włączając w to przygotowanie raportu oceny testu.
Działania skoncentrowane na zapewnieniu, że wymagania jakościowe będą spełnione.
Chronologiczny zapis szczegółów związanych z wykonaniem testów.
Czynność tworzenia dziennika (logu) testowego.
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.
nadzór nad generacją obciążenia wraz z kontrolą i raportowaniem wydajności modułu lub systemu.
Stosowane w całej organizacji podejście do zarządzania koncentrujące się na jakości, oparte na udziale w nim wszystkich członków organizacji i mające na celu długofalowy sukces poprzez satysfakcję klientów oraz korzyści dla wszystkich członków organizacji oraz społeczeństwa. Zarządzanie poprzez jakość składa się z następujących faz: planowanie, organizowanie, kierowanie, kontrolowanie i zapewnienie. (TQM od ang. Total Quality Management).
Proces radzenia sobie z ryzykiem.
Planowanie, harmonogramowanie, szacowanie, monitorowanie, raportowanie, nadzór i zamykanie czynności testowych.
Metoda pomiaru i zarządzania testowaniem w sesjach. (SBMT od ang. session-based test management).
(1) Ustrukturalizowane podejście do przejścia (przechodzenia) jednostek i organizacji z bieżącego stanu do przyszłego pożądanego stanu. (2) Kontrolowany sposób wprowadzania zmiany, lub proponowanej zmiany, do produktu lub usługi.
Stopień, w jakim moduł lub system może zastąpić inny określony moduł lub system w tym samym celu w tym samym środowisku.
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ł.
Proces otrzymywania informacji o kontach użytkowników w oparciu o wersje próbne i błędy w intencji użycia tych danych w ataku na zabezpieczenia.
Ośrodek, który zapewnia zdalny dostęp do środowiska testowego.
Stopień, w jakim moduł lub system jest dopasowany do różnych lub zmieniających się środowisk sprzętowych, programowych lub innych środowisk operacyjnych lub produkcyjnych.
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.
Ramy procesu, które opisują kluczowe elementy efektywnego rozwoju produktu i procesu utrzymania. Zintegrowany model dojrzałości organizacyjnej składa się z najlepszych praktyk w planowaniu, inżynierii i zarządzaniu rozwojem i utrzymaniem produktu. (CMMI - od ang. Capability Maturity Model Integration)
Pięciostopniowa struktura umożliwiająca doskonalenie procesu testowego, zgodna ze Zintegrowanym Modelem Dojrzałości Organizacyjnej - Capability Maturity Model Integration (CMMI), która opisuje kluczowe elementy efektywnego procesu testowego. (TMMi - od ang. Test Maturity Model integration).
Pokrycie wszystkich pojedynczych wyników warunków, których zmiana wpływa niezależnie na wynik decyzji. (MC/DC od ang. modified condition/decision coverage).
Pokrycie wszystkich pojedynczych wyników warunków, których zmiana wpływa niezależnie na wynik decyzji. (MC/DC od ang. modified condition/decision coverage).
Białoskrzynkowa technika testowania w której przypadki testowe są zaprojektowane tak, sprawdzić pojedyncze wyniki warunków, których zmiana niezależnie wpływa na wynik decyzji.
Białoskrzynkowa technika testowania w której przypadki testowe są zaprojektowane tak, sprawdzić pojedyncze wyniki warunków, których zmiana niezależnie wpływa na wynik decyzji.
Stopień, w jakim użytkownicy mogą rozpoznać, czy moduł lub system jest odpowiedni do ich potrzeb.
instrument strategicznego zarządzania działaniem firmy, który umożliwia mierzenie, czy operacyjna działalność organizacji jest zgodna z jej celami określonymi w biznesowej wizji i strategii.
Stopień, w jakim ilości i rodzaje zasobów używanych przez produkt lub system spełniają wymagania podczas wykonywania jego funkcji.
Technika obliczania przez kompilator lub interpreter wartości logicznych warunków złożonych, w której warunek po jednej stronie operatora logicznego może nie być wyliczany, jeżeli wartość logiczna warunku po drugiej stronie jest wystarczająca do określenia wartości logicznej całego warunku złożonego.
Grupa metodyk wytwarzania oprogramowania oparta na iteracyjnym, przyrostowym modelu wytwarzania oprogramowania, w których wymagania i rozwiązania ewoluują poprzez współpracę w ramach samoorganizujących się, wielofunkcyjnych zespołów.
Oprogramowanie przeznaczone do uszkodzenia systemu lub jego modułów.
Stopień, w jakim projekt lub wewnętrzna struktura modułu lub systemu jest trudna do zrozumienia, utrzymania i zweryfikowania.
Maksymalna liczba liniowo niezależnych ścieżek w programie.
Proces, w którym podejmowane są decyzje i wdrażane środki ochronne w celu zmniejszenia lub utrzymania ryzyk na określonych poziomach.
Atak na zabezpieczenia odgadujący hasła dostępu w systemie komputerowym lub przesyłane w sieci.
Stopień, w jakim moduł lub system może być używany przez określonych użytkowników w celu osiągnięcia specyficznych celów nauki z satysfakcją i wolnością od ryzyka w określonym kontekście użytkowania.
Stopień, w jakim produkt lub system posiada atrybuty umożliwiające łatwość jego obsługi i nadzoru.
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.
Stopień, w jakim moduł lub system może się łączyć z innymi modułami lub systemami.
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.
Średni czas, w jakim system będzie uruchomiony po awarii. (MTTR od ang. Mean Time To Repair).
Uśredniony czas pomiędzy kolejnymi awariami modułu lub systemu. (MTBF od ang. Mean Time Between Failures).
Ś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.
Uogólniony termin na testy dynamiczne w różnych wirtualnych środowiskach testowych.