Czarnoskrzynkowa technika projektowania przypadków testowych, w której przypadki te są projektowane na podstawie grafów przyczynowo-skutkowych.
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.
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.
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.
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.
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).
Ogólnie rozpoznawalna praktyczna zasada wspomagająca osiągnięcie celu.
Organizacyjne artefakty niezbędne do przeprowadzenia testu, składające się ze środowisk testowych, narzędzi testowych, wyposażenia biurowego i procedur.
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.
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.
Reguły decyzyjne wykorzystywane do określenia czy element testowy zaliczył test.
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).
Model opisujący testalia używane do testowania testowanego modułu lub systemu.
Rodzaj narzędzia testowego, które pozwala na wybranie danych z istniejącej bazy danych lub ich stworzenie, wygenerowanie, przetworzenie i edycję dla użycia w testowaniu.
Narzędzie testowe, które wykonuje testy na wyznaczonym obiekcie testowym i ocenia wyniki w stosunku do oczekiwanych wyników i warunków końcowych.
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.
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.
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.
Plan testu, który odnosi się do jednego poziomu testowania.
Czynność tworzenia planów testów lub wprowadzanie do nich zmian
Przyczyna defektu, która – gdy zostanie wyeliminowana – wystąpienie tego typu defektu redukuje lub usuwa.
Pokrycie sekwencji N+1-przejść.
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.
Odsetek defektów, które zostały usunięte w tej samej fazie cyklu życia oprogramowania, w której zostały wprowadzone.
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.
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.
Czynnik, który w przyszłości może skutkować negatywnymi konsekwencjami.
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.
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).
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).
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
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.
Typ testów integracyjnych wykonywanych w celu sprawdzenia poprawności przekazywania danych i sterowania pomiędzy modułami lub systemami.
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.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Testowanie zmian we wdrożonym systemie lub testowanie wpływu zmienionego środowiska na wdrożony system.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
Testowanie (ręczne lub automatyczne) wykonywane zgodnie ze skryptem testowym.
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.
Testowanie mające na celu ustalenia współdziałania oprogramowania.
Testy wykonywane przez osoby, które pracują w zespole projektowym, ale nie są zatrudnione w organizacji.
Stopień, w jaki moduł lub system może kontynuować prawidłowe działanie pomimo podania błędnych danych wejściowych.
Czarnoskrzynkowa technika projektowania przypadków testowych, w której przypadki te są projektowane na podstawie grafów przyczynowo-skutkowych.
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.
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).
Wymaganie dotyczące użyteczności modułu lub systemu.
Konsekwencja/wynik wykonania testu.
Konsekwencja/wynik wykonania testu.
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.
(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.
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 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.