1PODSTAWY TESTOWANIA
Ten rozdział składa się z następujących podrozdziałów: Konieczność testowania, Czym jest testowanie, Ogólne zasady testowania, Podstawowy proces testowy oraz Psychologia testowania. W pierwszym podrozdziale wyjaśniono przyczyny, z powodu których testowanie staje się konieczne w obecnym środowisku IT, w drugim podrozdziale natomiast - definicje testowania oraz podstawowe koncepcje niezbędne do zrozumienia istoty testowania.
W trzecim podrozdziale opisano podstawowe zasady testowania - siedem pryncypiów stanowiących podstawę organizacji testów w dowolnym przedsięwzięciu oraz przedsiębiorstwie.
Kolejna sekcja dotyczy podstawowego procesu testowego, uznawanego za wzorzec i podstawę projektowania struktury procesów testowych.
W ostatnim podrozdziale omówiono podstawowe aspekty psychologiczne związane z wykonywaniem zawodu testera.
W poszczególnych podrozdziałach zostały wyjaśnione następujące pojęcia:
- podrozdział 1.1: pluskwa, defekt, błąd, awaria, usterka, pomyłka, jakość, ryzyko;
- podrozdział 1.2: debagowanie, wymaganie, przegląd, przypadek testowy, testowanie, cel testu;
- podrozdział 1.3: testowanie gruntowne;
- podrozdział 1.4: testowanie potwierdzające, retesty, kryteria wyjścia, incydent, testowanie regresywne, podstawa testów, warunek testowy, pokrycie testowe, dane testowe, wykonanie testów, log testowy, plan testów, procedura testowa, polityka testów, zestaw testów, sumaryczny raport z testów, testalia;
- podrozdział 1.5: zgadywanie błędów, niezależność testowania.
1.1. Konieczność testowania
1.1.1. Wprowadzenie
Celem podrozdziału jest wyjaśnienie znaczenia testowania w kontekście realizacji projektów informatycznych.
W tym podrozdziale wyjaśniono przyczyny, z powodu których testowanie jest niezbędnym elementem procesu wytwarzania produktu. Testowanie, rozumiane jako kontrola jakości produktu na różnych etapach jego powstawania, służy minimalizacji ryzyka dostarczenia wyrobu wadliwego, niespełniającego wymagań i oczekiwań odbiorcy. Same procesy wytwórcze - projektowanie i produkcja - najczęściej nie uwzględniają czynności kontroli jakości lub obejmują jedynie najbardziej podstawowe działania. Z tego powodu konieczny jest proces skoncentrowany na badaniu i ocenie jakości. Procesem tym jest testowanie.
1.1.2. Kontekst systemów informatycznych
Oprogramowanie jest integralnym składnikiem wielu elementów dzisiejszego biznesu, mediów i życia. W odróżnieniu od sytuacji sprzed kilkunastu czy kilkudziesięciu lat trudno już znaleźć obszar, w którym nie występuje wsparcie technik informatycznych; zmieniło się też grono odbiorców - z wąskiego grona specjalistów "informatyków" na odbiorców "rynkowych" - czyli w większości osoby bez żadnego przygotowania technicznego czy doświadczenia w użytkowaniu systemów informatycznych. Dziś spory odsetek oprogramowania ma służyć "ogółowi", czyli osobom w różnym przedziale wieku, o odmiennym doświadczeniu zawodowym czy różnych preferencjach. To powoduje, że zmieniają się wymagania dotyczące oprogramowania - ma ono być intuicyjne, ponieważ nie jest możliwe przeszkolenie wszystkich użytkowników, a o sukcesie produktu decyduje to, czy spełni on oczekiwania odbiorców i umożliwi im wykonywanie zamierzonych zadań; ma być skalowalne, ponieważ wiele obszarów biznesowych rozwija się w olbrzymim tempie; ma być niezawodne, ponieważ odbiorcy oczekują produktu bezawaryjnego i stabilnego.
Oprogramowanie istniejące w dzisiejszym świecie to nie tylko systemy służące rozrywce czy ułatwianiu pewnych czynności - to również produkty, od których niezawodności zależy zdrowie czy życie ludzkie (np. oprogramowanie sterujące systemem podtrzymywania życia lub oprogramowanie do konfiguracji urządzeń medycznych do chemioterapii), czy wielkie kwoty finansowe (np. systemy finansowe, od których wiarygodności zależy lojalność klientów).
Z tych powodów oprogramowanie, które powstaje, jest przedmiotem starannej weryfikacji - na każdym etapie, pod każdym względem. Jeśli dodać do tego stale zwiększającą się złożoność oprogramowania - otrzymujemy gotowy argument przemawiający za koniecznością wdrożenia odpowiednich metod projektowania i weryfikacji produktów informatycznych.
1.1.3. Przyczyny usterek w oprogramowaniu
W jaki sposób pojawiają się problemy w oprogramowaniu? Punktem wyjścia jest błąd - pomyłka ludzka, która powoduje powstanie defektu (usterki, pluskwy) w kodzie oprogramowania lub dokumencie stanowiącym podstawę prac projektowych. Jeżeli kod zawierający defekt zostaje uruchomiony, aplikacja zachowa się inaczej, niż było zamierzone - spowoduje awarię.
Definicja 1.1. Pomyłka
Pomyłka (ang. mistake) - działanie człowieka powodujące powstanie nieprawidłowego rezultatu (IEEE, 1990). Pomyłka nazywana jest również błędem.
Definicja 1.2. Defekt
Defekt (ang. defect) - wada modułu lub systemu, która może spowodować, że moduł lub system nie wykona zakładanej czynności, np. niepoprawne wyrażenie lub definicja danych. Defekt, który wystąpi podczas uruchomienia programu, może spowodować awarię modułu lub systemu (ISTQB/SJSI, 2013). Defekt nazywany jest również pluskwą lub usterką.
Definicja 1.3. Awaria
Awaria (ang. failure) - odchyłka modułu lub systemu od oczekiwanego zachowania albo rezultatu działania (Fenton & Bieman, 2014).
Należy zwrócić uwagę na to, że usterki w oprogramowaniu, systemach lub dokumentach mogą, lecz niekoniecznie muszą, prowadzić do wystąpienia awarii. O awarii możemy mówić wtedy, gdy usterka "zamanifestowała" się w produkcie, kiedy możemy zobaczyć jej skutki jako odchylenie działania rzeczywistego od oczekiwanego.
Głównymi przyczynami występowania defektów jest czynnik ludzki - większość prac nad wytworzeniem oprogramowania jest realizowana przez człowieka, od pozyskania wymagań na oprogramowanie, poprzez ich analizę i opracowanie projektu rozwiązania systemowego, po implementację. Czynnik ludzki to element obarczony wysokim stopniem niepewności - ludzie są omylni, często (zwłaszcza w realiach projektowych) działają pod presją, pracują ze złożonym kodem czy algorytmami. Do tego dochodzi praca w warunkach zmieniających się technologii i konieczności integracji między wieloma systemami. Z powodu błędu ludzkiego powstaje najwięcej usterek w produkcie - co potwierdzają statystyki wskazujące - w zależności od źródła - że na etapie analizy i projektowania powstaje od 50 do 80% wszystkich defektów (Gopalakrishnan Nair & Suma, 2010).
Rysunek 1.1. Dystrybucja defektów w fazach projektu - statystyka 1
Źródło: Gopalakrishnan Nair & Suma, 2010
Rysunek 1.2. Dystrybucja defektów w fazach projektu - statystyka 2
Źródło: Gopalakrishnan Nair & Suma, 2010
Rysunek 1.3. Dystrybucja defektów w fazach projektu - statystyka 3
Źródło: Gopalakrishnan Nair & Suma, 2010
Oprócz czynnika ludzkiego istnieją i inne przyczyny pojawiania się awarii. Dość często awarie wywoływane są przez warunki środowiskowe, np. promieniowanie, pole magnetyczne i elektryczne oraz zanieczyszczenia mogą spowodować awarie oprogramowania wbudowanego; mogą też zmieniać działanie aplikacji przez zmianę warunków działania sprzętu.
1.1.4. Rola testowania w rozwoju, utrzymaniu i użytkowaniu oprogramowania
Testowanie, zastosowane zarówno do oprogramowania, jak i dokumentacji stanowiącej podstawę planowania i projektowania, może pomóc w zmniejszeniu ryzyka wystąpienia defektów i awarii. Tym samym zmniejsza się prawdopodobieństwo wystąpienia problemów podczas projektowania oraz użytkowania oprogramowania i sumarycznie podnosi się jakość produktu - przy założeniu, iż znalezione usterki zostaną poprawione, a poprawność korekty zweryfikowana przed przekazaniem systemu odbiorcom.
Samo testowanie powinno stanowić integralną część procesu wytwarzania oprogramowania - idealnie od wczesnych etapów wytwarzania. Powinno być dostosowane do obranego modelu wytwarzania i odpowiednio powiązane z innymi procesami wytwórczymi oraz wspierającymi. Istotne jest również to, by testowanie uwzględniało kontekst obszaru biznesowego, w którym ma działać produkt, w niektórych bowiem dziedzinach istnieją specyficzne standardy i wymagania, które musi spełnić oprogramowanie, by zostało dopuszczone do użytku. Wymagania "na jakość" mogą również pochodzić z samego kontraktu między zamawiającym a dostawcą oprogramowania.
Przykład 1.1. Wymaganie dotyczące jakości oprogramowania
Oryginalny zapis w Specyfikacji Istotnych Warunków Zamówienia (SIWZ): System musi być w stanie obsługiwać przynajmniej 1000 użytkowników jednocześnie.
Komentarz: Wymaganie to, by było w pełni testowalne, powinno zostać uzupełnione o określenie akceptowalnego czasu odpowiedzi systemu na działania użytkowników. Niezbędne jest też określenie parametrów środowiska produkcyjnego, aby było wiadomo, w jakich warunkach dane wymaganie ma zostać spełnione.
1.1.5. Testowanie a jakość
Klienci i konsumenci pragną produktów wysokiej jakości. Produktów niezawodnych, spełniających postawione przed nimi zadania i cele. Jak już wcześniej wspomniano, testowanie może przyczyniać się do podniesienia jakości oprogramowania. Teraz pojawia się pytanie, w jaki sposób.
Definicja 1.4. Jakość
Jakość (ang. quality) - stopień, w jakim moduł, system lub proces spełnia określone wymagania i/lub potrzeby oraz oczekiwania klienta lub użytkownika (IEEE, 1990).
Po pierwsze, wyniki testów dostarczają informację o jakości oraz dają możliwość zmierzenia jakości oprogramowania. Ocena ta może być wyrażona przez liczbę usterek wykrytych dla funkcjonalnych i niefunkcjonalnych atrybutów oprogramowania (często odnosi się tu do normy ISO 9126 Software Engineering - Software Product Quality).
Po drugie, wyniki testów pozwalają budować zaufanie do jakości oprogramowania. Samo testowanie jakości nie buduje, pozwala ją jednak ocenić i przyczynia się do jej podniesienia.
Jeśli zespół testowy nie znajduje usterek lub znajduje ich stosunkowo mało, podwyższa się poziom zaufania do systemu. Wynika to z tego, że profesjonalnie projektowane testy to testy opracowane w taki sposób, by pokryć określone elementy czy obszary ryzyka. Wykonując tak skonstruowane testy, weryfikuje się systematycznie każdy obszar, funkcję czy atrybut oprogramowania uznany za istotny dla poprawności funkcjonowania produktu. Jeśli testy wykryją usterki i zostaną one poprawnie skorygowane, podnosi się jakość produktu - poprzez eliminację niezgodności przed przekazaniem produktu do odbiorcy.
Po trzecie, testowanie daje możliwość usprawniania procesów. W wyniku testowania mogą pojawić się zgłoszenia usterek - poprzez określenie i analizę pierwotnych przyczyn usterek można ustalić rzeczywiste źródło problemów i je wyeliminować, doskonaląc w ten sposób procesy odpowiedzialne za wytworzenie produktów prac, w których owe usterki się pojawiły. To z kolei zmniejsza prawdopodobieństwo ponownego pojawienia się podobnych wad i w rezultacie podnosi jakość przyszłych produktów realizacji procesów - czyli m.in. oprogramowania.
1.1.6. Jak dużo testowania jest potrzebne
Na zakończenie warto zadać sobie pytanie, które nurtuje większość osób rozpoczynających przygodę z testowaniem: kiedy można uznać, że testowanie jest zakończone.
Odpowiedź na te pytania jest dość typowa dla branży IT: to zależy. Zależy od tzw. kryteriów zakończenia, które są ustalane na etapie planowania testów. Kryteria te powinny uwzględniać wymagania jakościowe produktu, poziom dopuszczalnego ryzyka, ale i ograniczenia projektowe, takie jak czas i budżet.
Generalnie, można przyjąć, iż testowanie na danym etapie można skończyć wtedy, gdy spełnione są kryteria zakończenia, a wyniki testowania dostarczają interesariuszom wystarczającej informacji do podjęcia świadomych decyzji o dopuszczeniu testowanego systemu do następnej fazy rozwoju lub przekazaniu go klientowi.
Przykład 1.2. Kryteria zakończenia testów
Przykładowe kryteria zakończenia testów:
- Osiągnięto 100% pokrycie krytycznych ryzyk.
- Wszystkie znalezione awarie o krytyczności wysokiej i średniej są naprawione i zweryfikowane jako naprawione. W systemie mogą istnieć nie więcej, niż 3 otwarte awarie o krytyczności niskiej.
- Klient zaakceptował wnioski przedstawione w raporcie podsumowującym testy.
Co należy wiedzieć po przeczytaniu tego podrozdziału:
LO-1.1.1
Umieć opisać, podając przykłady, w jaki sposób usterka w oprogramowaniu może wyrządzić szkodę osobie, środowisku lub firmie.
LO-1.1.2
Umieć rozróżnić przyczynę usterki od jej skutków.
LO-1.1.3
Podać powody tego, że testowanie jest niezbędne, opierając się na przykładach.
LO-1.1.4
Potrafić uzasadnić, że testowanie stanowi część zapewnienia jakości i podać przykłady tego, w jaki sposób testowanie przyczynia się do zwiększenia jakości.
LO-1.1.5
Wyjaśnić i porównać pojęcia: pomyłka, usterka, awaria oraz odpowiadające im pojęcia błąd i pluskwa, podając przykłady.
1.2. Czym jest testowanie
Celem podrozdziału jest wyjaśnienie koncepcji testowania - czynności i zadań składających się na testowanie oraz różnych celów testowania.
Dość typową interpretacją pojęcia testowania jest uznanie, iż testowanie to wykonywanie testów, czyli uruchamianie i weryfikacja działania produktu.
Definicja 1.5. Testowanie
Testowanie (ang. testing) - proces składający się z wszystkich czynności cyklu życia, zarówno statycznych, jak i dynamicznych; skoncentrowany na planowaniu, przygotowaniu i ewaluacji oprogramowania oraz powiązanych produktów w celu określenia, czy spełniają one wyspecyfikowane wymagania, oraz wykazania, że są one dopasowane do swoich celów i do wykrywania usterek (ISTQB/SJSI, 2013).
W rzeczywistości testowanie to o wiele więcej niż samo wykonywanie testów - to cały zestaw czynności występujących zarówno przed, jak i po wykonywaniu testów. Do tych czynności należą:
- planowanie testów, czyli ustalenie i organizacja czynności i zadań składających się na proces testowy;
- wybór warunków testowych, czyli określenie elementów będących podstawowym przedmiotem testów - innymi słowy, ustalenie, co będzie testowane;
- projektowanie i wykonywanie przypadków testowych, czyli rozwinięcie warunków testowych w przypadki testowe umożliwiające osiągnięcie pokrycia danego elementu;
Definicja 1.6. Przypadek testowy
Przypadek testowy (ang. test case) - zbiór danych wejściowych, wstępnych warunków wykonania, oczekiwanych rezultatów i końcowych warunków wykonania opracowany w określonym celu lub dla warunku testowego, jak wykonanie pewnej ścieżki programu lub zweryfikowanie zgodności z konkretnym wymaganiem (IEEE, 1990).
- sprawdzanie wyników wykonania testów, często powiązane z raportowaniem wyników oraz oceną testowanego systemu; czynność ta polega głównie na porównywaniu wyników rzeczywistych wykonania przypadków testowych z oczekiwanymi i raportowaniu niezgodności na tej podstawie; wyniki testów umożliwiają ocenę jakości testowanego produktu;
- monitorowanie postępu i nadzór nad testami; kontrola postępu testów jest niemożliwa bez monitorowania - czyli gromadzenia informacji o wykonanych pracach, ich wynikach i postępie w stosunku do ustalonego na etapie określania planu testów;
- ocena spełnienia kryteriów zakończenia - ustalenie gotowości do zakończenia czynności testowych; ocena ta odbywa się na podstawie ustalonych na etapie planowania testów kryteriów zakończenia w odniesieniu do wyników realizacji czynności testowych;
- kończenie i zamykanie testów (po zakończeniu fazy testów); po ukończeniu zaplanowanych na dany etap czynności testowych należy dokonać formalnego zamknięcia testów, może to obejmować sprawdzenie kryteriów zakończenia i upewnienie się, że wykonano wszystkie zaplanowane dla danej fazy czynności; podobne działania "kończące" wykonuje się również do zakończenia czynności testowych w całym projektcie.
Według programu ISTQB do testowania zalicza się także przeglądy dokumentacji i kodu źródłowego oraz analizę statyczną, które to czynności wchodzą w skład tzw. technik statycznych, czyli testów realizowanych bez uruchamiania kodu źródłowego oprogramowania.
Definicja 1.7. Przegląd
Przegląd (ang. review) - ocena produktu lub statusu projektu mająca na celu stwierdzenie rozbieżności od planowanych założeń i rekomendację usprawnień (IEEE, 2008).
Alternatywą są testy dynamiczne, wymagające uruchomienia oprogramowania, czyli testy realizowane poprzez weryfikację działającej aplikacji. Oba typy testów - dynamiczne i statyczne - umożliwiają wykrywanie wad (różnego rodzaju) i dostarczają informacji umożliwiających podjęcie czynności doskonalenia testowanego systemu oraz procesów rozwoju i testowania oprogramowania.
Samo testowanie, rozumiane jako cały proces, ma następujące cele:
- znajdowanie usterek - informowanie o jakości - lepiej znaleźć błąd wewnętrznie, niż żeby znalazł go klient czy użytkownik; usterka znaleziona podczas realizacji procesów wytwórczych to szansa na naprawę przed przekazaniem produktu do użytkowania, gdy ewentualne poprawki nie są już tak proste (i tanie);
- nabieranie zaufania do poziomu jakości - testowanie to systematyczne sprawdzanie różnych elementów i aspektów funkcjonowania oprogramowania; jeśli testy wykazują brak usterek, zaufanie do stabilności produktu się zwiększa - produkt został przecież sprawdzony przez profesjonalistów; jeśli testy ujawnią usterki - to również cenna informacja, usterka wykryta to usterka, którą można naprawić i tym samym dostarczyć odbiorcy produkt lepszej jakości;
- dostarczanie informacji potrzebnych do podejmowania decyzji - wyniki testów dostarczają precyzyjnej i mierzalnej informacji dotyczącej jakości testowanego obiektu, co umożliwia podejmowanie decyzji opartych na faktach i obiektywnych informacjach;
- zapobieganie defektom (np. weryfikacja podstawy testów przez projektowanie testów może zapobiec wprowadzeniu usterek do kodu) i awariom (np. poprzez wczesne przeglądy dokumentacji specyfikacji wymagań pomagają w przeciwdziałaniu pojawianiu się defektów w kodzie).
Różnorodność czynności testowych i wynikające z tego różne punkty widzenia powodują, iż można określić różne cele dla poszczególnych zadań testowych.
Definicja 1.8. Cel testu
Cel testu (ang. test objective) - przyczyna lub powód zaprojektowania i przeprowadzenia testu (ISTQB/SJSI, 2013).
Inne cele przyświecają testowaniu wytwórczemu: systematyczna weryfikacja poszczególnych składników systemu i wykrycie możliwie wielu awarii, inne testom akceptacji: potwierdzenie spełnienia wymagań i poprawnego działania systemu - co powinno być uwzględnione na etapie planowania czynności testowych i odpowiednio zakomunikowane interesariuszom.
Definicja 1.9. Wymaganie
Wymaganie (ang. requirement) - warunek lub umiejętność potrzebna użytkownikowi do rozwiązania problemu lub osiągnięcia celu, które system musi spełniać lub mieć, aby wypełnić założenia umowy, standardu, specyfikacji lub innego formalnego dokumentu (IEEE, 1990).
Przykład celów testowania znajduje się w tabeli.
Tabela 1.1. Przykład różnych celów testowania
Poziom testów
Cel
Testowanie wytwórcze (modułowe, integracyjne)
Weryfikacja składników oprogramowania
Wywołanie możliwie wielu awarii celem korekty usterek
Testowanie wytwórcze (systemowe)
Weryfikacja funkcjonowania całości oprogramowania
Wywołanie możliwie wielu awarii celem korekty usterek
Testowanie akceptacyjne
Potwierdzenie, że system działa tak, jak powinien
Weryfikacja spełnienia wymagań
Testowanie pielęgnacyjne
Weryfikacja poprawności działania systemu po wprowadzeniu zmian (testy regresji)
Testowanie produkcyjne
Ocena atrybutów systemu, takich jak niezawodność lub dostępność
Źródło: opracowanie na podstawie ISTQB, 2012
W temacie definicji testowania warto wspomnieć o kilku charakterystykach, które odróżniają testowanie od innych czynności wytwarzania. W organizacjach o niskim poziomie dojrzałości (TMMi Foundation, 2012) testowanie jest mylone z debagowaniem.
Definicja 1.10. Debagowanie
Debagowanie (ang. debugging) - proces wyszukiwania, analizowania i usuwania przyczyn awarii oprogramowania (ISTQB/SJSI, 2013).
Debagowanie to nie to samo, co testowanie. Testowanie dynamiczne może pokazać awarie wywołane przez usterki. Debagowanie to czynność programistyczna, która znajduje, analizuje i umożliwia usunięcie przyczyny awarii. Poprawność tak wykonanej poprawki weryfikują późniejsze testy potwierdzające (retesty) wykonywane przez testera. Odpowiedzialność za każdą z tych czynności jest zwykle inna - testerzy wykonują czynności testowe, a programiści debagują.
Co należy wiedzieć po przeczytaniu tego podrozdziału:
LO-1.2.1
Wskazać ogólne cele testowania.
LO-1.2.2
Podać przykłady celów testowania w różnych fazach cyklu życia oprogramowania.
LO-1.2.3
Wskazać różnice między testowaniem a debagowaniem.
1.3. Ogólne zasady testowania
Celem podrozdziału jest wyjaśnienie podstawowych zasad testowania oprogramowania.
1.3.1. Zasada 1 - testowanie ujawnia usterki
Testowanie może wykazać obecność usterek - jest to jeden z podstawowych celów testów. Nie może jednak dowieść, że oprogramowanie nie ma wad.
Realizacja czynności testowych zmniejsza prawdopodobieństwo występowania w oprogramowaniu nieujawnionych wcześniej defektów, lecz nie stanowi dowodu poprawności oprogramowania, nawet jeśli testy nie znajdują już żadnych awarii.
1.3.2. Zasada 2 - testowanie gruntowne jest niewykonalne
Definicja 1.11. Testowanie gruntowne
Testowanie gruntowne (ang. exhaustive testing) - podejście do testów, w którym zestaw testowy obejmuje wszystkie kombinacje wartości wejściowych i warunków wstępnych (ISTQB/SJSI, 2013).
Zasada ta mówi, iż przetestowanie wszystkich kombinacji wejść i warunków początkowych jest wykonalne tylko w niewielu przypadkach - gdy oprogramowanie jest bardzo małe, nie zawiera złożonych algorytmów itp. W rzeczywistości oprogramowanie jest zwykle bardzo złożone i obejmuje dziesiątki, jeśli nie setki czy tysiące funkcji i atrybutów niefunkcjonalnych. Przetestowanie wszystkich możliwych kombinacji byłoby niemożliwe - zwłaszcza w kontekście ograniczeń budżetowych i czasowych, w jakich funkcjonują projekty IT. Niemożliwe to pierwszy problem, drugim problemem jest brak uzasadnienia wykonywania wszystkich możliwych testów - wiele z nich można odrzucić jako niewnoszące większej wartości do oceny jakości produktu czy dotyczące niezmiernie rzadko stosowanych kombinacji, dla których głębokie testy nie mają uzasadnienia biznesowego.
Dlatego zamiast testowania gruntownego - niemożliwego w większości przypadków i nieefektywnego z punktu widzenia ekonomicznego - do ustalania zakresu i dokładności testów należy wykorzystać analizę ryzyka i priorytetyzację umożliwiające skoncentrowanie wysiłków testowych na tych czynnościach i obszarach, dla których testy przyniosą największą wartość.
1.3.3. Zasada 3 - wczesne testowanie
Aby wykryć usterki jak najwcześniej i tym samym zapobiegać awariom, testowanie powinno rozpoczynać się najszybciej, jak to możliwe - już od wczesnych etapów cyklu rozwoju oprogramowania. Zasada ta wynika z faktu, iż im później defekt zostanie znaleziony, tym trudniejsza i droższa jest jego naprawa. Tabela 1.2 przedstawia na to "dowód rzeczowy" - względny koszt naprawy defektu w zależności od fazy wykrycia.
Tabela 1.2. Względny koszt naprawy defektu w różnych fazach
Faza wprowadzenia defektu
Faza wykrycia defektu
Wymagania
Architektura
Implementacja
Testy systemowe
Wdrożenie
Wymagania
1
3
5-10
10
10-100
Architektura
-
1
10
15
25-100
Implementacja
-
-
1
10
10-25
Źródło: McConnell, 2004
W różnych etapach realizacji projektu testowanie powinno być nakierowane na spełnienie zdefiniowanych celów, np. weryfikacja testowalności wymagań w fazie analizy wymagań, kontrola spójności i kompletności projektu rozwiązania w fazie projektowania.
1.3.4. Zasada 4 - kumulowanie się błędów
Zasada ta odnosi się do obserwacji gęstości błędów w oprogramowaniu. Większość defektów znalezionych podczas testowania przed przekazaniem systemu do odbiorców lub powodujących awarie produkcyjne znajduje się w stosunkowo niewielkiej liczbie modułów. Można się tu posłużyć zasadą Pareto mówiącą, iż 80% skutków jest wynikiem wystąpienia 20% przyczyn.
Ponieważ pracochłonność testowania jest dzielona proporcjonalnie do spodziewanej oraz zaobserwowanej gęstości błędów w modułach, warto pokusić się o analizę spodziewanej gęstości błędów (np. na podstawie statystyk z wcześniejszych projektów), a następnie stale monitorować postęp i wyniki prac, by ocenić skuteczność prognoz i w razie potrzeby podjąć czynności korygujące - np. zmienić alokację wysiłku zgodnie z obserwowaną gęstością usterek.
1.3.5. Zasada 5 - paradoks pestycydów
Wielokrotnie powtarzane bez wprowadzania zmian testy przestają znajdować nowe usterki. Efekt ten nosi nazwę "paradoksu pestycydów" - czyli "uodparniania się" aplikacji na niezmieniane przypadki testowe. Aby uniknąć tego efektu, testy muszą być regularnie przeglądane i uaktualniane zgodnie z wynikami monitorowania postępu i rezultatów testów. Celem uzupełnienia standardowego zestawu testów i minimalizacji ryzyka pominięcia istotnych usterek można też stosować bardziej elastyczne techniki testów, np. testy eksploracyjne, zgadywanie błędów itd.
1.3.6. Zasada 6 - testowanie zależy od kontekstu
Testowanie może odnosić się do różnych produktów - stron internetowych, aplikacji desktopowych, mobilnych itd. W zależności od kontekstu inne będzie podejście do testowania, inne cele i stosowane techniki.
Przykład 1.3. Testowanie systemów krytycznych ze względu na bezpieczeństwo
Testowanie systemów krytycznych ze względu na bezpieczeństwo (ang. safety-critical systems) - w tym przypadku wiele wymagań dotyczących zarówno technik, jak i samego procesu testowania narzucanych jest przez standardy obowiązujące w danym sektorze, np. standard RTCA DO-178B/ED 12B Software Considerations in Airborne Systems and Equipment Certification dotyczący przemysłu lotniczego wskazuje na konieczność wykonania odpowiedniego rodzaju testów w zależności od krytyczności modułu poddawanego testom.
Tabela 1.3. Wymagania dotyczące pokrycia testowego w normie DO-178B/ED 12
Poziom krytyczności
Możliwy wpływ awarii
Wymagane pokrycie strukturalne
A. Katastroficzny
Uniemożliwienie bezpiecznego lotu i lądowania
Pokrycie warunków, decyzji i instrukcji
B. Ryzykowny/Poważny
Znaczne ograniczenie marginesu bezpieczeństwa lub możliwości funkcjonalnych
Pokrycie decyzji
instrukcji
C. Istotny
Znaczne ograniczenie marginesu bezpieczeństwa
Znaczne obciążenie personelu
Pokrycie instrukcji
D. Średni
Dyskomfort podróżnych potencjalnie powodujący urazy
Niewielkie ograniczenie marginesu bezpieczeństwa lub możliwości funkcjonalnych
Niewielki wzrost obciążenia personelu
Żadne
E. Bez efektu
Bez wpływu na możliwości samolotu
Bez wpływu na obciążenie personelu
Żadne
Źródło: RTCA DO-178B/ED 12B
1.3.7. Zasada 7 - mylne przekonanie o braku błędów
Testowanie może wykrywać usterki. Brak usterek nie oznacza jednak, iż produkt będzie funkcjonował prawidłowo. Nawet wykonane zgodnie z planem testy, zaplanowane i zaprojektowane zgodnie z najlepszymi zasadami sztuki, nie gwarantują braku błędów. Błędy te mogą być innego rodzaju niż "zwykłe" usterki rozumiane jako niezgodności ze stanem oczekiwanym - błędy mogą dotyczyć braku spełnienia oczekiwań docelowych odbiorców. Samo znajdowanie i naprawa usterek nie pomoże, jeżeli dostarczony produkt nie nadaje się do użytkowania w określonym kontekście lub nie spełnia wymagań i oczekiwań odbiorców. Innymi słowy - sama pozytywna weryfikacja produktu (czyli zgodność ze specyfikacjami) nie oznacza, iż automatycznie zagwarantowana jest pozytywna walidacja - zgodność z potrzebami odbiorców i wymaganiami docelowego użycia.
Co należy wiedzieć po przeczytaniu tego podrozdziału:
LO-1.3.1
Wyjaśnić siedem zasad testowania.
1.4. Podstawowy proces testowy
Celem podrozdziału jest opisanie czynności wchodzących w skład podstawowego procesu testowego.
1.4.1. Wprowadzenie
Jak już wcześniej wspomniano, na proces testowy składa się wiele czynności, zarówno tych związanych z bezpośrednim wykonywaniem testów, jak i czynności poprzedzających weryfikację produktu oraz czynności realizowane później. Dobrze zorganizowany proces testowy uwzględnia planowanie czynności testowych, opracowanie przypadków testowych i przygotowanie do ich wykonania oraz ocenę wyników.
Opracowany przez ISTQB podstawowy proces testowy składa się z następujących czynności:
- planowanie i nadzór nad testami;
- analiza i projektowanie testów;
- implementacja i wykonanie testów;
- ocena kryteriów zakończenia i raportowanie;
- czynności zamykające testy.
Czynności te, po doprecyzowaniu i uzupełnieniu, można przedstawić w postaci schematu.
Rysunek 1.4. Podstawowy proces testowy
Źródło: Akredytowane materiały szkoleniowe testerzy.pl "ISTQB Poziom Podstawowy (Foundation Level)" autorstwa R. Smilgin.
W praktyce czynności testowe niekoniecznie muszą być realizowane zgodnie z sugerowaną wcześniej kolejnością - często występują one jednocześnie lub nachodzą na siebie. Istotne jest to, by podstawowy proces testowy przyjęty w danej organizacji był dostosowany do kontekstu wytwarzanego systemu i samego projektu.
1.4.2. Planowanie i nadzór nad testami
Planowanie i nadzór nad testami to czynności kierownicze, wykonywane zwykle przez kierownika testów lub inną osobę odpowiedzialną za procesy testowe i sam projekt testowy.
Głównym celem planowania testów jest zdefiniowanie celów testowania i określenie czynności testowych potrzebnych do osiągnięcia tych celów i tym samym wypełnienie misji testowania. Planowanie testów powinno wynikać z zapisów polityki testów w danej organizacji, która określa ogólną misję i podejście do testowania.
Definicja 1.12. Polityka testów
Polityka testów (ang. test policy) - dokument wysokiego poziomu opisujący zasady, podejście i główne zadania organizacji dotyczące testowania (ISTQB/SJSI, 2013).
W ramach planowania testów powstaje plan testów - dokument, który można traktować jako plan projektu przedsięwzięcia testowego.
Definicja 1.13. Plan testów
Plan testów (ang. test plan) - dokument opisujący zakres, metody, zasoby oraz harmonogram zamierzonych czynności testowych. Określa m.in. elementy testowe, testowane cechy, zadania testowe, kto będzie te zadania wykonywał, stopień niezależności testerów, środowisko testowe, technikę projektowania testów oraz kryteria wejścia i wyjścia, przesłanki ich użycia, a także ryzyka wymagające ciągłego planowania. Jest to zapis procesu planowania testów (IEEE, 1998).
Plan taki opisuje zakres i podejście do testów w danym projekcie, wymagania dotyczące zasobów i harmonogramów, ryzyka itd. Istotną częścią planu testów jest określenie podejścia do testów, które będzie obowiązywało w danym projekcie. Opis podejścia może obejmować wskazanie poziomów testowania wraz z kryteriami wejścia i wyjścia dla poszczególnych poziomów.
Definicja 1.14. Kryterium wejścia
Kryteria wejścia (ang. entry criteria) - zbiór ogólnych i specyficznych warunków, których spełnienie jest wymagane do kontynuacji procesu dla określonego zadania, np. fazy testów. Celem kryterium wejścia jest ochrona przed rozpoczęciem zadania w sytuacji, gdy pociąga to za sobą więcej (zmarnowanych) nakładów pracy w porównaniu z nakładem pracy potrzebnym do osiągnięcia stanu spełnienia kryterium wejścia (Gilb & Graham, 1993).
Definicja 1.15. Kryterium wyjścia
Kryterium wyjścia (ang. exit criteria) - zbiór ogólnych i specyficznych warunków, uzgodnionych z udziałowcami, których spełnienie jest wymagane do oficjalnego zakończenia procesu. Celem kryterium wyjścia jest ochrona przed uznaniem zadania za ukończone w przypadku, gdy jakieś jego elementy nie są jeszcze w pełni wykonane. Kryteria wyjścia są stosowane jako argument przeciwko zakończeniu testów oraz do planowania, kiedy można to zrobić (Gilb & Graham, 1993). Kryteria wyjścia są znane również jako kryteria ukończenia.
Elementem planu jest też wskazanie testaliów, które będą tworzone bądź wykorzystywane w ramach realizacji czynności testowych.
Definicja 1.16. Testalia
Testalia (ang. testware) - wszystkie dokumenty i narzędzia (artefakty) wytworzone i używane podczas procesu testowania niezbędne do planowania, projektowania i wykonywania testów, takie jak dokumentacja, skrypty, wejścia, oczekiwane rezultaty, procedury, pliki, bazy danych, środowiska oraz każde dodatkowe oprogramowanie i narzędzia użyte podczas testowania (Fewster & Graham, 1999).
Druga z czynności "zarządczych" wskazana jako element podstawowego procesu testowego to nadzór nad testami, zwany też kontrolą testów. Jest to czynność realizowana podczas całego cyklu wytwarzania produktu i służąca głównie zapewnieniu zgodności wykonywanych prac z planem - lub zmianie planu w razie potrzeby. Przy ustalaniu formy czynności nadzoru nad testami należy uwzględnić to, że aby być w stanie nadzorować przedsięwzięcie testowe, należy stale monitorować postęp i wyniki testów celem porównania rzeczywistych danych z planem. W przypadku wystąpienia odchyleń od planu należy podjąć odpowiednie czynności korygujące umożliwiające wypełnienie misji i celów testowania mimo zaistniałych okoliczności.
1.4.3. Analiza i projektowanie testów
Analiza i projektowanie testów to czynności wykonywane zwykle przez testerów zgodnie z ustalonym na etapie planowania podejściem i przy użyciu określonych technik oraz narzędzi.
Nadrzędnym celem analizy i projektowania testów jest przekształcenie ogólnych, wysokopoziomowych celów testowania w konkretne warunki testowe i przypadki testowe.
Definicja 1.17. Warunek testowy
Warunek testowy (ang. test condition) - element lub zdarzenie modułu lub systemu, który może być zweryfikowany przez jeden lub więcej przypadków testowych, np. funkcja, transakcja, cecha, atrybut jakości lub element struktury (ISTQB/SJSI, 2013).
Analiza i projektowanie testów obejmuje w szczególności:
- przeglądanie podstawy testów (specyfikacji wymagań, raportów analizy ryzyka, architektury, projektu, specyfikacji interfejsów) celem opracowania warunków testowych oraz oceny testowalności podstawy testowania i przedmiotu testów;
Definicja 1.18. Podstawa testów
Podstawa testów (ang. test basis) - wszystkie dokumenty, z których można wywnioskować wymagania dla modułu lub systemu. Dokumentacja, na podstawie której oparte są przypadki testowe. Jeśli dokument może być zmieniony tylko poprzez formalną procedurę zmiany, to podstawa testu nazywana jest zamrożoną podstawą testu (Pol, et al., 2001).
- ustalenie wymaganego poziomu pokrycia dla poszczególnych elementów będących przedmiotem testowania;
- identyfikację i priorytetyzację warunków testowych na podstawie analizy elementów testowych, specyfikacji, zachowania i struktury oprogramowania;
- opracowanie przypadków testowych wysokiego poziomu i ich priorytetyzację;
Definicja 1.19. Pokrycie testowe
Pokrycie testowe (ang. test coverage) - stopień, wyrażany w procentach, w jakim zakresie zestaw testowy wykorzystał przedmiot pokrycia (ISTQB/SJSI, 2013).
- ustalenie wymagań odnośnie do danych testowych potrzebnych dla poszczególnych warunków oraz przypadków testowych;
Definicja 1.20. Dane testowe
Dane testowe (ang. test data) - dane, które istnieją (przykładowo w bazie danych) przed wykonaniem testu i które mają wpływ na testowany moduł lub system albo na które wywiera wpływ testowany moduł lub system (ISTQB/SJSI, 2013).
Tabela 1.4. Przykład macierzy śledzenia wymagań
Źródło: Zmitrowicz & Chrabski, 2014
- ustalenie wymagań odnośnie do środowiska testowego oraz identyfikację potrzebnej infrastruktury i narzędzi;
- opracowanie dwukierunkowego śledzenia między podstawą testów a warunkami czy przypadkami testowymi; relacje śledzenia zwykle tworzy się przy użyciu narzędzi do zarządzania testami, a w przypadku braku narzędzi można udokumentować pokrycie testowe za pomocą macierzy RTM (ang. Requirements Traceability Matrix); przykład RTM przestawia tabela 1.4.
1.4.4. Implementacja i wykonanie testów
Implementacja i wykonanie testów to kolejna czynność wykonywana przez testerów.
W ramach implementacji testów ustalana jest kolejność wykonywania przypadków testowych oraz określane są inne niezbędne do wykonania testów informacje, np. wymagane dane testowe czy specjalne wymagania proceduralne. Innymi słowy, tworzone są procedury i skrypty testowe.
Ponadto w ramach implementacji testów konfigurowane jest środowisko testowe, tak by było w pełni gotowe przed kolejną czynnością w procesie testowym, jaką jest wykonanie testów.
Definicja 1.21. Wykonanie testów
Wykonanie testów (ang. test execution) - proces przeprowadzenia testu na module lub systemie, w którego wyniku otrzymujemy rzeczywiste rezultaty (ISTQB/SJSI, 2013).
Implementacja testów obejmuje w szczególności
- uzupełnienie i priorytetyzację przypadków testowych, włącznie z identyfikacją danych testowych;
- przygotowanie i priorytetyzację procedur testowych, tworzenie danych testowych oraz (opcjonalnie) przygotowywanie jarzm testowych i opracowanie automatycznych skryptów testowych;
Definicja 1.22. Procedura testowa
Procedura testowa (ang. test procedure) - dokument określający ciąg akcji umożliwiający wykonanie testu. Znana także jako skrypt testowy lub manualny skrypt testowy (IEEE, 1998). Procedura testów znana jest również jako specyfikacja procedury testowej.
- opracowanie zestawów testów z procedur testowych w celu efektywniejszego wykonania testów;
Definicja 1.23. Zestaw testów
Zestaw testów (ang. test suite) - ciąg przypadków testowych, w którym warunki wyjściowe z jednego testu są używane jako warunki wejściowe do następnego testu. Znany także jako zbiór testów (ISTQB/SJSI, 2013).
- weryfikację poprawności konfiguracji środowiska testowego;
- weryfikację i w razie potrzeby uaktualnienie dwukierunkowego śledzenia między podstawą testów a warunkami/przypadkami testowymi.
Wykonanie testów obejmuje:
- uruchomienie procedur testowych w zaplanowanej kolejności, ręcznie lub za pomocą narzędzi do wykonywania testów;
- rejestrację wyników wykonania testów wraz z określeniem testowanego oprogramowania (np. wersji), narzędzi testowych oraz testaliów; przebieg i wyniki testów dokumentowane są w logu testów;
Definicja 1.24. Log testów
Log (dziennik) testów (ang. test log) - chronologiczny zapis szczegółów związanych z wykonaniem testów (IEEE, 1998).
- porównywanie wyników rzeczywistych z wynikami oczekiwanymi i raportowanie rozbieżności jako incydentów;
Definicja 1.25. Incydent
Incydent (ang. incident) - każde zdarzenie wymagające zbadania (IEEE, 1993).
- analizę incydentów w celu ustalenia ich przyczyny (usterki w kodzie, w danych testowych, w dokumencie testowym albo pomyłka w trakcie wykonywania testów);
- cykliczne powtarzanie czynności testowych jako rezultat akcji podjętych po stwierdzeniu rozbieżności - np. powtórne wykonanie testów niezaliczonych celem potwierdzenia korekty defektu (testowanie potwierdzające) czy powtórne wykonanie zestawu testów celem upewnienia się, czy zmiany wprowadzane do oprogramowania nie wprowadziły usterek lub czy nie ujawniły się inne wady (testowanie regresywne).
Definicja 1.26. Testowanie potwierdzające
Testowanie potwierdzające (ang. confirmation testing) - testowanie polegające na uruchomieniu przypadków testowych, które podczas ostatniego uruchomienia wykryły błędy, w celu sprawdzenia poprawności naprawy. Testowanie potwierdzające znane jest również jako retesty (ISTQB/SJSI, 2013).
Definicja 1.27. Testowanie regresywne
Testowanie regresywne (ang. regression testing) - ponowne przetestowanie uprzednio testowanego programu po dokonaniu w nim modyfikacji w celu upewnienia się, że w wyniku zmian nie powstały nowe defekty lub nie ujawniły się defekty w niezmienionej części oprogramowania. Testy takie są przeprowadzane po zmianach oprogramowania lub jego środowiska pracy (ISTQB/SJSI, 2013).
1.4.5. Ocena spełnienia kryteriów zakończenia i raportowanie
Ocena spełnienia kryteriów zakończenia i raportowanie wyników testów to zwykle zadania kierownika testów, który na podstawie informacji uzyskanych od testerów (w wyniku wykonywania testów) podejmuje decyzję dotyczącą zakończenia testów oraz raportuje wyniki wykonanych czynności testowych interesariuszom projektu.
Ocena spełnienia kryteriów zakończenia polega na ocenie stopnia wykonania testów zgodnie z ustalonymi na etapie planowania celami testowania. W przypadku realizacji przedsięwzięcia testowego w postaci faz czy poziomów ocena taka powinna być wykonywana dla każdego poziomu testowania celem weryfikacji kompletności zrealizowanych zadań i sprawdzenia gotowości przejścia do kolejnego etapu prac.
Ocena spełnienia kryteriów zakończenia obejmuje w szczególności:
- sprawdzenie, czy zostały spełnione kryteria zakończenia testów określone podczas planowania; odbywa się to na podstawie logów testów i danych uzyskanych z monitorowania postępu i wyników testów;
- w przypadku wątpliwości odnośnie do możliwości zakończenia testów - podjęcie decyzji dotyczącej wykonania dodatkowych testów, zmiany podejścia do testów, ewentualnie zmiany kryteriów zakończenia w przypadku braku możliwości spełnienia aktualnych warunków.
Po zakończeniu oceny należy opracować raport podsumowujący testy dla interesariuszy. Raport taki powinien dostarczać rzetelnej i obiektywnej oceny testowanego produktu, rekomendacje i ewentualne zalecenia dotyczące podjęcia dalszych czynności.
Definicja 1.28. Sumaryczny raport z testów
Sumaryczny raport z testów (ang. test summary report) - sumaryczny dokument przedstawiający działania testowe i ich rezultaty. Zawiera także ocenę testowanych elementów pod względem zgodności z kryteriami wyjścia (IEEE, 1998).
Warto zaznaczyć, iż raport podsumowujący testy jest podstawą podejmowania decyzji kierowniczych dotyczących już nie tyle procesów testowych, ile dalszych kroków związanych z przekazaniem produktu do kolejnego etapu wytwarzania bądź do użytkowania. Dlatego też jest szczególnie istotne, by przekazane w raporcie informacje były rzetelne i obiektywne oraz przedstawione w formie zrozumiałej dla interesariuszy.
1.4.6. Czynności zamykające testy
Po wykonaniu planowanych czynności testowych należy oficjalnie zakończyć przedsięwzięcie testowe. W ramach czynności zamykających testy gromadzi się dane z zakończonych czynności testowych: testalia, fakty i liczby umożliwiające np. wsparcie planowania w kolejnych projektach.
Czynności zamykające testy są zwykle wykonywane w ramach osiągnięcia określonych kamieni milowych projektu, takich jak: przekazanie systemu do odbiorcy, zakończenie (lub anulowanie) projektu testowego czy ukończenie serwisowego wydania oprogramowania.
Czynności zamykające testy obejmują w szczególności:
- sprawdzenie, czy dostarczono wszystkie planowane produkty i wykonano wszystkie zaplanowane czynności;
- obsługę raportów incydentów w stanie innym niż zamknięty: zamknięcie nieaktualnych zgłoszeń, utworzenie zgłoszeń zmian dla raportów otwartych;
- udokumentowanie akceptacji systemu i przekazanie określonych testaliów do zespołu serwisowego (np. przekazanie listy otwartych defektów);
- ukończenie i zarchiwizowanie testaliów, środowiska testowego i infrastruktury testowej do ponownego użycia w kolejnych projektach;
- analizę wniosków i doświadczeń celem ustalenia usprawnień i zmian (w tym proceduralnych) potrzebnych w przyszłych pracach i projektach;
- wykorzystanie zebranych informacji do podniesienia dojrzałości testowania (np. analiza przyczyn powstawania usterek celem wskazania obszarów wymagających poprawy).
Co należy wiedzieć po przeczytaniu tego podrozdziału:
LO-1.4.1
Podać pięć podstawowych czynności testowych i odpowiadające im zadania od planowania do zamknięcia testów.
1.5. Psychologia testowania
Celem podrozdziału jest wyjaśnienie podstawowych aspektów psychologicznych mających związek z realizacją czynności testowych.
Testowanie to praca polegająca na weryfikacji poprawności wyników pracy innych - dokumentacji, kodu czy gotowego produktu. Z tego powodu podejście do obiektu testów i sposób myślenia testera zwykle różni się zasadniczo od podejścia osób odpowiedzialnych za wytworzenie danych produktów prac. O ile autorzy są w stanie wykonać pewne czynności kontroli jakości w odniesieniu do własnych prac, o tyle celem zyskania niezależnej oceny jakości i wskazania potencjalnych problemów, które mogą być dla autora niewidoczne, zwykle angażuje się odpowiednio wyszkolonych, zawodowych testerów. Nosi to nazwę niezależności testowania.
Definicja 1.29. Niezależność testowania
Niezależność testowania (ang. independence of testing) to rozdzielenie odpowiedzialności, które sprzyja zapewnieniu obiektywności testowania (EUROCAE & RTCA, 1992).
Można wskazać następujące poziomy niezależności (od najniższego do najwyższego):
- testy zaprojektowane i wykonane przez osobę będącą autorem danego produktu prac - np. programista testujący własny kod;
- testy zaprojektowane i wykonane przez osobę niebędącą autorem, lecz wchodzącą w skład grupy zadaniowej - np. programista testujący kod kolegi;
- testy zaprojektowane i wykonane przez osobę z innego zespołu w organizacji (np. niezależnego zespołu testerów) lub przez specjalistów od testów (np. testów wydajnościowych lub użyteczności);
- testy zaprojektowane i wykonane przez osobę z innej organizacji lub firmy (np. testy zlecone lub certyfikacja przez niezależny organ certyfikujący).
Warto wspomnieć, że o ile testowanie niezależne może być wykonywane na dowolnym poziomie testów, a wysoki poziom niezależności może dawać o wiele skuteczniejsze wyniki w znajdowaniu defektów i awarii, o tyle w praktyce często wybiera się niższe poziomy niezależności ze względu na wymaganą do wykonania odpowiednich testów znajomość przedmiotu testów. Przykładem są testy modułowe wykonywane zwykle przez programistów.
Przy określaniu poziomu niezależności w danym projekcie istotne jest określenie jasnych celów testowania. Jeśli celem jest potwierdzanie poprawności działania oprogramowania, dobrym rozwiązaniem może być zaangażowanie reprezentantów użytkowników końcowych, którzy sprawdzą działanie aplikacji pod kątem spełnienia ich potrzeb. Jeśli celem jest wykrycie możliwie największej liczby awarii - warto rozważyć zaangażowanie profesjonalnego, niezależnego zespołu testerskiego.
Kolejnym ważnym aspektem nawiązującym do psychologii testowania jest kwestia odbioru pracy testera przez innych członków zespołu projektowego. Testowanie bywa postrzegane jako czynność destrukcyjna - testerzy wszak dążą do "zepsucia" produktu - i krytyka pracy autorów. Ważne jest, by uświadomić członkom zespołu cele i przesłanki testowania - zmniejszanie ryzyka, pomoc w wytworzeniu produktu dobrej jakości - oraz stworzyć atmosferę współpracy, a nie rywalizacji.
Testowanie nie jest prostą czynnością polegającą wyłącznie na "psuciu" czy żmudnym sprawdzaniu poszczególnych funkcji w systemie - to o wiele więcej, włączając w to umiejętność odpowiedniego planowania testów, projektowania testów z uwzględnieniem poziomu ryzyka, umiejętności skutecznej komunikacji i współpracy. Często bardzo istotne jest doświadczenie, na którym można oprzeć planowanie i przewidywanie potencjalnych obszarów problematycznych. Do tego dochodzi konieczność posiadania pewnych predyspozycji niezbędnych w pracy testera: ciekawości, krytycznego spojrzenia, profesjonalnego pesymizmu, przywiązywania wagi do szczegółów - aczkolwiek przy jednoczesnym uwzględnieniu priorytetów.
Bardzo istotnym elementem składającym się na kompetencje testera jest umiejętność komunikacji - wspomniany wcześniej problem dotyczący postrzegania testowania jako krytyki autora można rozwiązać poprzez odpowiednią komunikację usterek. Komunikację konstruktywną, która umożliwia zarówno poprawę wyników pracy innych, jak i samego sposobu pracy - a nie wytykanie błędów.
Podobna zasada odnosi się do komunikowania innych informacji - postępu czy ryzyka. Kluczem do sukcesu jest przyjęcie obiektywnego i opartego na wiarygodnych, weryfikowalnych informacjach sposobu przekazywania informacji - nie głoszenie własnych subiektywnych ocen, a przedstawianie faktów.
ISTQB wskazuje następujące sposoby na poprawienie komunikacji i relacji między testerami a resztą zespołu:
- zacznij od współpracy, a nie od wojny - przekaż jasno cele testowania w odniesieniu do ogólnych celów projektu: wyprodukowanie systemów o lepszej jakości;
- komunikuj informacje na temat produktu w sposób neutralny, skoncentrowany na faktach, bez krytykowania autora produktu;
- postaw się w pozycji drugiej strony - spróbuj zrozumieć, co druga osoba czuje i dlaczego reaguje tak, jak reaguje;
- upewnij się, że druga strona zrozumiała przekazaną informację;
- upewnij się, że rozumiesz uwagi drugiej strony.
Co należy wiedzieć po przeczytaniu tego podrozdziału:
LO-1.5.1
Wskazać czynniki psychologiczne, od których zależy sukces testowania.
LO-1.5.2
Wskazać różnice w nastawieniu testera i programisty.
1.6. Przykładowe pytania
Pytanie 1.1. LO-1.1.5
Który z następujących problemów obserwowanych podczas testowania lub pracy operacyjnej jest najprawdopodobniej awarią?
[A] Aplikacja przestała odpowiadać po tym, jak użytkownik wybrał opcję w okienku dialogowym.
[B] Do nowej wersji oprogramowania dołączono nieprawidłową wersję pliku z kodem źródłowym.
[C] Algorytm obliczeniowy użył nieprawidłowych danych wejściowych.
[D] Programista nieprawidłowo zinterpretował opis tekstowy działania algorytmu.
LO-1.1.5 Wyjaśnić i porównać pojęcia: pomyłka, usterka, awaria oraz odpowiadające im pojęcia błąd i pluskwa, podając przykłady.
Odpowiedź: A
Uzasadnienie: A opisuje ujawnienie się defektu w działającym oprogramowaniu - czyli awarię. B i C to usterki, D to pomyłka.
Pytanie 1.2. LO-1.1.5
Usterka to:
[A] Działanie człowieka powodujące postawanie nieprawidłowego wyniku.
[B] Błędna definicja danych w kodzie będąca wynikiem pomyłki twórcy oprogramowania.
[C] Odchylenie od spodziewanego zachowania oprogramowania.
[D] Przypadek testowy sprawdzający reakcję na błędne dane.
LO-1.1.5 Wyjaśnić i porównać pojęcia: pomyłka, usterka, awaria oraz odpowiadające im pojęcia błąd i pluskwa, podając przykłady.
Odpowiedź: B
Uzasadnienie: B opisuje wystąpienie defektu w kodzie - czyli usterkę. A to pomyłka, C to ogólna definicja błędu, D dotyczy przypadków testowych.
Pytanie 1.3. LO-1.2.1
Które z następujących zdań odzwierciedla najważniejszy cel zespołu testowego?
[A] Ustalenie, czy wykonano dostatecznie wiele testów modułów.
[B] Spowodowanie tylu awarii, ile jest możliwe, by można było zidentyfikować i naprawić usterki.
[C] Wykazanie, że zidentyfikowano wszystkie usterki.
[D] Udowodnienie, że pozostawione usterki nie spowodują żadnej awarii.
LO-1.2.1 Wskazać ogólne cele testowania.
Odpowiedź: B
Uzasadnienie: B opisuje jeden z celów testowania, jak to wyjaśniono w rozdziale Czym jest testowanie. A dotyczy pokrycia testów, nie celów. C i D są niemożliwe do realizacji - patrz zasady testowania.
Pytanie 1.4. LO-1.2.3
Jaka jest różnica między testowaniem a debagowaniem?
[A] Testowanie identyfikuje źródło usterki. Debagowanie analizuje awarie i wskazuje działania prewencyjne.
[B] Testowanie dynamiczne ujawnia awarie spowodowane usterkami. Debagowanie umożliwia wskazanie przyczyn występowania awarii w oprogramowaniu i ich usunięcie.
[C] Testowanie usuwa usterki. Debagowanie identyfikuje przyczyny występowania awarii.
[D] Testowanie dynamiczne zapobiega występowaniu przyczyn awarii. Debagowanie usuwa awarie.
LO-1.2.3 Odróżnienie testowania od debagowania.
Odpowiedź: B
Uzasadnienie: B opisuje prawidłowo istotę testowania i debagowania - jak to wyjaśniono w rozdziale Czym jest testowanie. A jest błędne, ponieważ testowanie nie wykrywa źródła usterki, C jest błędne, ponieważ testowanie nie usuwa usterek, D jest błędne ponieważ testowanie nie zapobiega bezpośrednio występowaniu przyczyn awarii.
Pytanie 1.5. LO-1.3.1
Które z następujących zdań najlepiej opisuje jedną z siedmiu podstawowych zasad testowania?
[A] Testy automatyczne są lepsze niż testy manualne, jeśli chcemy uniknąć testów gruntownych.
[B] Przy odpowiednim wysiłku i wsparciu narzędziowym testowanie gruntowne jest wykonalne dla każdego oprogramowania.
[C] Nie jest możliwe przetestowanie wszystkich kombinacji wejścia/wyjścia dla oprogramowania.
[D] Celem testowania jest wykazanie braku usterek.
LO-1.3.1 Wyjaśnić siedem zasad testowania.
Odpowiedź: C
Uzasadnienie: C prawidłowo parafrazuje zasadę testowania o nazwie Testowanie gruntowne jest niemożliwe. A jest błędne, ponieważ testy automatyczne nie są sposobem uniknięcia testów gruntownych, w zależności od kontekstu i możliwości mogą wręcz zwiększać pokrycie testów, B jest zaprzeczeniem zasady Testowanie gruntowne jest niemożliwe, D jest zaprzeczeniem zasady Testowanie ujawnia usterki.
Pytanie 1.6. LO-1.4.1
Które z następujących zadań będą wykonywane podczas analizy i projektowania testów według podstawowego procesu testowego?
[A] Ustalenie celów testowania.
[B] Przegląd podstawy testów.
[C] Opracowanie zestawów testowych z procedur testowych.
[D] Analiza wniosków z poprzednich projektów celem poprawy procesu testowego.
LO-1.4.1 Podać pięć podstawowych czynności testowych i odpowiadające im zadania od planowania do zamknięcia testów.
Odpowiedź: B
Uzasadnienie: B jest jedną z czynności analizy i projektowania testów wspomnianą w rozdziale Analiza i projektowanie testów. A dotyczy planowania testów, C - implementacji testów, D - czynności zamykających testowanie.
Pytanie 1.7. LO-1.4.1
Które z następujących zadań będą wykonywane podczas planowania testów według podstawowego procesu testowego?
[A] Ustalenie celów testowania.
[B] Przegląd podstawy testów.
[C] Opracowanie zestawów testowych z procedur testowych.
[D] Analiza wniosków z poprzednich projektów celem poprawy procesu testowego.
LO-1.4.1 Podać pięć podstawowych czynności testowych i odpowiadające im zadania od planowania do zamknięcia testów.
Odpowiedź: A
Uzasadnienie: A jest jedną z czynności planowania testów wspomnianą w rozdziale Planowanie i nadzór nad testami. B, C i D - jak w poprzednim pytaniu.
Pytanie 1.8. LO-1.5.1
Która z następujących sytuacji może prowadzić do konfliktów w zespole?
[A] Testerzy i recenzenci wykazują skrupulatność i są ukierunkowani na wykrywanie defektów.
[B] Testerzy i recenzenci posiadają wystarczające do wykrywania usterek kwalifikacje.
[C] Testerzy i recenzenci przedstawiają defekty jako krytykę autorów.
[D] Testerzy i recenzenci mają świadomość tego, że w oprogramowaniu i innych produktach pracy mogą być defekty, których autorzy nie znaleźli i nie naprawili.
LO-1.5.1 Wskazać czynniki psychologiczne, od których zależy sukces testowania.
Odpowiedź: C
Uzasadnienie: C może prowadzić do konfliktów w zespole, ponieważ defekty należy przedstawiać obiektywnie, jako problem oprogramowania czy innego artefaktu, a nie krytykę autorów. A prowadzi do realizacji celów testowania, B zwiększa skuteczność testowania, D dotyczy świadomości istnienia usterek - A, B i D to czynniki działające pozytywnie.
