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.
Całkowity proces identyfikacji ryzyk i ich oceny.
Proces oceny modułu lub systemu bez jego wykonywania, oparty na jego formie, strukturze, zawartości lub dokumentacji.
Czynność polegająca na identyfikowaniu warunków testowych w wyniku analizy podstawy testów.
Czarnoskrzynkowa technika testowania, w której przypadki testowe są projektowane w oparciu o wartości brzegowe.
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.
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. .
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.
Zdarzenie, w którym moduł lub system nie wykonuje wymaganej funkcji w określonym zakresie.
Działanie człowieka powodujące powstanie nieprawidłowego rezultatu.
Przyczyna lub powód testowania.
Kategoria cech oprogramowania, które mają wpływ na jakość produktu prac.
Kategoria cech oprogramowania, które mają wpływ na jakość produktu prac.
Kategoria cech oprogramowania, które mają wpływ na jakość produktu prac.
Praktyka wytwarzania oprogramowania polegająca na automatycznym łączeniu, integrowaniu i testowaniu wszystkich zmian w oprogramowaniu w momencie ich wprowadzania.
Instancja procesu testowego dotycząca pojedynczej, identyfikowalnej wersji przedmiotu testów.
Czynności wykonywane na każdym etapie wytwarzania oprogramowania oraz układ ich wzajemnych relacji logicznych i chronologicznych. (SDLC - od ang. software development lifecycle).
Technika testowania oparta na analizie specyfikacji modułu lub systemu.
Dane niezbędne do wykonania testów.
Typ instrukcji, w którym wybór między dwoma lub więcej możliwymi wynikami skutkuje wykonaniem określonego zestawu działań.
Niedoskonałość lub wada produktu pracy, polegająca na niespełnieniu wymagań.
Zbiór warunków definiujących kiedy można oficjalnie rozpocząć określone zadanie.
(1) Zdolność organizacji w odniesieniu do skuteczności i wydajności jej procesów i praktyk pracy. (2) Stopień, w jakim moduł lub system spełnia wymagania niezawodności w normalnym działaniu.
Stopień, w jakim moduł lub system zapewnia prawidłowe wyniki z wymaganą precyzją.
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.
Stopień wykorzystania zasobów w stosunku do osiąganych wyników.
Zbiór warunków definiujących kiedy można oficjalnie uznać określone zadanie za ukończone.
Jakościowa lub ilościowa miara ryzyka zdefiniowana przez wpływ i prawdopodobieństwo.
Część przedmiotu testów wykorzystywana w procesie testowym.
Stopień, w jakim interfejs użytkownika umożliwia przyjemną i satysfakcjonującą interakcję dla użytkownika.
Specyficzna instancja procesu testowego.
(1) Osoba odpowiedzialna za prowadzenie spotkań przeglądowych. (2) Osoba, która przeprowadza sesję testów użyteczności.
Stopień, w jakim moduł lub system zapewnia funkcje spełniające określone i domyślne potrzeby, gdy jest używany w określonych warunkach.
Rodzaj narzędzia testowego, które pozwala na wybranie danych z istniejącej bazy danych lub ich stworzenie, wygenerowanie, przetworzenie i edycję dla użycia w testowaniu.
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.
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).
Harmonogram opisujący kolejność wykonywania zestawów testowych w ramach cyklu testowego.
Ogólnie rozpoznawalna praktyczna zasada wspomagająca osiągnięcie celu.
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.
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.
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.
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.
Stopień w jakim moduł lub system zapobiega nieautoryzowanemu dostępowi oraz modyfikacji modułu, systemu lub danych.
Wszystkie moduły systemu, które dostarczają informacji i nadzorują użytkownika, by zrealizować określone zadania systemu.
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.
Stopień, w jakim moduł, system lub proces spełnia określone wymagania i/lub spełnia potrzeby i oczekiwania klienta lub użytkownika.
Dokument opisujący cel lub zadania dla sesji testów.
Dokument opisujący cel lub zadania dla sesji testów.
Osoba odpowiedzialna za zarządzanie działaniami testowymi, zasobami i oceną przedmiotu testów.
Podzbiór dziedziny wartości zmiennej w module lub systemie, dla którego zakłada się, na podstawie specyfikacji, że wszystkie wartości będą traktowane przez system w podobny sposób.
Podzbiór dziedziny wartości zmiennej w module lub systemie, dla którego zakłada się, na podstawie specyfikacji, że wszystkie wartości będą traktowane przez system w podobny sposób.
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 zestaw funkcji obejmuje wszystkie określone zadania i cele użytkownika.
Przypadek testowy z konkretnymi warunkami wstępnymi, wartościami wejściowymi, wynikami oczekiwanymi, warunkami wyjściowymi i odpowiednimi akcjami (o ile ma to zastosowanie).
Użytkownicy, zadania, wyposażenie (sprzęt, oprogramowanie i materiały) oraz fizyczne i społeczne środowiska, w których oprogramowanie jest używane.
Całkowity koszt poniesiony na działania jakościowe, na który składają się koszty działań prewencyjnych, koszty wykrycia, koszty awarii wewnętrznych i koszty awarii zewnętrznych.
Kryteria, które moduł lub system musi spełniać, aby został zaakceptowany przez użytkownika, klienta lub inny uprawniony podmiot.
Zbiór warunków definiujących kiedy można oficjalnie uznać określone zadanie za ukończone.
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.
Fizyczne miejsce, w którym przeprowadza się bezinwazyjne obserwacje reakcji uczestników oraz ich odpowiedzi na działanie oprogramowania.
(1) Osoba odpowiedzialna za prowadzenie spotkań przeglądowych. (2) Osoba, która przeprowadza sesję testów użyteczności.
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.
Czarnoskrzynkowa technika, w której przypadki testowe projektowane są za pomocą drzewa klasyfikacji.
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.
Czynności wykonywane na każdym etapie wytwarzania oprogramowania oraz układ ich wzajemnych relacji logicznych i chronologicznych. (SDLC - od ang. software development lifecycle).
Struktura, w której procesy tego samego rodzaju są sklasyfikowane w ogólnym modelu.
Sekwencyjny model cyklu życia oprogramowania opisujący relację jeden-do-jednego pomiędzy głównymi fazami wytwórczymi od specyfikacji wymagań biznesowych do dostarczenia, a odpowiadającymi im poziomami testów od testów akceptacyjnych do testów modułowych.
(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.
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.
Rodzaj narzędzia testowego, które pozwala na wybranie danych z istniejącej bazy danych lub ich stworzenie, wygenerowanie, przetworzenie i edycję dla użycia w testowaniu.
Narzędzie testowe, które wykonuje testy na wyznaczonym obiekcie testowym i ocenia wyniki w stosunku do oczekiwanych wyników i warunków końcowych.
Narzędzie wspomagające zarządzanie testami i sterowanie częścią procesu testowego. Zwykle ma kilka funkcji takich jak: zarządzanie testaliami, planowanie testów w czasie, logowanie rezultatów, śledzenie postępu prac, zarządzanie incydentami oraz raportowanie wyników testów.
Oprogramowanie lub sprzęt, który obsługuje jedno lub więcej działań testowych.
Status wyniku testu, w którym rzeczywisty wynik nie zgadza się z wynikiem oczekiwanym.
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).
Ocena produktu pracy wykorzystująca heurystyki.
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).
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.
Wynik kontroli, który identyfikuje pewne istotne kwestie, problemy lub możliwości.
Stopień, w jakim system lub moduł może działać prawidłowo przy nieprawidłowych danych lub przy niekorzystnych warunkach środowiskowych.
Stopień, w jakim 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.
Oprogramowanie stanowiące produkt wytworzony na szeroki rynek, tj. dla dużej liczby klientów, które jest dostarczane wielu klientom w identycznej postaci. (COTS od ang. Commercial off-the-Shelf).
Oprogramowanie stanowiące produkt wytworzony na szeroki rynek, tj. dla dużej liczby klientów, które jest dostarczane wielu klientom w identycznej postaci. (COTS od ang. Commercial off-the-Shelf).
Stopień, w jakim moduł lub system jest sprawny i dostępny, gdy jest wymagane jego użycie.
Proces modyfikacji modułu lub systemu po jego wydaniu, mający na celu poprawę defektów, charakterystyk jakościowych lub dostosowanie do zmienionego środowiska.
Dokumentacja opisująca cele testowe do osiągnięcia oraz środki i harmonogram ich realizacji, zorganizowana tak, by koordynować czynności testowe.
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.
Stopień, w jakim określone elementy pokrycia zostały określone lub sprawdzone przez zestaw testowy wyrażony w procentach.
Pokrycie sekwencji N+1-przejść.
Stopień, w jakim określone elementy pokrycia zostały określone lub sprawdzone przez zestaw testowy wyrażony w procentach.
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ą.
Stopień, w jakim moduł lub system zapewnia dostęp do danych tylko tym osobom, które mają do tego uprawnienia.
Jakościowa lub ilościowa miara ryzyka zdefiniowana przez wpływ i prawdopodobieństwo.
Specyficzna instancja procesu testowego.
Poziom (biznesowej) ważności określony dla elementu, np. defektu.
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 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.
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
Zabezpieczenie informacji umożliwiających identyfikację osoby lub innych danych wrażliwych przed niepowołanym ujawnieniem.
Atrybut lub kombinacja atrybutów uzyskana z jednego lub więcej warunków testowych za pomocą techniki testowej.
Moduł lub system podlegający testowaniu.
Typ testowania statycznego, podczas którego produkt pracy lub proces jest oceniany przez jedną lub więcej osób w celu wykrycia problemów i wprowadzenia ulepszeń.
Typ przeglądu, który przebiega według zdefiniowanego procesu, z formalnie udokumentowanym wynikiem.
Technika przeglądu oparta na liście pytań lub wymaganych atrybutów.
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.
Ł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.
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).
Typ cyklu życia oprogramowania, w którym moduł lub system wytwarzany jest w serii cyklów.
Dokumentacja wystąpienia, charakteru i statusu usterki.
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 wystąpienia, charakteru i statusu usterki.
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.
Rodzaj testu związanego ze zmianą przeprowadzonego po naprawieniu defektu w celu potwierdzenia, że awaria spowodowana przez ten defekt już nie występuje.
Konsekwencja/wynik wykonania testu.
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.
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 wpływające na jakość produktu.
Ryzyko wpływające na sukces projektu.
wytworzone/zaobserwowane zachowanie się modułu lub systemu, podczas gdy ten moduł lub system jest testowany.
wytworzone/zaobserwowane zachowanie się modułu lub systemu, podczas gdy ten moduł lub system jest testowany.
Iteracyjna, przyrostowa struktura zarządzania projektem, powszechnie stosowana w zwinnym wytwarzaniu oprogramowania.
Ciąg instrukcji wykonujący zestaw testowy.
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.
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.
Środowisko, w skład którego wchodzi sprzęt, wyposażenie, symulatory, narzędzia programistyczne oraz inne elementy wspierające, potrzebne do wykonania testu.
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).
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.
Dokumentacja zgodna z polityką testową, która opisuje ogólne wymagania dotyczące testowania oraz szczegółowe informacje na temat przeprowadzania testów w organizacji.
Dokumentacja zgodna z polityką testową, która opisuje ogólne wymagania dotyczące testowania oraz szczegółowe informacje na temat przeprowadzania testów w organizacji.
Rodzaj przedmiotu testów będącego systemem. (SUT od ang. System Under Test).
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 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 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.
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.
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.
Testowanie przeprowadzane przez wprowadzanie poleceń do testowanego oprogramowania poprzez bezpośrednie wykorzystanie interfejsu tej aplikacji.
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.
Testy wykonywane w celu wykrycia usterek w interfejsach i interakcjach pomiędzy integrowanymi modułami.
Poziom testów koncentrujący się na interakcjach między modułami lub systemami.
Testowanie wykonywane w celu wykrycia defektów w interfejsach i interakcjach pomiędzy modułami lub systemami.
Poziom testów, który koncentruje się na poszczególnych modułach sprzętowych lub programowych.
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 przeprowadzane w celu sprawdzenia zgodności modułu lub systemu z wymaganiami niefunkcjonalnymi.
Czarnoskrzynkowa technika testowania, w której przypadki testowe są projektowane w celu wykonywania zachowań przypadków użycia.
Testowanie, w którym zarządzanie, wybór, priorytetyzacja i wykorzystanie działań testowych i zasobów są oparte na odpowiednich na odpowiednich typach i poziomach ryzyka.
Technika skryptowa wykorzystująca skrypty zawierające wysokopoziomowe słowa kluczowe oraz pliki wspomagające, zawierające niskopoziomowe skrypty implementujące te słowa kluczowe.
Technika skryptowa wykorzystująca skrypty zawierające wysokopoziomowe słowa kluczowe oraz pliki wspomagające, zawierające niskopoziomowe skrypty implementujące te słowa kluczowe.
Testowanie zmian we wdrożonym systemie lub testowanie wpływu zmienionego środowiska na wdrożony system.
Rodzaj testu związanego ze zmianą przeprowadzonego po naprawieniu defektu w celu potwierdzenia, że awaria spowodowana przez ten defekt już nie występuje.
Testy wykonywane w celu wykrycia usterek w interfejsach i interakcjach pomiędzy integrowanymi modułami.
Czarnoskrzynkowa technika testowania, w której przypadki testowe są zaprojektowane tak, by wykonywać elementy modelu przejścia stanów.
Rodzaj testowania związanego ze zmianami mającego na celu wykrycie, czy defekty zostały wprowadzone lub odkryte w niezmienionych obszarach oprogramowania.
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.
Poziom testów, który koncentruje się na sprawdzeniu, czy system jako całość spełnia określone wymagania.
Testowanie mające na celu ocenę stopnia, w jakim system może być używany przez określonych użytkowników w sposób skuteczny, wydajny i przynoszący satysfakcję w określonym kontekście użycia
Testowanie w oparciu o doświadczenie, wiedzę i intuicję testera.
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.
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.
Proces testowy mający na celu określenie wydajności oprogramowania.
Testy wykonywane przez osoby, które pracują w zespole projektowym, ale nie są zatrudnione w organizacji.
Grupa czynności w testowaniu ukierunkowana na określone charakterystyki modułu lub systemu, oparta na specyficznych celach testowania.
Program aktywności zaprojektowany tak, by poprawić wydajność i dojrzałość procesu testowego w organizacji.
Niedoskonałość lub wada produktu pracy, polegająca na niespełnieniu wymagań.
Stopień, w jakim moduł lub system może być modyfikowany przez wyznaczony personel.
Stopień, w jakim dany moduł lub system może być używany przez określonych użytkowników dla osiągnięcia określonych celów w określonym kontekście użytkowania.
Sprawdzanie poprawności i dostarczenie obiektywnego dowodu, że produkt procesu wytwarzania oprogramowania spełnia potrzeby i wymagania użytkownika.
Minimalna lub maksymalna wartość uporządkowanej klasy równoważności.
Wyrażenie logiczne, którego wartością może być prawda albo fałsz.
Wyrażenie logiczne, którego wartością może być prawda albo fałsz.
Testowalna własność modułu lub systemu zidentyfikowana jako podstawa do testowania.
Wymagany stan elementu testowego i jego środowiska przed wykonaniem przypadku testowego.
Stopień wpływu defektu na rozwój lub działanie modułu lub systemu.
Dane otrzymane przez moduł lub system z zewnętrznego źródła.
Sprawdzenie poprawności i dostarczenie obiektywnego dowodu, że produkt procesu wytwarzania oprogramowania spełnia zdefiniowane wymagania.
Symulacja działań wykonywanych przez użytkownika określonego w profilu operacyjnym.
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).
Miara, która zapewnia oszacowanie lub ocenę określonych atrybutów uzyskanych z modelu w odniesieniu do zdefiniowanych potrzeb informacyjnych.
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.
Stopień, w jakim moduł lub system wykorzystuje czas, zasoby i pojemność podczas wykonywania wyznaczonych funkcji.
Dane przesyłane przez moduł lub system do zewnętrznego miejsca przeznaczenia.
Czynność polegająca na przeprowadzeniu testu modułu lub systemu, by otrzymać rzeczywiste wyniki.
Postanowienie zawierające kryteria, które należy spełnić.
Testowalna własność modułu lub systemu zidentyfikowana jako podstawa do testowania.
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.
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.
Status wyniku testu, dla którego wynik rzeczywisty jest zgodny z wynikiem oczekiwanym.
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.
Czynność tworzenia dziennika (logu) testowego.
Proces rozpoznawania, rejestrowania, klasyfikacji, badania, rozwiązywania i usuwania defektów.
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.
Planowanie, harmonogramowanie, szacowanie, monitorowanie, raportowanie, nadzór i zamykanie czynności testowych.
(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ł.
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.
Stopień, w jakim użytkownicy mogą rozpoznać, czy moduł lub system jest odpowiedni do ich potrzeb.
Stopień, w jakim ilości i rodzaje zasobów używanych przez produkt lub system spełniają wymagania podczas wykonywania jego funkcji.
Stopień, w jakim projekt lub wewnętrzna struktura modułu lub systemu jest trudna do zrozumienia, utrzymania i zweryfikowania.
Proces, w którym podejmowane są decyzje i wdrażane środki ochronne w celu zmniejszenia lub utrzymania ryzyk na określonych poziomach.
Stopień, w jakim 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.
Środowisko, w skład którego wchodzi sprzęt, wyposażenie, symulatory, narzędzia programistyczne oraz inne elementy wspierające, potrzebne do wykonania testu.