Analiza kodu źródłowego przeprowadzona bez wykonywania oprogramowania.
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.
Działanie człowieka powodujące powstanie nieprawidłowego rezultatu.
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.
Osobiste doświadczenia i reakcje z użycia lub przewidywanego użycia produktu software'owego.
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.
Ogólnie rozpoznawalna praktyczna zasada wspomagająca osiągnięcie celu.
Element języka programowania, który jest zwykle najmniejszą niepodzielną jednostką wykonania.
Wszystkie moduły systemu, które dostarczają informacji i nadzorują użytkownika, by zrealizować określone zadania systemu.
Rodzaj cyklu wytwarzania oprogramowania, w którym moduł lub system jest wytwarzany w serii powtarzanych cykli.
Stopień, w jakim moduł 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.
zestaw działań mających na celu ocenę jakości modułu lub systemu.
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.
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.
Skala pomiaru i sposób jej stosowania do pomiarów.
Liczba bądź kategoria przypisana do atrybutu/cechy obiektu poprzez wykonanie pomiaru.
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.
Status wyniku testu, w którym rzeczywisty wynik nie zgadza się z wynikiem oczekiwanym.
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).
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.
Czynność tworzenia planów testów lub wprowadzanie do nich zmian
Podejście do wytwarzania oprogramowania, w którym przypadki testowe są projektowane i wdrażane przed opracowaniem odpowiedniego modułu lub systemu.
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.
Działanie człowieka powodujące powstanie nieprawidłowego rezultatu.
Poziom (biznesowej) ważności określony dla elementu, np. defektu.
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.
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.
Konsekwencja/wynik wykonania testu.
Konsekwencja/wynik wykonania testu.
Czynnik, który w przyszłości może skutkować negatywnymi konsekwencjami.
Iteracyjna, przyrostowa struktura zarządzania projektem, powszechnie stosowana w zwinnym wytwarzaniu oprogramowania.
Nieprzerwany okres czasu poświęcony na testowanie.
Spotkanie na końcu projektu, podczas którego członkowie zespołu projektowego oceniają projekt i wyciągają wnioski, które mogą być wykorzystane w następnym projekcie.
Spotkanie na końcu projektu, podczas którego członkowie zespołu projektowego oceniają projekt i wyciągają wnioski, które mogą być wykorzystane w następnym projekcie.
Środowisko, w skład którego wchodzi sprzęt, wyposażenie, symulatory, narzędzia programistyczne oraz inne elementy wspierające, potrzebne do wykonania testu.
Formalny, o ile to możliwe obowiązkowy, zbiór wymagań stworzony i używany do opisu zalecanego spójnego podejścia do sposobu pracy lub do dostarczania wytycznych (np. normy ISO/IEC, normy IEEE lub normy w organizacjach).
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.
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.
Zestaw jednego lub więcej przypadków testowych.
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).
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Testowanie oparte na lub wykorzystujące modele. (MBT - od ang. Model-Based Testing) .
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
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.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Testowanie w oparciu o doświadczenie, wiedzę i intuicję testera.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Podejście, w którym dwie osoby równocześnie współpracują nad testowaniem produktu prac.
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”.
Sprawdzanie poprawności i dostarczenie obiektywnego dowodu, że produkt procesu wytwarzania oprogramowania spełnia potrzeby i wymagania użytkownika.
Stopień wpływu defektu na rozwój lub działanie modułu lub systemu.
Sprawdzenie poprawności i dostarczenie obiektywnego dowodu, że produkt procesu wytwarzania oprogramowania spełnia zdefiniowane wymagania.
Konsekwencja/wynik wykonania testu.
Konsekwencja/wynik wykonania testu.
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).
Status wyniku testu, dla którego wynik rzeczywisty jest zgodny z wynikiem oczekiwanym.
Metoda pomiaru i zarządzania testowaniem w sesjach. (SBMT od ang. session-based test management).
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.
Stopień, w jakim projekt lub wewnętrzna struktura modułu lub systemu jest trudna do zrozumienia, utrzymania i zweryfikowania.
Środowisko, w skład którego wchodzi sprzęt, wyposażenie, symulatory, narzędzia programistyczne oraz inne elementy wspierające, potrzebne do wykonania testu.
Ciąg sąsiednich krawędzi w grafie skierowanym.
Ciąg sąsiednich krawędzi w grafie skierowanym.
Środowisko, w skład którego wchodzi sprzęt, wyposażenie, symulatory, narzędzia programistyczne oraz inne elementy wspierające, potrzebne do wykonania testu.