Istqb, strona 2

2. Testowanie w cyklu życia oprogramowania — 100 min.
Słowa kluczowe analiza wpływu, cel testu, oprogramowanie do powszechnej sprzedaży,  podstawa testów, poziom testów, produkcyjne testy akceptacyjne, przedmiot testów, przypadek testowy, środowisko testowe, testowanie akceptacyjne, testowanie akceptacyjne przez użytkownika, testowanie akceptacyjne zgodności z prawem, testowanie akceptacyjne zgodności z umową, testowanie alfa, testowanie beta, testowanie białoskrzynkowe, testowanie funkcjonalne, testowanie integracji modułów, testowanie integracji systemów, testowanie integracyjne, testowanie modułowe, testowanie niefunkcjonalne, testowanie pielęgnacyjne, testowanie potwierdzające, testowanie regresji, testowanie systemowe, typ testów
Cele nauczania — testowanie w cyklu życia oprogramowania 2.1. Modele cyklu życia oprogramowania FL-2.1.1. (K2) Kandydat potrafi wyjaśnić relacje między czynnościami związanymi z wytwarzaniem oprogramowania a czynnościami testowymi w cyklu życia oprogramowania. FL-2.1.2. (K1) Kandydat potrafi wskazać powody, dla których konieczne jest dostosowanie modeli cyklu życia oprogramowania do kontekstu wynikającego z charakterystyki projektu i produktu. 2.2. Poziomy testów FL-2.2.1. (K2) Kandydat potrafi porównać poszczególne poziomy testów z punktu widzenia celów, podstawy testów, przedmiotów testów, typowych defektów i awarii, podejść i odpowiedzialności. 2.3. Typy testów FL-2.3.1. (K2) Kandydat potrafi porównać testowanie funkcjonalne z testowaniem niefunkcjonalnym i białoskrzynkowym. FL-2.3.2. (K1) Kandydat zdaje sobie sprawę z tego, że testy funkcjonalne, niefunkcjonalne i białoskrzynkowe mogą występować na dowolnym poziomie testowania. FL-2.3.3. (K2) Kandydat potrafi porównać przeznaczenie testowania potwierdzającego i testowania regresji. 2.4. Testowanie pielęgnacyjne FL-2.4.1. (K2) Kandydat potrafi wymienić i omówić zdarzenia wyzwalające testowanie pielęgnacyjne. FL-2.4.2. (K2) Kandydat potrafi opisać rolę analizy wpływu w testowaniu pielęgnacyjnym.

2.1. Modele cyklu życia oprogramowania
Model cyklu życia oprogramowania opisuje rodzaje czynności wykonywanych na poszczególnych etapach projektu wytwarzania oprogramowania oraz powiązania logiczne i chronologiczne między tymi czynnościami. Istnieje wiele różnych modeli cyklu życia oprogramowania, a każdy z nich wymaga innego podejścia do testowania.
2.1.1. Wytwarzanie oprogramowania a testowanie oprogramowania Znajomość powszechnie stosowanych modeli cyklu życia oprogramowania jest ważnym elementem obowiązków każdego testera, ponieważ pozwala uwzględnić właściwe czynności testowe.
Poniżej wymieniono kilka zasad dobrych praktyk testowania, które dotyczą każdego modelu cyklu życia oprogramowania:
• dla każdej czynności związanej z wytwarzaniem oprogramowania istnieje odpowiadająca jej czynność testowa;
• każdy poziom testów ma przypisane cele odpowiednie do tego poziomu;
• analizę i projektowanie testów na potrzeby danego poziomu testów należy rozpocząć podczas wykonywania odpowiadającej danemu poziomowi czynności związanej z wytwarzaniem oprogramowania;
• testerzy powinni uczestniczyć w dyskusjach dotyczących definiowania i doprecyzowywania wymagań i założeń projektu oraz w przeglądach produktów pracy (np. wymagań, założeń projektu czy też historyjek użytkownika) natychmiast po udostępnieniu wersji roboczych odpowiednich dokumentów.
Bez względu na wybrany model cyklu życia oprogramowania czynności testowe powinny rozpocząć się w początkowym etapie tego cyklu, zgodnie z zasadą wczesnego testowania.
W niniejszym sylabusie modele cyklu życia oprogramowania podzielono na następujące kategorie:
• sekwencyjne modele wytwarzania oprogramowania;
• iteracyjne i przyrostowe modele wytwarzania oprogramowania.
Sekwencyjny model wytwarzania oprogramowania opisuje proces wytwarzania oprogramowania jako liniowy przepływ czynności następujących kolejno po sobie. Oznacza to, że każda faza tego procesu powinna rozpoczynać się po zakończeniu fazy poprzedniej. W teorii poszczególne fazy nie zachodzą na siebie, ale w praktyce korzystne jest uzyskiwanie wczesnych informacji zwrotnych z kolejnej fazy.
W modelu kaskadowym (ang. waterfall) czynności związane z wytwarzaniem oprogramowania (takie jak: analiza wymagań, projektowanie, tworzenie kodu czy testowanie) wykonuje się jedna po drugiej. Zgodnie z założeniami tego modelu czynności testowe występują dopiero wtedy, gdy wszystkie inne czynności wytwórcze zostaną ukończone. 
W przeciwieństwie do modelu kaskadowego model V zakłada integrację procesu testowania z całym procesem wytwarzania oprogramowania, a tym samym wprowadza w życie zasadę wczesnego testowania. Ponadto model V obejmuje poziomy testowania powiązane z poszczególnymi, odpowiadającymi im, fazami wytwarzania oprogramowania, co dodatkowo sprzyja wczesnemu testowaniu (patrz podrozdział 2.2.). W tym modelu wykonanie testów powiązanych ze wszystkimi poziomami testów następuje sekwencyjnie, jednak w niektórych przypadkach może następować nachodzenie faz na siebie nawzajem.  W większości przypadków sekwencyjne modele wytwarzania oprogramowania pozwalają na wytworzenie oprogramowania posiadającego pełny zestaw funkcjonalności. Stosowanie takich modeli wytwarzania oprogramowania zwykle wymaga miesięcy, jeśli nie lat, pracy, aby zostało ono dostarczone do interesariuszy i użytkowników.
Przyrostowe wytwarzanie oprogramowania to proces polegający na określaniu wymagań oraz projektowaniu, budowaniu i testowaniu systemu częściami, co oznacza, że funkcjonalność oprogramowania rośnie przyrostowo. Wielkość poszczególnych przyrostów funkcjonalności zależy od konkretnego modelu cyklu życia: niektóre modele przewidują podział na większe fragmenty, a inne — na mniejsze. Jednorazowy przyrost funkcjonalności może ograniczać się nawet do wprowadzenia pojedynczej zmiany na ekranie interfejsu użytkownika lub nowej opcji zapytania. 
Wytwarzanie iteracyjne polega na specyfikowaniu, projektowaniu, budowaniu i testowaniu wspólnie grup funkcjonalności w serii cykli, często o określonym czasie trwania. Iteracje mogą zawierać zmiany funkcjonalności wytworzonych we wcześniejszych iteracjach, wspólnie ze zmianami w zakresie projektu. Każda iteracja dostarcza działające oprogramowanie, które stanowi rosnący podzbiór całkowitego zbioru funkcjonalności aż do momentu, w którym końcowa wersja oprogramowania zostaje dostarczona lub wytwarzanie zostanie zatrzymane. 
Wśród przykładów modeli iteracyjnych można wyróżnić: • Rational Unified Process (RUP®): poszczególne iteracje trwają zwykle stosunkowo długo (np. dwa lub trzy miesiące), a przyrostowe części systemu są odpowiednio duże, czyli obejmują np. dwie lub trzy grupy powiązanych funkcjonalności.
• SCRUM: poszczególne iteracje trwają stosunkowo krótko (np. kilka godzin, dni lub tygodni), a przyrostowe części systemu są odpowiednio małe, czyli obejmują na przykład dwa udoskonalenia i dwie lub trzy nowe funkcjonalności.
• Kanban: umożliwia dostarczenie jednego udoskonalenia lub jednej funkcjonalności naraz (natychmiast po przygotowaniu) bądź zgrupowanie większej liczby funkcjonalności w celu równoczesnego przekazania na środowisko produkcyjne.
• Model spiralny (lub prototypowanie): tworzy się eksperymentalne elementy przyrostowe, które następnie mogą zostać gruntownie przebudowane, a nawet porzucone na dalszych etapach wytwarzania oprogramowania.
Komponenty systemów lub systemy wykorzystujące powyższe modele często odnoszą się do nachodzących na siebie i powtarzanych w cyklu życia oprogramowania poziomów testów. W idealnej sytuacji każda funkcjonalność jest testowana na wielu poziomach, zbliżając się do finalnego wydania. Czasami też zespoły korzystają z metody ciągłego dostarczania (ang. Continuous Delivery) lub ciągłego wdrażania oprogramowania. Te podejścia pozwalają na szerokie wykorzystywanie automatyzacji  na wielu poziomach testowania (jako część potoku dostarczania oprogramowania). Ponadto wiele tego typu modeli uwzględnia koncepcję samoorganizujących się zespołów, która może zmienić sposób organizacji pracy w związku z testowaniem oraz relacje między testerami a programistami.
W każdym z powyższych modeli powstaje rosnący system, który może być dostarczany użytkownikom końcowym na zasadzie dodawania pojedynczych funkcjonalności, w określonych iteracjach lub w bardziej tradycyjny sposób, w formie dużych wydań. Niezależnie od tego, czy kolejne części przyrostowe oprogramowania są udostępniane użytkownikom, w miarę rozrastania się systemu coraz większego znaczenia nabiera testowanie regresji. 
W przeciwieństwie do modeli sekwencyjnych, w modelach iteracyjno-przyrostowych działające oprogramowanie może być dostarczone już w ciągu tygodni, a nawet dni, jednak na spełnienie wszystkich wymagań potrzeba miesięcy, a nawet lat.
Więcej informacji na temat testowania oprogramowania w kontekście modeli wytwarzania zwinnego można znaleźć w [ISTQB® A], a także w [Black 2017], [Crispin 2008], [Gregory 2015] oraz [Roman 2015].
2.1.2. Modele cyklu życia oprogramowania w kontekście Modele cyklu życia oprogramowania należy dobierać i dopasowywać do kontekstu wynikającego z charakterystyki projektu i produktu. W związku z tym w procesie wyboru i dostosowania odpowiedniego do potrzeb projektu modelu należy wziąć pod uwagę: cel projektu, typ wytwarzanego produktu, priorytety biznesowe (takie jak czas wprowadzenia produktu na rynek) i zidentyfikowane czynniki ryzyka produktowego i projektowego. Przykładem może być wytwarzanie i testowanie wewnętrznego systemu administracyjnego o niewielkim znaczeniu, które powinno przebiegać inaczej niż wytwarzanie i testowanie systemu krytycznego ze względów bezpieczeństwa takiego jak układ sterowania hamulcami w samochodzie. Innym przykładem może być sytuacja, w której kwestie organizacyjne i kulturowe mogą utrudniać komunikację pomiędzy członkami zespołu, co może skutkować spowolnieniem wytwarzania oprogramowania w modelu iteracyjnym.
W zależności od kontekstu projektu, konieczne może okazać się połączenie lub reorganizacja niektórych poziomów testów i/lub czynności testowych. W przypadku integracji oprogramowania do powszechnej sprzedaży (ang. Commercial off-the shelf — COTS) z większym systemem nabywca może wykonywać testy współdziałania na poziomie testowania integracji systemów (np. w zakresie integracji z infrastrukturą i innymi systemami) oraz na poziomie testowania akceptacyjnego (testowanie funkcjonalne i niefunkcjonalne wraz z testowaniem akceptacyjnym przez użytkownika i produkcyjnymi testami akceptacyjnymi). Poziomy testów zostały dokładnie opisane  w podrozdziale 2.2., a typy testów – w podrozdziale 2.3.
Różne modele cyklu życia oprogramowania można łączyć ze sobą. Przykładem może być zastosowanie modelu V do wytwarzania i testowania systemów back-endowych i ich integracji oraz modelu zwinnego do wytwarzania i testowania interfejsu użytkownika i funkcjonalności dostępnej dla użytkowników. Innym wariantem łączenia różnych modeli jest zastosowanie modelu prototypowania na wczesnym etapie projektu, a następnie zastąpienie go modelem przyrostowym po zakończeniu fazy eksperymentalnej.
W przypadku systemów związanych z Internetem rzeczy (ang. Internet of Things — IoT), które składają się z wielu różnych obiektów takich jak: urządzenia, produkty i usługi, w odniesieniu do poszczególnych obiektów stosuje się zwykle oddzielne modele cyklu życia. Stanowi to duże wyzwanie — zwłaszcza w zakresie wytwarzania poszczególnych wersji systemów IoT. Ponadto w przypadku powyższych obiektów większy nacisk kładzie się na późniejsze etapy cyklu życia oprogramowania, już po wprowadzeniu obiektów na produkcję (np. na fazy: produkcyjną, aktualizacji i wycofania z użytku).

2.2. Poziomy testów
Poziomy testów to grupy czynności testowych, które organizuje się i którymi zarządza się wspólnie. Każdy poziom testów jest instancją procesu testowego składającą się z czynności opisanych w podrozdziale 1.4., wykonywanych dla oprogramowania na danym poziomie wytwarzania, od pojedynczych modułów lub komponentów, po kompletne systemy lub, jeśli ma to miejsce w danym przypadku, systemy systemów. Poziomy te są powiązane z innymi czynnościami wykonywanymi w ramach cyklu życia oprogramowania. 
Poziomy testów opisane w niniejszym sylabusie to:
• testowanie modułowe;
• testowanie integracyjne;
• testowanie systemowe;
• testowanie akceptacyjne.
 
Każdy poziom testów charakteryzują następujące atrybuty:
• cele szczegółowe;
• podstawa testów (do której należy odwoływać się przy wyprowadzaniu przypadków testowych);
• przedmiot testów (czyli to, co jest testowane);
• typowe defekty i awarie;
• konkretne podejścia i odpowiedzialności.
Każdy poziom testów wymaga odpowiedniego środowiska testowego, np. do testowania akceptacyjnego idealnie nadaje się środowisko testowe podobne do środowiska produkcyjnego, a podczas testowania modułowego programiści zwykle korzystają z własnego środowiska rozwojowego.
2.2.1. Testowanie modułowe Cele testowania modułowego
Testowanie modułowe (zwane także testowaniem jednostkowym, testowaniem komponentów lub testowaniem programu) skupia się na modułach, które można przetestować oddzielnie. Cele tego typu testowania to między innymi: 
• zmniejszanie ryzyka;
• sprawdzanie zgodności zachowań funkcjonalnych i niefunkcjonalnych modułu z projektem i specyfikacjami;
• budowanie zaufania do jakości modułu;
• wykrywanie defektów w module;
• zapobieganie przedostawaniu się defektów na wyższe poziomy testowania.
W niektórych przypadkach — zwłaszcza w przyrostowych i iteracyjnych modelach wytwarzania oprogramowania (np. modelu zwinnym), w których zmiany kodu mają charakter ciągły — automatyczne modułowe testy regresji są kluczowym elementem pozwalającym uzyskać pewność, że wprowadzone zmiany nie spowodowały nieprawidłowej pracy innych, istniejących i działających  już modułów.
Testy modułowe są często wykonywane w izolacji od reszty systemu (zależnie od modelu cyklu życia oprogramowania i konkretnego systemu), przy czym w takiej sytuacji może być konieczne użycie atrap obiektów (ang. mock object), wirtualizacji usług, jarzm testowych, zaślepek bądź sterowników. Testowanie modułowe może obejmować funkcjonalność (np. poprawność obliczeń), parametry niefunkcjonalne (np. wycieki pamięci) oraz właściwości strukturalne (np. testowanie decyzji).
Podstawa testów
Przykładowe produkty pracy, które mogą być wykorzystywane jako podstawa testów w ramach testowania modułowego, to między innymi:
• projekt szczegółowy;
• kod;
• model danych;
• specyfikacje modułów.
Przedmioty testów
Do typowych przedmiotów testów dla testów modułowych zalicza się:
• moduły, jednostki lub komponenty;
• kod i struktury danych;
• klasy;
• moduły baz danych.
Typowe defekty i awarie
Przykładami typowych defektów i awarii wykrywanych w ramach testowania modułowego są:
• niepoprawna funkcjonalność (np. niezgodna ze specyfikacją projektu);
• problemy z przepływem danych;
• niepoprawny kod i logika.
Defekty są zwykle usuwane natychmiast po wykryciu, często bez formalnego procesu zarządzania nimi. Należy jednak zaznaczyć, że zgłaszając defekty, programiści dostarczają ważne informacje na potrzeby analizy przyczyny podstawowej i doskonalenia procesów.
Konkretne podejścia i odpowiedzialności
Testowanie modułowe jest zwykle wykonywane przez programistę będącym autorem kodu, a przynajmniej wymaga dostępu do testowanego kodu. W związku z tym programiści mogą naprzemiennie tworzyć moduły i wykrywać/usuwać defekty. Programiści często piszą i wykonują testy po napisaniu kodu danego modułu. Jednakże, w niektórych przypadkach — zwłaszcza w przypadku zwinnego wytwarzania oprogramowania — automatyczne przypadki testowe do testowania modułowego można również tworzyć przed napisaniem kodu aplikacji. 
Warto w tym miejscu omówić przykład wytwarzania sterowanego testami (ang. Test Driven Development — TDD). Model ten ma charakter wysoce iteracyjny i opiera się na cyklach obejmujących tworzenie automatycznych przypadków testowych, budowanie i integrowanie niewielkich fragmentów kodu, wykonywanie testów modułowych, rozwiązywanie ewentualnych problemów oraz refaktoryzację kodu. Proces ten jest powtarzany do momentu ukończenia modułu i zaliczenia wszystkich testów modułowych. Wytwarzanie sterowane testami jest przykładem podejścia typu „najpierw testuj”. Model ten był pierwotnie stosowany w ramach programowania ekstremalnego (ang. eXtreme Programming — XP), ale upowszechnił się również w innych modelach zwinnych oraz cyklach sekwencyjnych (patrz [ISTQB® AT]).
2.2.2. Testowanie integracyjne Cele testowania integracyjnego
Testowanie integracyjne skupia się na interakcjach między modułami lub systemami. Cele testowania integracyjnego to: 
• zmniejszanie ryzyka;
• sprawdzanie zgodności zachowań funkcjonalnych i niefunkcjonalnych interfejsów z projektem i specyfikacjami;
• budowanie zaufania do jakości interfejsów;
• wykrywanie defektów (które mogą występować w samych interfejsach lub w modułach/systemach);
• zapobieganie przedostawaniu się defektów na wyższe poziomy testowania.
Podobnie jak w przypadku testowania modułowego, istnieją sytuacje w których automatyczne integracyjne testy regresji pozwalają uzyskać pewność, że wprowadzone zmiany nie spowodowały nieprawidłowej pracy dotychczas działających interfejsów, modułów lub systemów.
W niniejszym sylabusie opisano dwa różne poziomy testowania integracyjnego, które mogą być wykonywane w odniesieniu do przedmiotów testów różnej wielkości:
• Testowanie integracji modułów skupia się na interakcjach i interfejsach między integrowanymi modułami. Testy tego typu wykonuje się po zakończeniu testowania modułowego (zwykle są to testy automatyczne). W przypadku iteracyjnego i przyrostowego modelu wytwarzania oprogramowania testy integracji modułów są zwykle elementem procesu ciągłej integracji.
• Testowanie integracji systemów skupia się na interakcjach i interfejsach między systemami, pakietami i mikrousługami. Testy tego typu mogą również obejmować interakcje z interfejsami dostarczanymi przez organizacje zewnętrzne (np. dostawców usług internetowych — ang. Web Services). W takim przypadku organizacja wytwarzająca oprogramowanie nie kontroluje interfejsów zewnętrznych, co może stwarzać wiele problemów w obszarze testowania (związanych np. z usuwaniem defektów w kodzie tworzonym przez organizację zewnętrzną, które blokują testowanie, bądź z przygotowywaniem środowisk testowych). Testowanie integracji systemów może odbywać się po zakończeniu testowania systemowego lub równolegle do trwającego testowania systemowego (dotyczy to zarówno sekwencyjnego, jak i przyrostowego wytwarzania oprogramowania).
Podstawa testów
Przykładowe produkty pracy, które mogą być wykorzystywane jako podstawa testów w ramach testowania integracyjnego, to między innymi:
• projekt oprogramowania i systemu;
• diagramy sekwencji;
• specyfikacje interfejsów;
• przypadki użycia;
• architektura na poziomie modułów i systemu;
• przepływy pracy;
• definicje interfejsów zewnętrznych.
Przedmioty testów
Do typowych przedmiotów testów zalicza się:
• podsystemy;
• bazy danych;
• infrastrukturę;
• interfejsy;
• interfejsy programowania aplikacji (ang. Application Programming Interface — API);
• mikrousługi.
Typowe defekty i awarie
Przykładami typowych defektów i awarii wykrywanych w ramach testowania integracji modułów są:
• niepoprawne lub brakujące dane bądź niepoprawne kodowanie danych;
• niepoprawne uszeregowanie lub niepoprawna synchronizacja wywołań interfejsów;
• niezgodności interfejsów;
• błędy komunikacji między modułami;
• brak obsługi lub nieprawidłowa obsługa błędów komunikacji między modułami;
• niepoprawne założenia dotyczące znaczenia, jednostek lub granic danych przesyłanych między modułami.
Przykładami typowych defektów i awarii wykrywanych w ramach testowania integracji systemów są:
• niespójne struktury komunikatów przesyłanych między systemami;
• niepoprawne lub brakujące dane bądź niepoprawne kodowanie danych;
• niezgodność interfejsów;
• błędy komunikacji między systemami;
• brak obsługi lub nieprawidłowa obsługa błędów komunikacji między systemami;
• niepoprawne założenia dotyczące znaczenia, jednostek lub granic danych przesyłanych między systemami;
• nieprzestrzeganie rygorystycznych, obowiązujących przepisów dotyczących zabezpieczeń.
Konkretne podejścia i odpowiedzialności
Testowanie integracji modułów i testowanie integracji systemów powinno koncentrować się na samej integracji. Przykładem takiego podejścia jest integrowanie modułu A z modułem B, podczas którego testy powinny skupiać się na komunikacji między tymi modułami, a nie na funkcjonalności każdego z nich (funkcjonalność ta powinna być przedmiotem testowania modułowego). Analogicznie w przypadku integrowania systemu X z systemem Y testerzy powinni skupiać się na komunikacji między tymi systemami, a nie na funkcjonalności każdego z nich (funkcjonalność ta powinna być przedmiotem testowania systemowego). Na tym poziomie można przeprowadzać testy funkcjonalne, niefunkcjonalne i strukturalne.
Testowanie integracji modułów jest często obowiązkiem programistów, natomiast za testowanie integracji systemów zwykle odpowiadają testerzy. O ile jest to możliwe, testerzy wykonujący testowanie integracji systemów powinni znać architekturę systemu, a ich spostrzeżenia  powinny być brane pod uwagę na etapie planowania integracji.
Zaplanowanie testów integracyjnych i strategii integracji przed zbudowaniem modułów lub systemów umożliwia wytworzenie tych modułów lub systemów w sposób zapewniający maksymalną efektywność testowania. Usystematyzowane strategie integracji mogą być oparte na architekturze systemu (np. strategie zstępujące lub wstępujące), zadaniach funkcjonalnych, sekwencjach przetwarzania transakcji bądź innych aspektach systemu lub modułów. Aby uprościć lokalizowanie defektów i umożliwić ich wczesne wykrywanie, integrację należy przeprowadzać metodą przyrostową (np. niewielka liczba jednocześnie dodawanych komponentów lub systemów). Nie zaleca się integracji metodą „wielkiego wybuchu”, polegającą na zintegrowaniu wszystkich modułów lub systemów naraz. W odpowiednim ukierunkowaniu testowania integracyjnego może również pomóc analiza ryzyka związanego z najbardziej złożonymi interfejsami.
Im szerszy jest zakres integracji, tym trudniej jest wskazać konkretny moduł lub system, w którym wystąpiły defekty, co może prowadzić do wzrostu ryzyka i wydłużenia czasu diagnozowania problemów. Jest to jeden z powodów, dla których powszechnie stosuje się metodę ciągłej integracji, polegającą na integrowaniu oprogramowania moduł po module (np. integracja funkcjonalna). Elementem ciągłej integracji jest często automatyczne testowanie regresji, które w miarę możliwości powinno odbywać się na wielu poziomach testów.
2.2.3. Testowanie systemowe Cele testowania systemowego
Testowanie systemowe skupia się na zachowaniu i możliwościach całego systemu lub produktu, często z uwzględnieniem całokształtu zadań, jakie może on wykonywać oraz zachowań niefunkcjonalnych, jakie można stwierdzić podczas wykonywania tych zadań. Cele testowania systemowego to między innymi: 
• zmniejszanie ryzyka;
• sprawdzanie zgodności zachowań funkcjonalnych i niefunkcjonalnych systemu z projektem i specyfikacjami;
• sprawdzanie kompletności systemu i prawidłowości jego działania;
• budowanie zaufania do jakości systemu jako całości;
• wykrywanie defektów;
• zapobieganie przedostawaniu się defektów na poziom testowania akceptacyjnego lub na produkcję.
W przypadku niektórych systemów celem testowania może być również zweryfikowanie jakości danych. Podobnie jak w przypadku testowania modułowego i testowania integracyjnego, automatyczne, systemowe testy regresji pozwalają uzyskać pewność, że wprowadzone zmiany nie spowodowały nieprawidłowego działania dotychczasowych funkcji lub całościowej funkcjonalności. Często spotykanym rezultatem testowania systemowego są dane i informacje, na podstawie których interesariusze podejmują decyzje o przekazaniu systemu do użycia produkcyjnego. Ponadto testowanie systemowe może być niezbędne do spełnienia wymagań wynikających z obowiązujących przepisów prawa lub norm/standardów.
Środowisko testowe powinno w miarę możliwości odzwierciedlać specyfikę środowiska docelowego lub produkcyjnego.
Podstawa testów
Przykładowe produkty pracy, które mogą być wykorzystywane jako podstawa testów w ramach testowania systemowego, to między innymi:
• specyfikacje wymagań (funkcjonalnych i niefunkcjonalnych) dotyczących systemu i oprogramowania;
• raporty z analizy ryzyka;
• przypadki użycia;
• opowieści i historyjki użytkownika;
• modele zachowania systemu;
• diagramy stanów;
• instrukcje obsługi systemu i podręczniki użytkownika.
Przedmioty testów
Do typowych przedmiotów testów dla testów systemowych zalicza się:
• aplikacje;
• systemy łączące sprzęt i oprogramowanie;
• systemy operacyjne;
• system podlegający testowaniu;
• konfiguracja i dane konfiguracyjne systemu.
Typowe defekty i awarie
Przykładami typowych defektów i awarii wykrywanych w ramach testowania systemowego są:
• niepoprawne obliczenia;
• niepoprawne lub nieoczekiwane zachowania funkcjonalne lub niefunkcjonalne systemu;
• niepoprawne przepływy sterowania i/lub przepływy danych w systemie;
• problemy z prawidłowym i kompletnym wykonywaniem całościowych zadań funkcjonalnych;
• problemy z prawidłowym działaniem systemu w środowisku produkcyjnym;
• niezgodność działania systemu z opisami zawartymi w instrukcji obsługi systemu i podręcznikach użytkownika.
 
Konkretne podejścia i odpowiedzialności
Testowanie systemowe powinno koncentrować się na kompleksowym zbadaniu zachowania  systemu jako całości na poziomie zarówno funkcjonalnym, jak i niefunkcjonalnym. W ramach testowania systemowego należy stosować techniki (patrz rozdział 4.), które są najbardziej odpowiednie dla danego aspektu (danych aspektów) systemu będącego przedmiotem testów. W celu sprawdzenia, czy zachowanie funkcjonalne jest zgodne z opisem zawartym w regułach biznesowych, można wykorzystać np. tablicę decyzyjną.
Testowanie systemowe wykonują zwykle niezależni testerzy. Defekty w specyfikacjach (np. brakujące historyjki użytkownika lub niepoprawnie zdefiniowane wymagania biznesowe) mogą doprowadzić do nieporozumień lub sporów dotyczących oczekiwanego zachowania systemu. Wyniki testów mogą więc zostać zaklasyfikowane jako rezultaty fałszywie pozytywne lub fałszywie negatywne, a sugerowanie się nimi może spowodować odpowiednio stratę czasu lub spadek skuteczności wykrywania defektów. 
Między innymi dlatego (aby zmniejszyć częstość występowania powyższych sytuacji) należy zaangażować testerów w przeglądy, doprecyzowywanie historyjek użytkownika i inne czynności testowe o charakterze statycznym na jak najwcześniejszym etapie prac.
 
2.2.4. Testowanie akceptacyjne Cele testowania akceptacyjnego
Testowanie akceptacyjne — podobnie jak testowanie systemowe — skupia się zwykle na zachowaniu i możliwościach całego systemu lub produktu. Cele testowania akceptacyjnego to najczęściej: 
• budowanie zaufania do systemu;
• sprawdzanie kompletności systemu i jego prawidłowego działania;
• sprawdzanie zgodności zachowania funkcjonalnego i niefunkcjonalnego systemu ze specyfikacją.
W wyniku testowania akceptacyjnego mogą powstawać informacje pozwalające ocenić gotowość systemu do wdrożenia i użytkowania przez klienta (użytkownika). Podczas testowania akceptacyjnego mogą też zostać wykryte defekty, ale ich wykrywanie często nie jest celem tego poziomu testów (w niektórych przypadkach znalezienie dużej liczby defektów na etapie testowania akceptacyjnego może być nawet uznawane za istotny czynnik ryzyka projektowego). Ponadto testowanie akceptacyjne może być niezbędne do spełnienia wymagań wynikających z obowiązujących przepisów prawa lub norm/standardów.
Najczęściej występujące formy testowania akceptacyjnego to:
• testowanie akceptacyjne przez użytkownika;
• produkcyjne testy akceptacyjne;
• testowanie akceptacyjne zgodności z umową i zgodności z przepisami prawa;
• testowanie alfa i beta.
Formy testowania akceptacyjnego opisano w kolejnych czterech podpunktach.
 
Testowanie akceptacyjne przez użytkownika
Testowanie akceptacyjne systemu przez użytkownika odbywa się w (symulowanym) środowisku produkcyjnym i skupia się zwykle na sprawdzeniu, czy system nadaje się do użytkowania przez przyszłych odbiorców. Głównym celem jest tu budowanie pewności, że system umożliwi użytkownikom spełnienie ich potrzeb, postawionych przed nim wymagań i wykona proces biznesowy z minimalną liczbą problemów, minimalnymi kosztem i ryzykiem.
Produkcyjne testy akceptacyjne
Testowanie akceptacyjne systemu przez operatorów lub administratorów odbywa się zwykle w (symulowanym) środowisku produkcyjnym. Testy skupiają się na aspektach operacyjnych i mogą obejmować:
• testowanie mechanizmów tworzenia kopii zapasowych i odtwarzania danych;
• instalowanie, odinstalowywanie i aktualizowanie oprogramowania;
• usuwanie skutków awarii;
• zarządzanie użytkownikami;
• wykonywanie czynności pielęgnacyjnych;
• wykonywanie czynności związanych z ładowaniem i migracją danych;
• sprawdzanie, czy występują podatności zabezpieczeń;
• wykonywanie testów wydajnościowych.
Głównym celem produkcyjnych testów akceptacyjnych jest uzyskanie pewności, że operatorzy lub administratorzy systemu będą w stanie zapewnić użytkownikom prawidłową pracę systemu w środowisku produkcyjnym, nawet w wyjątkowych i trudnych warunkach.
Testowanie akceptacyjne zgodności z umową i zgodności z przepisami prawa 
Testowanie akceptacyjne zgodności z umową odbywa się zgodnie z kryteriami akceptacji zapisanymi w umowie dotyczącej wytworzenia oprogramowania na zlecenie. Powyższe kryteria akceptacji powinny zostać określone w momencie uzgadniania przez strony treści umowy. Tego rodzaju testowanie akceptacyjne wykonują często użytkownicy lub niezależni testerzy.
Testowanie akceptacyjne zgodności z przepisami prawa jest wykonywane w kontekście obowiązujących aktów prawnych, takich jak: ustawy, rozporządzenia czy normy bezpieczeństwa. Tego rodzaju testowanie akceptacyjne często wykonują użytkownicy lub niezależni testerzy, a rezultaty mogą być obserwowane lub kontrolowane przez organy nadzoru.
Głównym celem testowania akceptacyjnego zgodności z umową i zgodności z przepisami prawa  jest uzyskanie pewności, że osiągnięto zgodność z wymaganiami wynikającymi z obowiązujących umów lub regulacji. 
Testowanie alfa i beta
Twórcy oprogramowania przeznaczonego do powszechnej sprzedaży (COTS) często chcą uzyskać informacje zwrotne od potencjalnych lub obecnych klientów, zanim oprogramowanie trafi na rynek. Służą do tego testy alfa i beta. 
Testowanie alfa jest wykonywane w siedzibie organizacji wytwarzającej oprogramowanie, ale zamiast zespołu wytwórczego testy wykonują potencjalni lub obecni klienci, i/lub operatorzy bądź niezależni testerzy. Z kolei testowanie beta wykonują obecni lub potencjalni klienci we własnych lokalizacjach. Testy beta mogą być, ale nie muszą, poprzedzone testami alfa.
Jednym z celów testów alfa i beta jest budowanie zaufania potencjalnych i aktualnych klientów i/lub operatorów w kwestii korzystania z systemu w normalnych warunkach, w środowisku produkcyjnym, aby osiągnąć swoje cele wkładając w to minimalny wysiłek, koszt i ryzyko. Innym celem tych testów może być wykrywanie błędów związanych z warunkami i środowiskiem (środowiskami), w których system będzie używany, szczególnie wtedy, gdy takie warunki są trudne do odtworzenia dla zespołu projektowego.
Podstawa testów
Przykładowe produkty pracy, które mogą być wykorzystywane jako podstawa testów w ramach dowolnego typu testowania akceptacyjnego, to między innymi:
• procesy biznesowe;
• wymagania użytkowników lub wymagania biznesowe;
• przepisy, umowy, normy i standardy;
• przypadki użycia;
• wymagania systemowe;
• dokumentacja systemu lub podręczniki dla użytkowników;
• procedury instalacji;
• raporty z analizy ryzyka.
Ponadto podstawę testów, z której wyprowadzane są przypadki testowe na potrzeby produkcyjnych testów akceptacyjnych, mogą stanowić następujące produkty pracy:
• procedury tworzenia kopii zapasowych i odtwarzania danych;
• procedury usuwania skutków awarii;
• wymagania niefunkcjonalne;
• dokumentacja operacyjna;
• instrukcje wdrażania i instalacji;
• założenia wydajnościowe;
• pakiety bazodanowe;
• normy, standardy lub przepisy w dziedzinie zabezpieczeń.
Typowe przedmioty testów
Do typowych przedmiotów testów dowolnego typu testów akceptacyjnych zalicza się:
• system podlegający testowaniu;
• konfiguracja i dane konfiguracyjne systemu;
• procesy biznesowe wykonywane na całkowicie zintegrowanym systemie;
• systemy rezerwowe i ośrodki zastępcze (ang. hot site) służące do testowania mechanizmów zapewnienia ciągłości biznesowej i usuwania skutków awarii;
• procesy związane z użyciem produkcyjnym i utrzymaniem;
• formularze;
• raporty;
• istniejące i skonwertowane dane produkcyjne.
Typowe defekty i awarie
Przykładami typowych defektów wykrywanych w ramach różnych typów testowania akceptacyjnego są:
• systemowe przepływy pracy niezgodne z wymaganiami biznesowymi lub wymaganiami użytkowników;
• niepoprawnie zaimplementowane reguły biznesowe;
• niespełnienie przez system wymagań umownych lub prawnych;
• awarie niefunkcjonalne, takie jak podatności zabezpieczeń, niedostateczna wydajność pod dużym obciążeniem bądź nieprawidłowe działanie na obsługiwanej platformie.
 
Konkretne podejścia i obowiązki
Testowanie akceptacyjne często spoczywa na klientach, użytkownikach biznesowych, właścicielach produktów lub operatorach systemów, ale w proces ten mogą być również zaangażowani inni interesariusze. Testowanie akceptacyjne zazwyczaj uznaje się za ostatni poziom sekwencyjnego cyklu życia oprogramowania, ale może ono również odbywać się na innych jego etapach, np.:
• testowanie akceptacyjne oprogramowania „do powszechnej sprzedaży” może odbywać się podczas jego instalowania lub integrowania;
• testowanie akceptacyjne nowego udoskonalenia funkcjonalnego może mieć miejsce przed rozpoczęciem testowania systemowego.
W iteracyjnych modelach wytwarzania oprogramowania zespoły projektowe mogą stosować na zakończenie każdej iteracji różne formy testowania akceptacyjnego, takie jak testy skupiające się na weryfikacji zgodności nowej funkcjonalności z kryteriami akceptacji bądź testy skupiające się na walidacji nowej funkcjonalności z punktu widzenia potrzeb użytkowników. Ponadto na końcu każdej iteracji, po ukończeniu każdej iteracji lub po wykonaniu serii iteracji, mogą być wykonywane testy alfa i beta, a także testy akceptacyjne wykonywane przez użytkownika, produkcyjne testy akceptacyjne oraz testy akceptacyjne zgodności z umową i zgodności z przepisami prawa.

2.3. Typy testów
Typ testów to grupa dynamicznych czynności testowych wykonywanych z myślą o przetestowaniu określonych charakterystyk systemu/oprogramowania (lub jego części) zgodnie z określonymi celami testów. Celem testów może być między innymi:
• ocena funkcjonalnych charakterystyk jakościowych takich jak: kompletność, prawidłowość i adekwatność;
• dokonanie oceny niefunkcjonalnych charakterystyk jakościowych, w tym parametrów takich jak: niezawodność, wydajność, bezpieczeństwo, kompatybilność czy też użyteczność;
• ustalenie, czy struktura lub architektura komponentu lub systemu jest poprawna, kompletna i zgodna ze specyfikacjami;
• dokonanie oceny skutków zmian, np. potwierdzenie usunięcia defektów (testowanie potwierdzające) lub wyszukanie niezamierzonych zmian w sposobie działania wynikających z modyfikacji oprogramowania lub środowisku (testowanie regresji).
2.3.1. Testowanie funkcjonalne Testowanie funkcjonalne systemu polega na wykonaniu testów, które umożliwiają dokonanie oceny funkcji, jakie system ten powinien realizować. Wymagania funkcjonalne mogą być opisane w produktach pracy takich jak: specyfikacje wymagań biznesowych, opowieści, historyjki użytkownika, przypadki użycia lub specyfikacje funkcjonalne, ale zdarza się również, że występują one w postaci nieudokumentowanej. Funkcje opisują to, „co” powinien robić dany system.
Testy funkcjonalne należy wykonywać na wszystkich poziomach testów (np. testy dotyczące modułów mogą opierać się na specyfikacjach modułów), jednakże z zastrzeżeniem, że testy wykonywane na poszczególnych poziomach skupiają się na różnych zagadnieniach (patrz podrozdział 2.2.).
Testowanie funkcjonalne uwzględnia zachowanie oprogramowania, w związku z czym do wyprowadzania warunków testowych i przypadków testowych dotyczących funkcjonalności komponentu lub systemu można używać technik czarnoskrzynkowych (patrz podrozdział 4.2.).
Staranność testowania funkcjonalnego można zmierzyć na podstawie pokrycia funkcjonalnego. Termin „pokrycie funkcjonalne” oznacza stopień, w jakim został przetestowany określony typ elementu funkcjonalnego, wyrażony jako procent elementów danego typu pokrytych przez testy. Dzięki możliwości śledzenia powiązań między testami a wymaganiami funkcjonalnymi można na przykład obliczyć, jaki procent wymagań został uwzględniony w ramach testowania, a w rezultacie zidentyfikować ewentualne luki w pokryciu.
Do projektowania i wykonywania testów funkcjonalnych mogą być potrzebne specjalne umiejętności lub specjalna wiedza taka jak znajomość konkretnego problemu biznesowego rozwiązywanego przy pomocy danego oprogramowana (np. oprogramowania do modelowania geologicznego dla przemysłu naftowego i gazowego) bądź konkretnej roli, jaką spełnia dane oprogramowanie (np. gra komputerowa zapewniająca interaktywną rozrywkę).
2.3.2. Testowanie niefunkcjonalne Celem testowania niefunkcjonalnego jest dokonanie oceny charakterystyk systemów i oprogramowania, takich jak: użyteczność, wydajność, bezpieczeństwo itd. Klasyfikację charakterystyk jakościowych oprogramowania zawiera standard ISO/IEC 25010. Testowanie niefunkcjonalne pozwala sprawdzić to, „jak dobrze” zachowuje się dany system. 
Wbrew mylnemu przekonaniu testowanie niefunkcjonalne można i często należy wykonywać na wszystkich poziomach testów. Ponadto powinno ono odbywać się na jak najwcześniejszym etapie, ponieważ zbyt późne wykrycie defektów niefunkcjonalnych może być bardzo dużym zagrożeniem dla powodzenia projektu.
Do wyprowadzania warunków testowych i przypadków testowych na potrzeby testowania niefunkcjonalnego można używać technik czarnoskrzynkowych (patrz podrozdział 4.2.). Przykładem może być zastosowanie analizy wartości brzegowych do zdefiniowania warunków skrajnych dotyczących testów wydajnościowych.
Staranność testowania niefunkcjonalnego można zmierzyć na podstawie pokrycia niefunkcjonalnego. Termin „pokrycie niefunkcjonalne” oznacza stopień, w jakim został przetestowany określony typ elementu niefunkcjonalnego, wyrażony jako procent elementów danego typu pokrytych przez testy. Dzięki możliwości śledzenia powiązań między testami a typami urządzeń obsługiwanych przez aplikację mobilną można na przykład obliczyć, jaki procent urządzeń został uwzględniony w ramach testowania kompatybilności, a w rezultacie zidentyfikować ewentualne luki w pokryciu.
Do projektowania i wykonywania testów niefunkcjonalnych mogą być potrzebne specjalne umiejętności lub specjalna wiedza — taka jak znajomość słabych punktów charakterystycznych dla danego projektu lub danej technologii (np. podatności zabezpieczeń związanych z określonymi językami programowania) bądź konkretnej grupy użytkowników (np. profili użytkowników systemów do zarządzania placówkami opieki zdrowotnej).
Szczegółowe informacje na temat testowania niefunkcjonalnych charakterystyk jakościowych zawierają sylabusy [ISTQB® ATA], [ISTQB® ATTA], [ISTQB® SEC] i inne specjalistyczne moduły ISTQB®.
2.3.3. Testowanie białoskrzynkowe W przypadku testowania białoskrzynkowego warunki testowe wyprowadza się na podstawie struktury wewnętrznej lub implementacji danego systemu. Struktura wewnętrzna może obejmować kod, architekturę, przepływy pracy i/lub przepływy danych w obrębie systemu (patrz podrozdział 4.3.).
Staranność testowania białoskrzynkowego można zmierzyć na podstawie pokrycia strukturalnego. Termin „pokrycie strukturalne” oznacza stopień, w jakim został przetestowany określony typ elementu strukturalnego, wyrażony jako procent elementów danego typu pokrytych przez testy.
Na poziomie testowania modułów pokrycie kodu określa się na podstawie procentowej części kodu danego modułu, która została przetestowana. Wartość tę można mierzyć w kategoriach różnych aspektów kodu (przedmiotów pokrycia), takich jak procent instrukcji wykonywalnych lub procent wyników decyzji przetestowanych w danym module. Powyższe rodzaje pokrycia nazywa się zbiorczo pokryciem kodu. Na poziomie testowania integracji modułów, testowanie białoskrzynkowe może odbywać się na podstawie architektury systemu (np. interfejsów między modułami), a pokrycie strukturalne może być mierzone w kategoriach procentowego udziału przetestowanych interfejsów.
Do projektowania i wykonywania testów białoskrzynkowych mogą być potrzebne specjalne umiejętności lub specjalna wiedza, np.: znajomość struktury kodu (umożliwiająca np. użycie narzędzi do pomiaru pokrycia kodu), wiedza o sposobie przechowywania danych (pozwalająca np. ocenić zapytania do baz danych) bądź sposób korzystania z narzędzi do pomiaru pokrycia i poprawnego interpretowania generowanych przez nie rezultatów.
2.3.4. Testowanie związane ze zmianami Po wprowadzeniu w systemie zmian mających na celu usunięcie defektów bądź dodanie lub zmodyfikowanie funkcjonalności należy przeprowadzić testy, które potwierdzą, że wprowadzone zmiany faktycznie skutkowały naprawieniem defektu lub poprawną  implementacją odpowiedniej funkcjonalności, a przy tym nie wywołały żadnych nieprzewidzianych, niekorzystnych zachowań oprogramowania.
• Testowanie potwierdzające. Po naprawieniu defektu można przetestować oprogramowanie przy użyciu wszystkich przypadków testowych, które wcześniej nie zostały zaliczone z powodu wystąpienia tego defektu, a powinny zostać ponownie wykonane w nowej wersji oprogramowania. Oprogramowanie może być również testowane nowymi testami, jeśli na przykład defektem była brakująca funkcjonalność. Absolutnym minimum jest ponowne wykonanie w nowej wersji oprogramowania kroków niezbędnych do odtworzenia awarii wywoływanej przez dany defekt. Celem testu potwierdzającego jest sprawdzenie, czy pierwotny defekt został pomyślnie usunięty.
• Testowanie regresji. Istnieje ryzyko, że zmiana (poprawka lub inna modyfikacja) wprowadzona w jednej części kodu wpłynie przypadkowo na zachowanie innych części kodu w tym samym module, w innych modułach tego samego systemu, a nawet w innych systemach. Ponadto należy wziąć pod uwagę zmiany dotyczące środowiska, takie jak wprowadzenie nowej wersji systemu operacyjnego lub systemu zarządzania bazami danych. Powyższe, niezamierzone skutki uboczne, są nazywane regresjami, a testowanie regresji polega na ponownym wykonaniu testów w celu ich wykrycia.
Testowanie potwierdzające i testowanie regresji można wykonywać na wszystkich poziomach testów.
Zwłaszcza w iteracyjnych i przyrostowych modelach wytwarzania oprogramowania (np. w modelu zwinnym) nowe funkcjonalności, zmiany dotychczasowych funkcjonalności oraz refaktoryzacja powodują częste zmiany kodu, które pociągają za sobą konieczność przeprowadzenia odpowiednich testów. Z uwagi na ciągłą ewolucję systemu, testowanie potwierdzające i testowanie regresji są bardzo istotne, szczególnie w przypadku systemów związanych z Internetem rzeczy (IoT), w których poszczególne obiekty (np. urządzenia) są często aktualizowane lub wymieniane.
Zestawy testów regresji są wykonywane wielokrotnie i zwykle ewoluują dość wolno, w związku z czym testowanie regresji świetnie nadaje się do automatyzacji – dlatego też automatyzację tego rodzaju testów należy rozpocząć w początkowym etapie projektu (patrz rozdział 6.).
2.3.5. Poziomy testów a typy testów Każdy z wymienionych powyżej typów testów można wykonywać na dowolnym poziomie testów. Aby zilustrować tę prawidłowość, poniżej przedstawiono przykłady testów funkcjonalnych, niefunkcjonalnych i białoskrzynkowych oraz testów związanych ze zmianami, które są wykonywane na wszystkich poziomach testów w odniesieniu do aplikacji bankowej. Poniżej podano przykłady testów funkcjonalnych wykonywanych na różnych poziomach testów:
• na potrzeby testowania modułowego projektowane są testy odzwierciedlające sposób, w jaki dany moduł powinien obliczać odsetki składane;
• na potrzeby testowania integracji modułów projektowane są testy odzwierciedlające sposób, w jaki informacje na temat konta pozyskane poprzez  interfejs użytkownika są przekazywane do warstwy logiki biznesowej;
• na potrzeby testowania systemowego projektowane są testy odzwierciedlające sposób, w jaki posiadacze rachunków mogą składać wnioski o przyznanie linii kredytowej na rachunku bieżącym;
• na potrzeby testowania integracji systemów projektowane są testy odzwierciedlające sposób, w jaki dany system sprawdza zdolność kredytową posiadacza rachunku przy użyciu zewnętrznej mikrousługi;
• na potrzeby testowania akceptacyjnego projektowane są testy odzwierciedlające sposób, w jaki pracownik banku zatwierdza lub odrzuca wniosek kredytowy.
Poniżej opisano  przykłady testów niefunkcjonalnych przeprowadzanych na różnych poziomach testów:
• na potrzeby testowania modułowego projektowane są testy wydajnościowe, które umożliwiają ocenę liczbę cykli procesora niezbędnych do wykonania złożonych obliczeń dotyczących łącznej kwoty odsetek;
• na potrzeby testowania integracji modułów projektowane są testy zabezpieczeń, które mają na celu wykrycie podatności zabezpieczeń związanych z przepełnieniem bufora danymi przekazywanymi z interfejsu użytkownika do warstwy logiki biznesowej;
• na potrzeby testowania systemowego projektowane są testy przenaszalności, które umożliwiają sprawdzenie, czy warstwa prezentacji działa we wszystkich obsługiwanych przeglądarkach i urządzeniach przenośnych;
• na potrzeby testowania integracji systemów projektowane są testy niezawodności, które pozwalają na dokonanie oceny odporności systemu w przypadku braku odpowiedzi ze strony mikrousługi służącej do sprawdzania zdolności kredytowej;
• na potrzeby testowania akceptacyjnego projektowane są testy użyteczności, które pozwalają ocenić ułatwienia dostępu dla osób niepełnosprawnych zastosowane w interfejsie do przetwarzania kredytów po stronie banku.
Kolejna grupa zawiera przykłady testów białoskrzynkowych przeprowadzanych na różnych poziomach testów:
• na potrzeby testowania modułowego projektowane są testy, których celem jest zapewnienie pełnego pokrycia instrukcji kodu i decyzji (patrz podrozdział 4.3.) we wszystkich modułach wykonujących obliczenia finansowe;
• na potrzeby testowania integracji modułów projektowane są testy, które umożliwiają sprawdzenie, w jaki sposób każdy ekran interfejsu wyświetlanego w przeglądarce przekazuje dane prezentowane na następnym ekranie oraz do warstwy logiki biznesowej;
• na potrzeby testowania systemowego projektowane są testy, których celem jest zapewnienie pokrycia możliwych sekwencji stron internetowych wyświetlanych podczas składania wniosku o przyznanie linii kredytowej;
• na potrzeby testowania integracji systemów projektowane są testy, których celem jest sprawdzenie wszystkich możliwych typów zapytań wysyłanych do mikrousługi służącej do sprawdzania zdolności kredytowej;
• na potrzeby testowania akceptacyjnego projektowane są testy, których celem jest pokrycie wszystkich obsługiwanych struktur i zakresów wartości dla plików z danymi finansowymi używanych w przelewach międzybankowych.
Ostatnia grupa zawiera przykłady testów związanych ze zmianami przeprowadzanych na różnych poziomach testów: 
• na potrzeby testowania modułowego projektowane są automatyczne testy regresji dotyczące poszczególnych modułów (testy te zostaną następnie uwzględnione w strukturze ciągłej integracji);
• na potrzeby testowania integracji modułów projektowane są testy służące do potwierdzania skuteczności wprowadzonych poprawek związanych z defektami w interfejsach, w miarę umieszczania takich poprawek w repozytorium kodu;
• na potrzeby testowania systemowego ponownie wykonywane są wszystkie testy dotyczące danego przepływu pracy, jeśli dane czy sposób ich prezentacji na którymkolwiek z ekranów objętych tym przepływem pracy uległ zmianie;
• na potrzeby testowania integracji systemów codziennie wykonywane są ponownie testy aplikacji współpracującej z mikrousługą do sprawdzania zdolności kredytowej (w ramach ciągłego wdrażania tej mikrousługi);
• na potrzeby testowania akceptacyjnego wszystkie wcześniej niezaliczone testy są wykonywane ponownie (po usunięciu defektu wykrytego w ramach testowania akceptacyjnego).
Powyżej przedstawiono przykłady wszystkich typów testów wykonywanych na wszystkich poziomach testów, jednak nie każde oprogramowanie wymaga uwzględnienia każdego typu testów na każdym poziomie. Ważne jest to, aby na poszczególnych poziomach zostały wykonane odpowiednie testy — dotyczy to zwłaszcza pierwszego z poziomów testów, na jakim występuje dany typ testów.

2.4. Testowanie pielęgnacyjne
Po wdrożeniu w środowisku produkcyjnym oprogramowanie lub system wymaga dalszej pielęgnacji. Różnego rodzaju zmiany — związane np. z usuwaniem defektów wykrytych podczas użytkowania produkcyjnego, dodaniem nowej funkcjonalności bądź usuwaniem lub modyfikowaniem funkcjonalności już istniejącej — są praktycznie nieuniknione. Ponadto pielęgnacja jest niezbędna do utrzymania lub poprawy wymaganych niefunkcjonalnych charakterystyk jakościowych oprogramowania lub systemu przez cały cykl jego życia — zwłaszcza w zakresie takich parametrów jak: wydajność, kompatybilność, niezawodność, bezpieczeństwo i przenaszalność.
Po dokonaniu każdej zmiany w fazie pielęgnacji, należy wykonać testowanie pielęgnacyjne, którego celem jest zarówno sprawdzenie, czy zmiana została wprowadzona pomyślnie, jak i wykrycie ewentualnych, niezamierzonych skutków ubocznych (np. regresji) w niezmienionych częściach systemu (czyli zwykle w większości jego obszarów). Testowanie pielęgnacyjne obejmuje więc zarówno te części systemu, które zostały zmienione, jak i części niezmienione, na które zmiany mogły mieć wpływ. Pielęgnacja może być wykonywana zarówno planowo (w związku z nowymi wersjami), jak i w sposób niezaplanowany (w związku z poprawkami doraźnymi — ang. hotfix).
Wydanie pielęgnacyjne może wymagać wykonania testów pielęgnacyjnych na wielu poziomach testów i z wykorzystaniem różnych typów testów — zależnie od zakresu wprowadzonych zmian. Na zakres testowania pielęgnacyjnego wpływają między innymi:
• poziom ryzyka związanego ze zmianą (np. stopień, w jakim zmieniony obszar oprogramowania komunikuje się z innymi modułami lub systemami);
• wielkość dotychczasowego systemu;
• wielkość wprowadzonej zmiany.
2.4.1. Zdarzenia wywołujące pielęgnację Istnieje kilka powodów, dla których wykonuje się pielęgnację oprogramowania, a tym samym testowanie pielęgnacyjne. Dotyczy to zarówno zmian planowanych, jak i nieplanowanych.
Zdarzenia wywołujące pielęgnację można podzielić na następujące kategorie:
• Modyfikacja. Ta kategoria obejmuje między innymi: zaplanowane udoskonalenia (np. w postaci nowych wersji oprogramowania), zmiany korekcyjne i awaryjne, zmiany środowiska operacyjnego (np. planowe uaktualnienia systemu operacyjnego lub bazy danych), uaktualnienia oprogramowania do powszechnej sprzedaży (COTS)  oraz poprawki usuwające defekty i podatności zabezpieczeń.
• Migracja. Ta kategoria obejmuje między innymi przejście z jednej platformy na inną, co może wiązać się z koniecznością przeprowadzenia testów produkcyjnych nowego środowiska i zmienionego oprogramowania bądź testów konwersji danych (w przypadku migracji danych z innej aplikacji do pielęgnowanego systemu).
• Wycofanie. Ta kategoria dotyczy sytuacji, w której aplikacja jest wycofywana z użytku.
Kiedy aplikacja lub system jest wycofywany, może to wymagać testowania migracji lub archiwizacji danych, jeśli zachodzi potrzeba ich przechowywania przez dłuższy czas. Testowanie procedur odzyskiwania/pozyskiwania zarchiwizowanych danych przez dłuższy czas może także być konieczne. Dodatkowo nieodzowne może być uwzględnienie testów regresji, aby zapewnić dalszą prawidłową pracę funkcjonalności pozostających w użyciu.
W przypadku systemów związanych z Internetem rzeczy (IoT – Internet of Things) testowanie pielęgnacyjne może być konieczne po wprowadzeniu w systemie zupełnie nowych lub zmodyfikowanych elementów, takich jak urządzenia sprzętowe czy usługi programowe. Podczas testowania pielęgnacyjnego tego typu systemów szczególny nacisk kładzie się na testowanie integracyjne na różnych poziomach (np. na poziomie sieci i aplikacji) oraz na aspekty związane z zabezpieczeniami, szczególnie w zakresie danych osobowych.
2.4.2. Analiza wpływu związana z pielęgnacją Analiza wpływu pozwala ocenić zmiany wprowadzone w wersji pielęgnacyjnej pod kątem zarówno skutków zamierzonych, jak i spodziewanych lub potencjalnych skutków ubocznych, a także umożliwia zidentyfikowanie obszarów systemu, na które będą miały wpływ wprowadzone zmiany. Ponadto może pomóc w zidentyfikowaniu wpływu zmiany na dotychczasowe testy. Skutki uboczne zmiany oraz obszary systemu, na które może ona wpływać, należy przetestować pod kątem regresji, przy czym czynność ta może być poprzedzona aktualizacją istniejących testów, na które oddziałuje dana zmiana.
Analizę wpływu można przeprowadzić przed dokonaniem zmiany, aby ustalić, czy zmianę tę należy faktycznie wprowadzić (z uwagi na potencjalne konsekwencje dla innych obszarów systemu).
Przeprowadzenie analizy wpływu może być utrudnione, jeśli:
• specyfikacje (np. wymagania biznesowe, historyjki użytkownika, architektura) są nieaktualne lub niedostępne;
• przypadki testowe nie zostały udokumentowane lub są nieaktualne;
• nie stworzono możliwości dwukierunkowego śledzenia powiązań między testami a podstawą testów;
• wsparcie narzędziowe nie istnieje lub jest niewystarczające;
• zaangażowane osoby nie dysponują wiedzą z danej dziedziny i/lub na temat danego systemu;
• podczas wytwarzania oprogramowania poświęcono zbyt mało uwagi jego charakterystyce jakościowej w zakresie utrzymywalności.

1.1. Co to jest testowanie?
Systemy oprogramowania są nieodłączną częścią naszego życia we wszystkich jego obszarach — od aplikacji biznesowych (np. w bankowości) po produkty użytkowe (np. samochody). Jednocześnie większość z nas miała zapewne do czynienia z oprogramowaniem, które nie zadziałało tak, jak powinno. Nieprawidłowe funkcjonowanie oprogramowania może powodować wiele problemów, w tym straty finansowe, stratę czasu, utratę reputacji firmy, a nawet utratę zdrowia lub życia. Testowanie oprogramowania pozwala ocenić jego jakość i zmniejszyć ryzyko wystąpienia awarii podczas eksploatacji.
Powszechnie uważa się, że testowanie polega wyłącznie na wykonywaniu testów, czyli uruchamianiu oprogramowania i sprawdzaniu uzyskanych rezultatów. Jak jednak opisano w podrozdziale 1.4., testowanie oprogramowania to proces obejmujący czynności, które wykraczają poza samo wykonywanie testów. W skład procesu testowego wchodzą również takie czynności jak: planowanie, analiza, projektowanie i implementacja testów, raportowanie o postępie i wynikach testów oraz dokonywanie oceny jakości przedmiotu testów. Testowanie może wymagać uruchomienia testowanego modułu lub systemu – mamy wtedy do czynienia z tzw. testowaniem dynamicznym. Można również wykonywać testy bez uruchamiania testowanego obiektu – takie testowanie nazywa się testowaniem statycznym. A zatem testowanie obejmuje również przegląd produktów pracy takich jak: wymagania, historyjki użytkownika i kod źródłowy.
Inne nieporozumienie polega na postrzeganiu testowania jako czynności skupionej wyłącznie na weryfikacji wymagań, historyjek użytkownika lub innych form specyfikacji. Chociaż w ramach testowania rzeczywiście sprawdza się, czy system spełnia wyspecyfikowane wymagania, to jednak przeprowadza się również walidację, której zadaniem jest sprawdzenie, czy system spełnia wymagania użytkowników oraz inne potrzeby interesariuszy w swoim środowisku operacyjnym.
Czynności testowe są organizowane i przeprowadzane w różny sposób w różnych cyklach życia (patrz podrozdział 2.1.).
1.1.1. Typowe cele testowania  W przypadku każdego projektu cele testowania mogą być realizowane między innymi poprzez następujące czynności:
• dokonywanie oceny produktów pracy, takich jak: wymagania, historyjki użytkownika, projekt i kod;
• sprawdzanie, czy zostały spełnione wszystkie wyspecyfikowane wymagania;
• sprawdzanie, czy przedmiot testów jest kompletny i działa zgodnie z oczekiwaniami użytkowników i innych interesariuszy;
• budowanie zaufania do poziomu jakości przedmiotu testów;
• zapobieganie defektom;
• wykrywanie defektów i awarii;
• dostarczanie interesariuszom informacji niezbędnych do podejmowania świadomych decyzji (dotyczących zwłaszcza poziomu jakości przedmiotu testów);
• obniżanie poziomu ryzyka związanego z jakością oprogramowania (np. ryzyka wystąpienia niewykrytych wcześniej awarii podczas eksploatacji);
• przestrzeganie wymagań wynikających z umów, przepisów prawa i norm/standardów i/lub sprawdzanie, czy obiekt testów jest zgodny z tymi wymaganiami lub standardami.
Cele testowania mogą różnić się w zależności od kontekstu testowanego modułu lub systemu, poziomu testów oraz modelu cyklu życia oprogramowania. Poniżej podano kilka przykładowych różnic.
• W przypadku testowania modułowego jednym z celów może być wykrycie jak największej liczby awarii, a w rezultacie wczesne zidentyfikowanie i usunięcie powodujących je defektów. Innym celem może być zwiększenie pokrycia kodu przez testy modułowe.
• W przypadku testowania akceptacyjnego jednym z celów może być potwierdzenie, że system działa zgodnie z oczekiwaniami i spełnia stawiane mu wymagania. Innym celem tego rodzaju testowania może być dostarczenie interesariuszom informacji na temat ryzyka, jakie wiąże się z przekazaniem systemu do eksploatacji w danym momencie.
1.1.2. Testowanie a debugowanie Testowanie i debugowanie to dwie różne czynności. Wykonywanie testów pozwala ujawnić awarie, które są skutkiem defektów w oprogramowaniu, natomiast debugowanie to czynność związana z wytwarzaniem oprogramowania, która polega na znajdowaniu, analizowaniu i usuwaniu tych defektów. Następnie wykonywane jest testowanie potwierdzające, które pozwala sprawdzić, czy wprowadzone poprawki w rezultacie spowodowały usunięcie defektów. W niektórych przypadkach testerzy są odpowiedzialni za przeprowadzenie testu początkowego oraz końcowego testu potwierdzającego, a programiści są odpowiedzialni za przeprowadzenie debugowania oraz związanego z nim testowania modułowego. Jednakże w przypadku zwinnego wytwarzania oprogramowania i niektórych innych cykli życia testerzy mogą być również zaangażowani w debugowanie i testowanie modułowe.
Standard międzynarodowy ISO/IEC/IEEE 29119-1 zawiera bardziej szczegółowe informacje dotyczące pojęć związanych z testowaniem.
1.2. Dlaczego testowanie jest niezbędne?
Rygorystyczne testowanie modułów i systemów oraz związanej z nimi dokumentacji może pomóc w zmniejszeniu ryzyka wystąpienia awarii podczas eksploatacji oprogramowania. Wykrycie, a następnie usunięcie defektów, przyczynia się do podniesienia jakości modułów lub systemów. Ponadto testowanie oprogramowania może być niezbędne do spełnienia wymagań wynikających z umów, przepisów prawa bądź norm/standardów branżowych.
1.2.1. Znaczenie testowania dla powodzenia projektu W historii informatyki znanych jest wiele przykładów oprogramowania i systemów, które zostały przekazane do eksploatacji, ale na skutek defektów uległy awarii lub z innych powodów nie zaspokoiły potrzeb interesariuszy. Dzięki odpowiednim technikom testowania — stosowanym w sposób fachowy na odpowiednich poziomach testów i w odpowiednich fazach cyklu życia oprogramowania — częstotliwość występowania tego rodzaju problemów można jednak ograniczyć. Poniżej przedstawiono kilka przykładów takich zastosowań.
• Zaangażowanie testerów w przeglądy wymagań lub w doprecyzowywanie historyjek użytkownika pomaga wykryć defekty w powyższych produktach pracy. Zidentyfikowanie i usunięcie tych defektów zmniejsza ryzyko wytworzenia niepoprawnej lub nietestowalnej funkcjonalności.
• Ścisła współpraca między testerami a projektantami systemu na etapie prac projektowych pozwala obu stronom lepiej zrozumieć projekt i sposób jego testowania. Lepsza znajomość tematu przekłada się na mniejsze ryzyko wystąpienia zasadniczych problemów w projekcie, a także pozwala zidentyfikować przypadki testowe w początkowym etapie projektu.
• Ścisła współpraca testerów z programistami na etapie tworzenia kodu pozwala obu stronom lepiej zrozumieć kod i sposób jego testowania. Większa wiedza w tym zakresie pozwala zmniejszyć ryzyko wystąpienia defektów w kodzie i spowodowanych przez nie awarii w testach.
• Weryfikacja i walidacja oprogramowania przez testerów przed przekazaniem go do eksploatacji pozwala wykryć defekty mogące prowadzić do awarii, które w przeciwnym razie mogłyby zostać przeoczone. Ułatwia także usuwanie związanych z nimi defektów (debugowanie). W rezultacie rośnie prawdopodobieństwo, że oprogramowanie zaspokoi potrzeby interesariuszy i spełni stawiane mu wymagania.
W uzupełnieniu powyższych przykładów należy zaznaczyć, że osiągnięcie zdefiniowanych celów testowania (patrz p. 1.1.1.) przyczynia się do ogólnego powodzenia procesu wytwarzania i pielęgnacji oprogramowania.
1.2.2. Zapewnienie jakości a testowanie Testowanie jest często utożsamiane z zapewnieniem jakości (ang. quality assurance), ale w rzeczywistości są to dwa oddzielne (chociaż powiązane ze sobą) procesy, które zawierają się w szerszym pojęciu „zarządzania jakością” (ang. quality management). Zarządzanie jakością obejmuje wszystkie czynności mające na celu kierowanie i nadzorowanie działań organizacji w dziedzinie jakości. Elementami zarządzania jakością są między innymi zapewnienie jakości i kontrola jakości. Zapewnienie jakości skupia się zazwyczaj na prawidłowym przestrzeganiu właściwych procesów w celu uzyskania pewności, że zostaną osiągnięte odpowiednie poziomy jakości.
Jeśli procesy są wykonywane prawidłowo, powstające w ich wyniku produkty pracy mają zwykle wyższą jakość, co przyczynia się do zapobiegania defektom. Duże znaczenie dla skutecznego zapewnienia jakości mają również wykorzystanie procesu analizy przyczyny podstawowej do wykrywania i usuwania przyczyn defektów oraz prawidłowe wdrażanie wniosków ze spotkań retrospektywnych w celu doskonalenia procesów.
Kontrola jakości obejmuje cały szereg czynności, włączając w to czynności testowe, które wspierają osiągnięcie odpowiednich poziomów jakości. Czynności testowe są ważnym elementem procesu wytwarzania lub pielęgnacji oprogramowania. Prawidłowy przebieg tego procesu (w tym testowania) jest istotny z punktu widzenia zapewnienia jakości, w związku z czym zapewnienie jakości wspiera właściwe testowanie. Jak opisano w punktach 1.1.1. i 1.2.1., testowanie przyczynia się do osiągnięcia wymaganej jakości produktów pracy na kilka różnych sposobów.
1.2.3. Pomyłki, defekty i awarie Na skutek pomyłki (błędu) człowieka w kodzie oprogramowania lub w innym związanym z nim produkcie pracy może powstać defekt (inaczej zwany usterką lub pluskwą). Pomyłka skutkująca wprowadzeniem defektu w jednym produkcie pracy może spowodować błąd skutkujący wprowadzeniem defektu w innym, powiązanym produkcie pracy. Przykładem takiej sytuacji jest pomyłka popełniona podczas pozyskiwania wymagań, która może prowadzić do defektu w wymaganiach, co spowoduje pomyłkę programisty skutkującą wprowadzeniem defektu w kodzie.
Wykonanie kodu zawierającego defekt może spowodować awarię, ale nie musi dziać się tak w przypadku każdego defektu. Niektóre defekty powodują awarię na przykład tylko po wprowadzeniu ściśle określonych danych wejściowych bądź na skutek wystąpienia określonych warunków wstępnych, które mogą zaistnieć bardzo rzadko lub nigdy.
 
Pomyłki mogą pojawiać się z wielu powodów, takich jak:
• presja czasu;
• omylność człowieka;
• brak doświadczenia lub niedostateczne umiejętności uczestników projektu;
• problemy z wymianą informacji między uczestnikami projektu (w tym nieporozumienia dotyczące rozumienia wymagań i dokumentacji projektowej);
• złożoność kodu, projektu, architektury, rozwiązywanego problemu i/lub wykorzystywanej technologii;
• nieporozumienia dotyczące interfejsów wewnątrz systemu i między systemami, zwłaszcza w przypadku dużej liczby tych systemów;
• stosowanie nowych, nieznanych technologii.
Awarie – poza tymi wynikającymi z defektów w kodzie – mogą być również spowodowane warunkami środowiskowymi. Przykładem takich sytuacji i warunków są: promieniowanie, pole elektromagnetyczne lub zanieczyszczenie środowiska, które mogą spowodować wystąpienie defektów w oprogramowaniu wewnętrznym (ang. firmware) lub wpłynąć na działanie oprogramowania poprzez zmianę parametrów pracy sprzętu.
Nie wszystkie nieoczekiwane wyniki testów oznaczają awarie. Wynik fałszywie pozytywny może być, między innymi, skutkiem błędów związanych z wykonaniem testów, defektów w danych testowych, środowisku testowym, w innych testaliach itp. Podobne problemy mogą być przyczyną sytuacji odwrotnej – wyniku fałszywie negatywnego, czyli sytuacji, w której testy nie wykrywają defektu, który powinny wykryć. Wyniki fałszywie pozytywne są raportowane jako defekty, których w rzeczywistości nie ma.
1.2.4. Defekty, podstawowe przyczyny oraz skutki Podstawowa przyczyna defektu to pierwotny powód, w wyniku którego defekt ten powstał. Przeanalizowanie defektu w celu zidentyfikowania podstawowej przyczyny pozwala zredukować wystąpienia podobnych defektów w przyszłości. Ponadto analiza przyczyny podstawowej — skupiająca się na najważniejszych, pierwotnych przyczynach defektów — może prowadzić do udoskonalenia procesów, co może z kolei przełożyć się na dalsze zmniejszenie liczby defektów w przyszłości.
Załóżmy na przykład, że defekt w jednym z wierszy kodu powoduje nieprawidłowe wypłacanie odsetek, co z kolei wiąże się z reklamacjami klientów. Wadliwy kod został napisany na podstawie historyjki użytkownika, która była niejednoznaczna, ponieważ właściciel produktu źle zrozumiał zasady naliczania odsetek. W związku z tym, jeśli przy naliczaniu odsetek występuje duży procent defektów, których podstawową przyczyną są podobne nieporozumienia, rozwiązaniem może być przeszkolenie właścicieli produktów w zakresie tego rodzaju obliczeń, co pozwoli zmniejszyć w przyszłości liczbę podobnych defektów.
W powyższym przykładzie reklamacje klientów są skutkami, nieprawidłowa wypłata odsetek jest awarią, a nieprawidłowe obliczenia wykonywane przez kod są defektem wynikającym z pierwotnego defektu, jakim była niejednoznaczność historyjki użytkownika. Podstawową przyczyną pierwotnego defektu były braki wiedzy właściciela produktu, na skutek których popełnił on pomyłkę przy pisaniu historyjki użytkownika. Proces analizy przyczyny podstawowej omówiono w sylabusach [ISTQB® ETM] i [ISTQB® EITP].
 
1.3. Siedem zasad testowania
Przez ostatnie kilkadziesiąt lat zaproponowano cały szereg zasad testowania, które dostarczają ogólnych wskazówek mających zastosowanie do wszystkich rodzajów testowania.
1. Testowanie ujawnia usterki, ale nie może dowieść ich braku
Testowanie może wykazać obecność defektów, ale nie może dowieść, że oprogramowanie jest od nich wolne. Tym samym testowanie zmniejsza prawdopodobieństwo, że w oprogramowaniu pozostaną niewykryte defekty, ale sam fakt niewykrycia defektów nie stanowi dowodu poprawności oprogramowania.
2. Testowanie gruntowne jest niemożliwe
Przetestowanie wszystkiego (tj. wszystkich kombinacji danych wejściowych i warunków wstępnych) jest możliwe tylko w najprostszych przypadkach. W związku z tym, zamiast podejmować próbę testowania gruntownego, należy odpowiednio ukierunkować wysiłki związane z testowaniem na zastosowanie analizy ryzyka, technik testowania i priorytetyzacji.
3. Wczesne testowanie oszczędza czas i pieniądze
Aby wcześnie wykryć defekty, należy rozpocząć testowanie statyczne i dynamiczne na jak najwcześniejszym etapie cyklu życia oprogramowania. Wczesne testowanie jest niekiedy nazywane „przesunięciem w lewo” (ang. shift left). Wykonywanie testów na wczesnym etapie cyklu życia oprogramowania pozwala ograniczyć lub wyeliminować kosztowne zmiany (patrz podrozdział 3.1.).
4. Kumulowanie się defektów
Zwykle większość defektów wykrytych podczas testowania przed przekazaniem oprogramowania do eksploatacji lub większość awarii występujących w fazie eksploatacji występuje lub ma swoje źródło w niewielkiej liczbie modułów. W rezultacie przewidywane skupiska defektów i skupiska defektów faktycznie zaobserwowane na etapie testowania lub eksploatacji są ważnym elementem analizy ryzyka, którą przeprowadza się w celu odpowiedniego ukierunkowania wysiłków związanych z testowaniem (o czym wspomniano w zasadzie nr 2.).
5. Paradoks pestycydów
Ciągłe powtarzanie tych samych testów prowadzi do sytuacji, w której przestają one w pewnym momencie wykrywać nowe defekty. Aby móc wykrywać nowe defekty, może być konieczne zmodyfikowanie dotychczasowych testów i danych testowych, a także napisanie nowych testów. Niezmieniane testy tracą z czasem zdolność do wykrywania defektów, podobnie jak pestycydy po pewnym czasie nie są zdolne do eliminowania szkodników. W niektórych przypadkach — takich jak automatyczne testowanie regresji — paradoks pestycydów może być korzystny, ponieważ pozwala potwierdzić, że liczba defektów związanych z regresją jest niewielka.
6. Testowanie zależy od kontekstu
Testowanie wykonuje się w różny sposób w różnych kontekstach. Na przykład oprogramowanie sterujące systemami przemysłowymi, które jest krytyczne ze względów bezpieczeństwa, testuje się inaczej niż aplikację mobilną sklepu internetowego. Innym przykładem może być odmienny sposób przeprowadzania testów w projektach zwinnych i w tych prowadzonych zgodnie z modelem sekwencyjnym cyklu życia  (patrz podrozdział 2.1.).
7. Przekonanie o braku błędów jest błędem1
Niektóre organizacje oczekują, że testerzy będą w stanie uruchomić wszystkie możliwe testy i wykryć wszystkie możliwe defekty, ale powyższe zasady (odpowiednio nr 2 i 1) pokazują, że jest to niemożliwe. Co więcej, błędnym jest przekonanie, że samo znalezienie i naprawienie dużej liczby defektów zapewni pomyślne wdrożenie systemu. Na przykład bardzo dokładne testowanie wszystkich wyspecyfikowanych wymagań i naprawienie wszystkich znalezionych defektów wciąż może nas nie uchronić od zbudowania systemu trudnego w obsłudze, który nie spełni wymagań i oczekiwań użytkowników lub będzie miał gorsze parametry od konkurencyjnych rozwiązań.
Więcej informacji na temat powyższych zagadnień oraz wielu innych zasad testowania można znaleźć w [Myers 2011], [Kaner 2002] i [Weinberg 2008].
 
1.4. Proces testowy Nie ma jednego uniwersalnego procesu testowania oprogramowania, ale istnieją typowe czynności testowe, bez stosowania których nie zostaną zrealizowane ustalone dla testowania cele. Czynności te składają się na proces testowy. Dobór procesu testowego do konkretnego oprogramowania w konkretnej sytuacji zależy od wielu czynników. Organizacja może w swojej strategii testowej zdefiniować, które czynności testowe wchodzą w skład tego procesu, jak czynności testowe mają być zaimplementowane oraz w którym momencie cyklu życia oprogramowania powinny mieć miejsce.
1.4.1. Proces testowy w kontekście Przykładowe czynniki kontekstowe wpływające na proces testowy w organizacji to:
• wykorzystywany model cyklu życia oprogramowania i metodyki projektowe;
• rozważane poziomy testów i typy testów;
• czynniki ryzyka produktowego i projektowego;
• dziedzina biznesowa;
• ograniczenia operacyjne, w tym w szczególności:
o budżety i zasoby;
o harmonogramy;
o złożoność procesu lub projektu;
o wymagania wynikające z umów i przepisów;
• polityka testów i praktyki obowiązujące w organizacji;
• wymagane normy/standardy wewnętrzne i zewnętrzne.
W kolejnych punktach opisano ogólne aspekty organizacyjnego procesu testowego w relacji do:
• czynności i zadań testowych;
• produktów pracy związanych z testowaniem;
• możliwości śledzenia powiązań pomiędzy podstawą testów a produktami pracy związanymi z testowaniem.
Dobrą praktyką jest zdefiniowanie mierzalnych kryteriów pokrycia dotyczących podstawy testów (w odniesieniu do każdego rozważanego poziomu lub typu testów). Kryteria pokrycia mogą w praktyce pełnić funkcję kluczowych wskaźników wydajności (ang. Key Performance Indicators — KPI) sprzyjających wykonywaniu określonych czynności i pozwalających wykazać osiągnięcie celów testowania oprogramowania (patrz p. 1.1.1.).
Przykładem ilustrującym tę praktykę jest podstawa testów dla aplikacji mobilnej, która może zawierać listę wymagań oraz listę wspieranych urządzeń mobilnych. Każde wymaganie i każde wspierane urządzenie jest elementem podstawy testów. Kryteria pokrycia mogą wymagać co najmniej jednego testu dla każdego elementu podstawy testów. Po wykonaniu testów ich wyniki są źródłem informacji dla interesariuszy, czy określone wymagania zostały spełnione oraz czy na wspieranych urządzeniach zaobserwowano awarie.
1.4.2. Czynności i zadania testowe W procesie testowym wyróżnia się następujące, główne grupy czynności:
• planowanie testów;
• monitorowanie testów i nadzór nad testami;
• analiza testów;
• projektowanie testów;
• implementacja testów;
• wykonywanie testów;
• ukończenie testów.
Każda grupa składa się z czynności, które opisano w kolejnych podpunktach. Ponadto poszczególne czynności w każdej z grup mogą składać się z kilku pojedynczych zadań różniących się w zależności od projektu lub wersji oprogramowania.
Należy również zaznaczyć, że chociaż wiele grup czynności może sprawiać wrażenie logicznie uszeregowanych, często są one realizowane metodą iteracyjną. Przykładem takiej praktyki jest model zwinnego wytwarzania oprogramowania, który opiera się na krótkich iteracjach obejmujących projektowanie, tworzenie i testowanie produktu. Iteracje odbywają się w sposób ciągły i są objęte ciągłym planowaniem. W rezultacie czynności testowe są również wykonywane w ramach tego podejścia do wytwarzania oprogramowania w sposób ciągły i iteracyjny. Nawet w przypadku stosowania metod sekwencyjnych, w których czynności są wykonywane krokowo w logicznej kolejności, pewne elementy nakładają się na siebie, są wykonywane łącznie lub równocześnie bądź są pomijane. W związku z powyższym zwykle konieczne jest dostosowanie głównych czynności do kontekstu danego systemu lub projektu.
Planowanie testów
Planowanie testów obejmuje czynności, których celem jest zdefiniowanie celów testowania oraz określenie podejścia do osiągania celów testowania w granicach wyznaczonych przez kontekst (np. określenie odpowiednich technik testowania i zadań testowych oraz sformułowanie harmonogramu testów, który umożliwi dotrzymanie wyznaczonego terminu). Plany testów mogą być następnie korygowane na podstawie informacji zwrotnych z monitorowania i nadzoru. Kwestię planowania testów objaśniono dokładniej w podrozdziale 5.2.
 
Monitorowanie testów i nadzór nad testami
Monitorowanie testów polega na ciągłym porównywaniu rzeczywistego z zaplanowanym postępem testowania przy użyciu miar specjalnie w tym celu zdefiniowanych w planie testów. Nadzór nad testami polega na podejmowaniu działań, które są niezbędne do osiągnięcia celów wyznaczonych w planie testów (z uwzględnieniem jego ewentualnych aktualizacji). Elementem wspomagającym monitorowanie testów i nadzór nad testami jest ocena kryteriów wyjścia, które w przypadku niektórych cykli życia są również nazywane „definicją ukończenia” (patrz [ISTQB® AT]). Ocena kryteriów wyjścia dla wykonania testów na określonym poziomie testów może obejmować:
• sprawdzenie rezultatów testów i dziennika testów pod kątem określonych kryteriów pokrycia;
• oszacowanie poziomu jakości modułu lub systemu na podstawie rezultatów testów i dziennika testów;
• ustalenie, czy są konieczne dalsze testy (np. w przypadku nieosiągnięcia przez dotychczas wykonane testy pierwotnie założonego poziomu pokrycia ryzyka produktowego, co wiąże się z koniecznością napisania i wykonania dodatkowych testów).
Interesariusze są informowani o postępie w realizacji planu testów za pomocą raportów o postępie testów, które zawierają między innymi informacje o ewentualnych odchyleniach od planu oraz informacje pomagające uzasadnić podjęcie decyzji o wstrzymaniu testowania.
Kwestię monitorowania testów i nadzoru nad testami objaśniono dokładniej w podrozdziale 5.3.
Analiza testów
Celem grupy czynności w analizie testów jest przeanalizowanie podstawy testów w celu zidentyfikowania testowalnych cech i zdefiniowania związanych z nimi warunków testowych. Innymi słowy, analiza testów służy do ustalenia tego, „co” należy przetestować (w kategoriach mierzalnych kryteriów pokrycia).
Główne czynności wykonywane w ramach analizy testów to:
• dokonywanie analizy podstawy testów właściwej dla rozważanego poziomu testów, np.:
o specyfikacji wymagań, takich jak: wymagania biznesowe, wymagania funkcjonalne, wymagania systemowe, historyjki użytkownika, opowieści (ang. epic)2, przypadki użycia lub podobne produkty pracy, które określają pożądane zachowanie funkcjonalne i niefunkcjonalne modułu lub systemu;
o informacji dotyczących projektu i implementacji, takich jak: diagramy lub dokumenty opisujące architekturę systemu lub oprogramowania, specyfikacje projektowe, przepływy wywołań, modele oprogramowania (np. diagramy UML lub diagramy związków encji), specyfikacje interfejsów lub podobne produkty pracy, które określają strukturę modułu lub systemu;
o implementacji samego modułu lub systemu, w tym kodu, metadanych, zapytań do bazy danych oraz interfejsów;                                                     
 2 Autorzy tłumaczenia zdecydowali się przetłumaczyć angielskie pojęcie „epic” jako „opowieść”; spotykane jest też niepoprawne językowo tłumaczenie „epika”.
o raportów z analizy ryzyka, które mogą dotyczyć aspektów funkcjonalnych, niefunkcjonalnych i strukturalnych modułu lub systemu;
• dokonywanie oceny testowalności podstawy testów i elementów testowych w celu zidentyfikowania często występujących typów defektów, które mogą powodować problemy z testowalnością, takich jak:
o niejednoznaczności;
o pominięcia;
o niespójności;
o nieścisłości;
o sprzeczności;
o nadmiarowe (zbędne) instrukcje;
• identyfikowanie cech i zbiorów cech, które mają zostać przetestowane;
• definiowanie warunków testowych w odniesieniu do poszczególnych cech oraz określenie ich priorytetów na podstawie analizy podstawy testów — z uwzględnieniem parametrów funkcjonalnych, niefunkcjonalnych i strukturalnych, innych czynników biznesowych i technicznych oraz poziomów ryzyka;
• stworzenie możliwości dwukierunkowego śledzenia powiązań między elementami podstawy testów a związanymi z nimi warunkami testowymi (patrz punkty 1.4.3. i 1.4.4.).
Zastosowanie technik czarnoskrzynkowych, białoskrzynkowych oraz technik opartych na doświadczeniu w ramach analizy testów (patrz rozdział 4.) pomaga zmniejszyć prawdopodobieństwo pominięcia ważnych warunków testowych oraz zdefiniować bardziej precyzyjne i dokładne warunki testowe.
W niektórych przypadkach w wyniku analizy testów definiowane są warunki testowe, które mają być wykorzystywane jako cele testów w kartach opisów testów. Karty opisu testów są typowymi produktami pracy w niektórych odmianach testowania opartego na doświadczeniu (patrz p. 4.4.2.). Jeśli istnieje śledzenie powiązań między wspomnianymi powyżej celami testów a podstawą testów, możliwy jest pomiar pokrycia uzyskanego w trakcie testowania opartego na doświadczeniu.
Identyfikowanie defektów na etapie analizy testów jest istotną potencjalną korzyścią, zwłaszcza gdy nie stosuje się żadnego innego procesu przeglądu i/lub gdy proces testowy jest ściśle powiązany z procesem przeglądu. Czynności wykonywane w ramach analizy testów pozwalają zweryfikować, czy wymagania są spójne, prawidłowo wyrażone i kompletne, a także sprawdzić, czy właściwie odzwierciedlają one potrzeby klienta, użytkowników i innych interesariuszy. Warto w tym  miejscu podać przykład takich technik jak: wytwarzanie sterowane zachowaniem (ang. Behavior Driven Development — BDD) i wytwarzanie sterowane testami akceptacyjnymi (ang. Acceptance Test Driven Development — ATDD), które obejmują generowanie warunków testowych i przypadków testowych na podstawie historyjek użytkownika i kryteriów akceptacji przed rozpoczęciem tworzenia kodu. Przewidują one również weryfikację i walidację historyjek użytkownika i kryteriów akceptacji oraz wykrywanie występujących w nich defektów (patrz [ISTQB® AT]).
Projektowanie testów
Podczas projektowania testów warunki testowe są przekształcane w przypadki testowe wysokiego poziomu, zbiory takich przypadków testowych oraz w inne testalia. W związku z tym o ile analiza testów odpowiada na pytanie: „co należy przetestować”, o tyle projektowanie testów odpowiada na pytanie: „jak należy testować”.
Główne czynności wykonywane w ramach projektowania testów to:
• projektowanie przypadków testowych i zbiorów przypadków testowych oraz określenie ich priorytetów;
• identyfikowanie danych testowych niezbędnych do obsługi warunków testowych i przypadków testowych;
• projektowanie środowiska testowego oraz zidentyfikowanie wszelkich niezbędnych narzędzi i elementów infrastruktury;
• tworzenie możliwości dwukierunkowego śledzenia powiązań między podstawą testów, warunkami testowymi, przypadkami testowymi i procedurami testowymi (patrz p. 1.4.4.).
Rozwinięcie warunków testowych w przypadki testowe i zbiory przypadków testowych na etapie projektowania testów wymaga często użycia technik testowania (patrz rozdział 4.).
Tak jak w przypadku analizy testów, projektowanie testów może również skutkować identyfikacją podobnych typów defektów w podstawie testów, co jest ważną potencjalną korzyścią.
Implementacja testów
Podczas implementacji testów tworzone i/lub dokańczane są testalia niezbędne do wykonania testów, w tym szeregowanie przypadków testowych w ramach procedur testowych. W związku z tym, o ile projektowanie testów odpowiada na pytanie: „jak testować?”, o tyle implementacja testów odpowiada na pytanie: „czy mamy wszystko, co jest potrzebne do uruchomienia testów?”.
Główne czynności wykonywane w ramach implementacji testów to:
• opracowanie procedur testowych i określenie ich priorytetów oraz, potencjalnie, utworzenie skryptów testów automatycznych;
• utworzenie zestawów testowych (na podstawie procedur testowych) oraz skryptów testów automatycznych (jeśli istnieją testy automatyczne);
• uporządkowanie zestawów testowych w harmonogram wykonywania testów w sposób zapewniający efektywny przebieg całego procesu (patrz p. 5.2.4.);
• zbudowanie środowiska testowego (włączając w to - jeśli to konieczne - jarzma testowe, wirtualizację usług, symulatory i inne elementy infrastrukturalne) oraz sprawdzenie, czy zostało ono poprawnie skonfigurowane;
• przygotowanie danych testowych i sprawdzenie, czy zostały poprawnie załadowane do środowiska testowego;
• zweryfikowanie i zaktualizowanie możliwości dwukierunkowego śledzenia powiązań między podstawą testów, warunkami testowymi, przypadkami testowymi, procedurami testowymi i zestawami testowymi (patrz p. 1.4.4.).
Zadania związane z projektowaniem i implementacją testów są często łączone.
Etapy projektowania i implementacji testów mogą być realizowane i dokumentowane w ramach wykonywania testów — zwłaszcza w przypadku testowania eksploracyjnego oraz innych typów testowania opartego na doświadczeniu. Testowanie eksploracyjne może odbywać się na podstawie kart opisu testów (sporządzanych w ramach analizy testów), przy czym testy eksploracyjne wykonywane są natychmiast po ich zaprojektowaniu i zaimplementowaniu (patrz p. 4.4.2.).
Wykonywanie testów
Podczas wykonywania testów uruchamiane są zestawy testowe, zgodnie z harmonogramem wykonania testów. Główne czynności przeprowadzane w ramach wykonywania testów to:
• zarejestrowanie danych identyfikacyjnych i wersji elementów testowych bądź przedmiotu testów, narzędzi testowych i testaliów;
• wykonywanie testów ręcznie lub przy użyciu narzędzi do wykonywania testów;
• porównanie rzeczywistych wyników testów z oczekiwanymi;
• przeanalizowanie anomalii w celu ustalenia ich prawdopodobnych przyczyn (np. awarie mogą być wynikiem defektów w kodzie, ale mogą się pojawić również wyniki fałszywie pozytywne (patrz p. 1.2.3.));
• raportowanie defektów oparte na obserwowanych awariach (patrz podrozdział 5.6.);
• zarejestrowanie (zalogowanie) wyniku wykonania testów (np. zaliczenie, niezaliczenie, test blokujący);
• powtórzenie czynności testowych w wyniku działań podjętych w związku z wystąpieniem anomalii albo w ramach zaplanowanego testowania (np. testowania potwierdzającego, wykonywania poprawionego testu i/lub testowania regresji);
• zweryfikowanie i zaktualizowanie możliwości dwukierunkowego śledzenia powiązań między podstawą testów, warunkami testowymi, przypadkami testowymi, procedurami testowymi i wynikami testów.
Ukończenie testów
Ukończenie testów polega na zebraniu danych pochodzących z wykonanych czynności testowych w celu skonsolidowania zdobytych doświadczeń, testaliów oraz innych stosownych informacji. Czynności związane z ukończeniem testów są wykonywane w momencie osiągnięcia kamieni milowych projektu, takich jak: przekazanie systemu lub oprogramowania do eksploatacji, zakończenie realizacji (lub anulowanie) projektu, zakończenie iteracji projektu zwinnego (np. w ramach spotkania retrospektywnego), ukończenie poziomu testów bądź zakończenie prac nad wydaniem pielęgnacyjnym (ang. maintenance release).
Główne czynności wykonywane w ramach ukończenia testów to:
• sprawdzenie, czy wszystkie raporty o defektach są zamknięte oraz wprowadzenie żądań zmian lub pozycji do rejestru produktu w odniesieniu do wszelkich defektów, które nie zostały rozwiązane do momentu zakończenia wykonywania testów;
• utworzenie sumarycznego raportu z testów, który zostanie przekazany interesariuszom;
• dla wersji końcowych: zarchiwizowanie środowiska testowego, danych testowych, infrastruktury testowej oraz innych testaliów, do ponownego wykorzystania w przyszłości;
• przekazanie testaliów zespołom odpowiedzialnym za pielęgnację, innym zespołom projektowym i/lub innym interesariuszom, którzy mogą odnieść korzyść z ich użycia;
• przeanalizowanie zdobytych doświadczeń omawianych na wszystkich etapach projektu w celu ustalenia, jakie zmiany będą konieczne w przypadku przyszłych iteracji, wydań i projektów;
• wykorzystanie zebranych informacji do zwiększenia dojrzałości procesu testowego.
1.4.3. Produkty pracy związane z testowaniem Produkty pracy związane z testowaniem powstają w ramach procesu testowego. Podobnie jak sposób implementacji procesu testowego, również typy produktów pracy powstających w wyniku tego procesu oraz nadawane im nazwy różnią się znacznie w poszczególnych organizacjach. W niniejszym sylabusie przyjęto opisaną powyżej definicję procesu testowego  oraz produktów pracy (opisanych zarówno w sylabusie, jak i w Słowniku terminów testowych ISTQB® [ISTQB® S]). Punktem odniesienia dla produktów pracy związanych z testowaniem może być również standard międzynarodowy ISO/IEC/IEEE 29119-3.
Wiele z produktów pracy związanych z testowaniem, które opisano w tym punkcie, może być tworzonych i zarządzanych przy użyciu narzędzi do zarządzania testami oraz narzędzi do zarządzania defektami (patrz rozdział 6.).
Produkty pracy planowania testów
Wśród produktów pracy powstających na etapie planowania testów można zwykle wyróżnić jeden lub kilka planów testów. Plan testów zawiera informacje na temat podstawy testów, z którą zostaną powiązane za pośrednictwem informacji śledzenia inne produkty pracy związane z testowaniem (patrz poniżej i p. 1.4.4.). Ponadto określa się w nim kryteria wyjścia (definicję ukończenia), które będą stosowane w ramach monitorowania testów i nadzoru nad testami. Planowanie testów opisano w podrozdziale 5.2.
Produkty pracy monitorowania testów i nadzoru nad testami
Typowymi produktami pracy związanymi z monitorowaniem testów i nadzorem nad testami są różnego rodzaju raporty z testów, w tym raporty o postępie testów (tworzone na bieżąco i/lub w regularnych odstępach czasu) oraz sumaryczne raporty końcowe z testów (tworzone w momencie osiągnięcia poszczególnych kamieni milowych projektu). Raporty z testów powinny zawierać szczegółowe informacje na temat dotychczasowego przebiegu procesu testowego (w tym podsumowanie rezultatów wykonywania testów, gdy zostaną one udostępnione) i powinny być przedstawiane w formie dostosowanej do potrzeb konkretnych odbiorców. Monitorowanie testów i nadzór nad testami oraz produkty pracy powstające w ramach tych czynności opisano dokładniej w podrozdziale 5.3.
Produkty pracy monitorowania testów i nadzoru nad testami powinny również odnosić się do kwestii dotyczących zarządzania projektem, takich jak: ukończenie zadań, alokacja i zużycie zasobów czy też pracochłonność.
Produkty pracy analizy testów
Produkty pracy związane z analizą testów obejmują zdefiniowane i uszeregowane według priorytetów warunki testowe, przy czym pożądana jest możliwość dwukierunkowego śledzenia powiązań między tymi warunkami a pokrywanymi przez nie elementami podstawy testów. W przypadku testowania eksploracyjnego, w wyniku analizy testów mogą również powstawać karty opisu testów. Ponadto analiza testów może prowadzić do wykrycia i zgłoszenia defektów w podstawie testów.
Produkty pracy projektowania testów
W wyniku projektowania testów powstają przypadki testowe i zestawy testowe zdefiniowane na etapie analizy testów. 

Dobrą praktyką jest projektowanie przypadków testowych wysokiego poziomu, które nie zawierają konkretnych wartości danych wejściowych i oczekiwanych rezultatów. Wysokopoziomowe przypadki testowe można wykorzystywać wielokrotnie w różnych cyklach testowych z użyciem różnych danych szczegółowych, należycie dokumentując przy tym zakres przypadku testowego. W idealnej sytuacji dla każdego przypadku testowego istnieje możliwość dwukierunkowego śledzenia powiązań między tym przypadkiem a pokrywanym przez niego warunkiem testowym (lub warunkami testowymi).
Wśród rezultatów etapu projektowania testów można również wymienić zaprojektowanie i/lub zidentyfikowanie niezbędnych danych testowych, zaprojektowanie środowiska testowego oraz zidentyfikowanie infrastruktury i narzędzi, przy czym stopień udokumentowania powyższych rezultatów bywa bardzo zróżnicowany.
Warunki testowe zdefiniowane w fazie analizy testów mogą być doprecyzowane podczas projektowania testów.
Produkty pracy implementacji testów
Produkty pracy związane z implementacją testów to między innymi:
• procedury testowe oraz kolejność ich wykonywania;
• zestawy testowe;
• harmonogram wykonania testów.
W idealnym przypadku, po zakończeniu implementacji testów można wykazać spełnienie kryteriów pokrycia określonych w planie testów dzięki możliwości dwukierunkowego śledzenia powiązań między procedurami testowymi a elementami podstawy testów (za pośrednictwem przypadków testowych i warunków testowych).
W pewnych sytuacjach implementacja testów wiąże się również z utworzeniem produktów pracy, których użycie wymaga korzystania z narzędzi lub narzędzia są przez nie wykorzystywane. Przykłady takich produktów pracy to  wirtualizacja usług czy skrypty testów automatycznych.
Implementacja testów może także skutkować utworzeniem i zweryfikowaniem danych testowych i środowiska testowego, przy czym poziom kompletności dokumentacji dotyczącej rezultatów weryfikacji danych i/lub środowiska może być bardzo różny.
Dane testowe służą do przypisywania konkretnych wartości do danych wejściowych i oczekiwanych rezultatów przypadków testowych. Te konkretne wartości, wraz z konkretnymi wskazówkami ich użycia, przekształcają przypadki testowe wysokiego poziomu w wykonywalne przypadki testowe niskiego poziomu. Ten sam przypadek testowy wysokiego poziomu można wykonywać z użyciem różnych danych testowych w odniesieniu do różnych wersji przedmiotu testów. Konkretne, oczekiwane rezultaty związane z określonymi danymi testowymi, identyfikuje się przy użyciu wyroczni testowej.
W przypadku testowania eksploracyjnego niektóre produkty pracy związane z projektowaniem i implementacją testów mogą powstawać już w trakcie wykonywania testów, przy czym stopień udokumentowania testów eksploracyjnych i możliwości śledzenia powiązań do określonych elementów podstawy testów może być bardzo różny.
Na etapie implementacji testów można również doprecyzować warunki testowe zdefiniowane podczas analizy testów.
Produkty pracy wykonywania testów
Do produktów pracy związanych z wykonywaniem testów zaliczają się między innymi:
• dokumentacja dotycząca statusu poszczególnych przypadków testowych lub procedur testowych (np.: gotowy do wykonania, zaliczony, niezaliczony, zablokowany, celowo pominięty itd.);
• raporty o defektach (patrz podrozdział 5.6.);
• dokumentacja wskazująca, które elementy testowe, przedmioty testów, narzędzia testowe i testalia zostały wykorzystane w ramach testowania.
W idealnym przypadku, po zakończeniu wykonywania testów można ustalić status poszczególnych elementów podstawy testów i wygenerować raporty na ten temat dzięki możliwości dwukierunkowego śledzenia powiązań do odpowiednich procedur testowych. Można na przykład wskazać, które wymagania zostały całkowicie przetestowane i pomyślnie przeszły testy, które wymagania nie przeszły testów i/lub wiążą się z defektami oraz które wymagania nie zostały jeszcze w pełni przetestowane. Umożliwia to sprawdzenie, czy zostały spełnione kryteria pokrycia testowego oraz przedstawienie rezultatów testów w raportach w sposób zrozumiały dla interesariuszy.
Produkty pracy ukończenia testów
Produkty pracy związane z ukończeniem testów to między innymi: sumaryczne raporty z ukończenia testów, czynności do wykonania mające na celu wprowadzenie udoskonaleń w kolejnych projektach lub iteracjach (np. po retrospektywie projektu zwinnego), żądania zmian lub pozycje listy zaległości produktowych oraz ostateczna wersja  testaliów.
1.4.4. Śledzenie powiązań między podstawą testów a produktami pracy związanymi z testowaniem Jak wspomniano w p. 1.4.3., produkty pracy związane z testowaniem i ich nazwy mogą być bardzo różne. Niezależnie od tych różnic, w celu zapewnienia skutecznego monitorowania i nadzoru, istotne jest stworzenie i utrzymywanie mechanizmu śledzenia powiązań między każdym elementem podstawy testów a odpowiadającymi mu produktami pracy związanymi z testowaniem przez cały czas trwania procesu testowego. Sprawne śledzenie powiązań umożliwia nie tylko ocenę pokrycia testowego, ale również:
• analizowanie wpływu zmian;
• przeprowadzanie audytu testów;
• spełnianie kryteriów związanych z zarządzaniem w obszarze IT;
• tworzenie bardziej zrozumiałych raportów o statusie testów i sumarycznych raportów z testów dzięki uwzględnieniu statusu elementów podstawy testów (np. wymagań, dla których testy zostały zaliczone, niezaliczone lub czekają na wykonanie);
• przekazywanie interesariuszom informacji o aspektach technicznych testowania w zrozumiałej dla nich formie;
• udzielanie informacji potrzebnych do oceny jakości produktów, możliwości procesów i postępu w realizacji projektu z punktu widzenia możliwości osiągnięcia celów biznesowych.
Niektóre narzędzia do zarządzania testami mają wbudowane modele produktów pracy związanych z testowaniem, które odpowiadają pewnej części lub wszystkim produktom omówionym w tym punkcie. Ponadto istnieją organizacje, które budują własne systemy zarządzania w celu uporządkowania produktów pracy i dostarczania niezbędnych informacji związanych ze śledzeniem.

1.5. Psychologia testowania
Wytwarzanie oprogramowania, w tym jego testowanie, to proces realizowany z udziałem ludzi, w związku z czym duże znaczenie dla przebiegu testowania mają uwarunkowania psychologiczne. 
1.5.1. Psychologia człowieka a testowanie Identyfikowanie defektów podczas testowania statycznego (np. w ramach przeglądów wymagań lub sesji doprecyzowywania historyjek użytkowników)  bądź identyfikowanie awarii w trakcie testowania dynamicznego może być odbierane jako krytyka produktu lub jego autora. Jednocześnie zjawisko psychologiczne zwane efektem potwierdzenia (ang. confirmation bias) może utrudniać zaakceptowanie informacji sprzecznych z dotychczasowymi przekonaniami. Przykładem takiego zjawiska są oczekiwania programistów, że ich kod będzie poprawny, co prowadzi do wystąpienia efektu potwierdzenia, który skutkuje tym, że trudno jest im zaakceptować fakt, że ich kod jest błędny. Obok efektu potwierdzenia mogą też występować inne błędy poznawcze, które utrudniają ludziom zrozumienie lub zaakceptowanie informacji uzyskanych w wyniku testowania. Dodatkowy czynnik utrudniający przyjęcie informacji zwrotnej z testów stanowi skłonność wielu osób  do obwiniania osoby przynoszącej złe wiadomości, a takie sytuacje często są rezultatem testowania.
Na skutek działania powyższych czynników psychologicznych niektóre osoby mogą postrzegać testowanie jako czynność destrukcyjną, nawet jeśli przyczynia się ono wydatnie do postępu w realizacji projektu i podnoszenia jakości produktów (patrz podrozdziały 1.1. i 1.2.). Aby ograniczyć podobne reakcje, należy przekazywać informacje o defektach i awariach w sposób jak najbardziej konstruktywny, co pozwoli zmniejszyć napięcia między testerami a analitykami, właścicielami produktów, projektantami i programistami. Zasada ta ma zastosowanie zarówno do testowania statycznego, jak i do testowania dynamicznego.
Testerzy i kierownicy testów muszą posiadać duże umiejętności interpersonalne, aby sprawnie przekazywać informacje na temat defektów, awarii, rezultatów testów, postępu testowania i ryzyk oraz budować pozytywne relacje ze współpracownikami. Poniżej przedstawiono kilka zaleceń dotyczących zasad dobrej wymiany informacji:
• Należy zacząć od współpracy, a nie od konfliktu. Wszystkich powinna łączyć świadomość wspólnego celu, jakim jest podnoszenie jakości systemów.
• Należy podkreślić korzyści wynikające z testowania. Przykładem takiego zachowania jest wykorzystanie przez autorów informacji o defektach do doskonalenia produktów pracy i rozwijania umiejętności. Dla organizacji wykrycie i usunięcie defektów podczas testowania oznacza oszczędność czasu i pieniędzy oraz zmniejszenie ogólnego ryzyka związanego z jakością produktów.
• Informacje na temat rezultatów testów i inne wnioski należy przekazywać w sposób neutralny, koncentrując się na faktach i nie krytykując osoby, która stworzyła wadliwy element. W związku z powyższym należy zadbać o to, by raporty o defektach i wnioski z przeglądu były obiektywne oraz znajdowały oparcie w faktach.
• Należy wczuć się w sytuację drugiej osoby i zrozumieć, dlaczego negatywnie reaguje ona na podane informacje.
• Należy upewnić się, że rozmówca rozumie przekazywane informacje i vice versa.
W poprzedniej części dokumentu (patrz podrozdział 1.1.) omówiono typowe cele testowania. Jednoznaczne zdefiniowanie właściwego zbioru celów testowania ma istotne implikacje psychologiczne, ponieważ większość osób ma skłonność do dopasowywania swoich planów i zachowań do celów określonych przez zespół, kierownictwo i innych interesariuszy. W związku z tym należy zadbać o to, by testerzy przestrzegali przyjętych założeń, a ich osobiste nastawienie w jak najmniejszym stopniu wpływało na wykonywaną pracę.
1.5.2. Różnice w sposobie myślenia testerów i programistów Programiści i testerzy często prezentują odmienny sposób myślenia. Podstawowym celem prac programistycznych jest zaprojektowanie i wykonanie produktu. Jak wspomniano powyżej, cele testowania obejmują weryfikację i walidację produktu, wykrycie defektów przed przekazaniem produktu do eksploatacji itd. Tym samym mamy do czynienia z różnymi zbiorami celów wymagającymi różnego nastawienia, których pogodzenie jest kluczem do uzyskania produktu wyższej jakości.
Sposób myślenia danej osoby wyznaczają przyjmowane przez nią założenia oraz preferowane przez nią sposoby podejmowania decyzji i rozwiązywania problemów. Wśród pożądanych cech osobowościowych testera należy wymienić: ciekawość, „zawodowy pesymizm”, umiejętność krytycznego spojrzenia na wykonywane czynności, dbałość o szczegóły oraz motywację do utrzymywania opartych na zaufaniu i wspólnym dążeniu do celu relacji zawodowych. Warto też zaznaczyć, że sposób myślenia testera często ewoluuje i dojrzewa wraz ze zdobywaniem przez niego doświadczenia zawodowego.
Wśród typowych cech osobowościowych programisty mogą występować niektóre cechy charakterystyczne dla testera, ale programiści odnoszący sukcesy w swoim zawodzie są często bardziej zainteresowani projektowaniem i budowaniem rozwiązań niż analizowaniem ewentualnych problemów z przyjętymi rozwiązaniami. Ważnym czynnikiem jest również efekt potwierdzenia, który może utrudnić znajdowanie pomyłek w rezultatach własnej pracy.
Programiści mający odpowiednie nastawienie mogą testować własny kod. Różne cykle życia oprogramowania oferują różne sposoby organizowania pracy testerów i wykonywania czynności testowych. Zlecając wykonanie niektórych czynności testowych niezależnym testerom, można zwiększyć skuteczność wykrywania defektów, co jest szczególnie ważne w przypadku systemów dużych, złożonych lub krytycznych ze względów bezpieczeństwa. Niezależni testerzy mają inny punkt widzenia, różny od punktów widzenia autorów produktów pracy (tj. analityków biznesowych, właścicieli produktów, projektantów i programistów), ponieważ mają inne uprzedzenia poznawcze (ang. cognitive biases).