Terms related to Advanced Agile Technical Tester 2019

Całkowity proces identyfikacji ryzyk i ich oceny.
Analiza kodu źródłowego przeprowadzona bez wykonywania oprogramowania.
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.
Użycie oprogramowania do wykonania lub wspierania czynności testowych, np. zarządzania testami, projektowania testów, wykonania testów i sprawdzania wyników.
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.
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
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ń.
Chronologiczny zapis szczegółów związanych z wykonaniem testów.
Stopień wykorzystania zasobów w stosunku do osiąganych wyników.
Jakościowa lub ilościowa miara ryzyka zdefiniowana przez wpływ i prawdopodobieństwo.
Specyficzna instancja procesu 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.
Czynność polegająca na przygotowaniu testaliów potrzebnych do wykonania testów, oparta na analizie i projektowaniu testów.
Uczestnik przeglądu, który identyfikuje problemy w produkcie pracy.
Wszystkie moduły systemu, które dostarczają informacji i nadzorują użytkownika, by zrealizować określone zadania systemu.
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.
pokrycie kodu
Uczestnik przeglądu, który identyfikuje problemy w produkcie pracy.
Kryteria, które moduł lub system musi spełniać, aby został zaakceptowany przez użytkownika, klienta lub inny uprawniony podmiot.
Chronologiczny zapis szczegółów związanych z wykonaniem testów.
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.
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 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).
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.
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.
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.
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.
Niedoskonałość lub wada produktu pracy, polegająca na niespełnieniu wymagań.
Implementacja strategii testowej w określonym projekcie.
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.
Stopień, w jakim określone elementy pokrycia zostały określone lub sprawdzone przez zestaw testowy wyrażony w procentach.
Działanie człowieka powodujące powstanie nieprawidłowego rezultatu.
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.
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.
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ń.
Przegląd wykonywany przez inne osoby o podobnych kwalifikacjach.
Uczestnik przeglądu, który identyfikuje problemy w produkcie pracy.
Stopień, w jakim maksymalne wartości graniczne parametru modułu lub systemu spełniają wymagania.
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.
Konsekwencja/wynik wykonania testu.
Konsekwencja/wynik wykonania testu.
Czynnik, który w przyszłości może skutkować negatywnymi konsekwencjami.
Stopień w jakim moduł lub system może być dostosowany do zmieniającego się obciążenia.
Technika rozwoju oprogramowania, w której specyfikacja jest definiowana poprzez przykłady.
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.
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.
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.
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.
Rodzaj przedmiotu testów będącego systemem. (SUT od ang. System Under Test).
Procedura używana do definiowania warunków testowych, projektowania przypadków testowych i określania danych testowych.
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.
Wykwalifikowany profesjonalista, zaangażowany w testowanie modułu lub systemu.
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.
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 przeprowadzane w celu sprawdzenia zgodności modułu lub systemu z wymaganiami niefunkcjonalnymi.
Testowanie oparte na lub wykorzystujące modele. (MBT - od ang. Model-Based Testing) .
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.
Czarnoskrzynkowa technika testowania, w której przypadki testowe są zaprojektowane tak, by wykonywać elementy modelu przejścia stanów.
Testowanie, które dynamicznie reaguje na zachowanie przedmiotu testów i na otrzymane wyniki testowania.
Czarnoskrzynkowa technika testowania, w której przypadki testowe są zaprojektowane tak, by wykonywać elementy modelu przejścia stanów.
Technika skryptowa wykorzystująca pliki danych do przechowywania danych testowych i wyników oczekiwanych, które są potrzebne do wykonania skryptów testowych.
Poziom testów, który koncentruje się na sprawdzeniu, czy system jako całość spełnia określone wymagania.
Testowanie w oparciu o doświadczenie, wiedzę i intuicję testera.
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”.
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.
Sprawdzanie poprawności i dostarczenie obiektywnego dowodu, że produkt procesu wytwarzania oprogramowania spełnia potrzeby i wymagania użytkownika.
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.
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.
Technika umożliwiająca wirtualne dostarczanie usług, które są zdalnie wdrażane, dostępne i zarządzane
Miara, która zapewnia oszacowanie lub ocenę określonych atrybutów uzyskanych z modelu w odniesieniu do zdefiniowanych potrzeb informacyjnych.
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.
Konsekwencja/wynik wykonania testu.
Konsekwencja/wynik wykonania testu.
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).
Odpowiedź modułu lub systemu na zestaw wartości wejściowych i warunków wstępnych.
Status wyniku testu, dla którego wynik rzeczywisty jest zgodny z wynikiem oczekiwanym.
Chronologiczny zapis szczegółów związanych z wykonaniem testó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.
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ł.
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 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.