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)
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%).
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.
Analiza kodu źródłowego przeprowadzona bez wykonywania oprogramowania.
Narzędzie wykonujące analizę statyczną.
Narzędzie wykonujące analizę statyczną.
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.
Proces potwierdzający, że moduł, system lub osoba spełnia określone wymagania.
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).
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) .
Osobiste doświadczenia i reakcje z użycia lub przewidywanego użycia produktu software'owego.
Menedżer wyższego szczebla zarządzający kierownikami testów.
Chronologiczny zapis szczegółów związanych z wykonaniem testów.
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.
Ogólnie rozpoznawalna praktyczna zasada wspomagająca osiągnięcie celu.
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).
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.
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.
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.
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.
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.
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.
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.
Skala pomiaru i sposób jej stosowania do pomiarów.
Liczba bądź kategoria przypisana do atrybutu/cechy obiektu poprzez wykonanie pomiaru.
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.
Struktura, w której procesy tego samego rodzaju są sklasyfikowane w ogólnym modelu.
Narzędzie wykonujące analizę statyczną.
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.
Rozdzielenie odpowiedzialności, które sprzyja zapewnieniu obiektywności testowania.
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).
Uporządkowana ocena procesów wytwarzania oprogramowania w organizacji w stosunku do modelu wzorcowego.
Proces definiowania i implementacji profilu produkcyjnego.
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.
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.
Miary pokrycia oparte na wewnętrznej strukturze modułu lub systemu.
Dokument wysokiego poziomu opisujący zasady, podejście i główne zadania w organizacji dotyczące testowania.
Dokument wysokiego poziomu opisujący zasady, podejście i główne zadania w organizacji dotyczące testowania.
Proces przypisania liczby bądź kategorii do obiektu, mający na celu opisanie danej właściwości obiektu.
Działanie człowieka powodujące powstanie nieprawidłowego rezultatu.
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.
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.
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)
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.
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.
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.
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.
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.
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.
Nieprzerwany okres czasu poświęcony na testowanie.
Stopień w jakim moduł lub system może być dostosowany do zmieniającego się obciążenia.
Spotkanie na końcu projektu, podczas którego członkowie zespołu projektowego oceniają projekt i wyciągają wnioski, które mogą być wykorzystane w następnym projekcie.
Spotkanie na końcu projektu, podczas którego członkowie zespołu projektowego oceniają projekt i wyciągają wnioski, które mogą być wykorzystane w następnym projekcie.
Środowisko, w skład którego wchodzi sprzęt, wyposażenie, symulatory, narzędzia programistyczne oraz inne elementy wspierające, potrzebne do wykonania testu.
Formalny, o ile to możliwe obowiązkowy, zbiór wymagań stworzony i używany do opisu zalecanego spójnego podejścia do sposobu pracy lub do dostarczania wytycznych (np. normy ISO/IEC, normy IEEE lub normy w organizacjach).
standard opisujący cechy projektu lub opis projektu danych lub modułów programu.
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.
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.
Bazująca na wiedzy eksperckiej technika estymacji opierająca się na zbiorowej wiedzy członków zespołu polegająca na dokładnym szacowaniu.
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).
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.
Testowanie oparte na analizie wewnętrznej struktury modułu lub systemu.
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 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.
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 wykonywane przez osoby, które nie pracują w tej samej lokalizacji co zespół projektowy i nie są zatrudnione w organizacji.
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.
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.
Uproszczona technika prowadzenia warsztatów, która pomaga określić krytyczne cechy rozwoju nowego produktu. (QFD od ang. Quality Function Deployment)
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.
Wymaganie dotyczące użyteczności modułu lub systemu.
Narzędzie softwarowe wytworzone specjalnie dla grupy użytkowników lub klientów.
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.
Chronologiczny zapis szczegółów związanych z wykonaniem testów.
(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.
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).
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.
Uśredniony czas pomiędzy kolejnymi awariami modułu lub systemu. (MTBF od ang. Mean Time Between Failures).
Środowisko, w skład którego wchodzi sprzęt, wyposażenie, symulatory, narzędzia programistyczne oraz inne elementy wspierające, potrzebne do wykonania testu.