Agenda
I. Jaka jest różnica między błędem, defektem a awarią?
II. Wstęp do procesu testowego
III. Poziomy testów
IV. Typy testów
Błąd, Defekt, Awaria
Błąd – ew. pomyłka, jest to działanie człowieka, które powoduje powstanie nieprawidłowego rezultatu, w przypadku programisty może nastąpić z powodu:
- Niewłaściwego zrozumienia funkcjonalności
- Błędu obliczeniowego, np. podczas implementacji funkcji
- Błędnej interpretacji wartości
- Błędy nie zawsze są wynikiem pomyłki programisty. Mogą one wynikać też z błędnej dokumentacji. Błąd wyeliminowany na tym poziomie nie prowadzi do awarii.
Błąd, Defekt, Awaria
Defekt – jest to wada produktu testowego, polegająca na niespełnieniu stawianych wymagań, może to być wynik błędu programisty wykonanego w kodzie. Z defektem mamy do czynienia m.in. gdy:
- W trakcie testów aktualny rezultat działania programu odbiega od rezultatu oczekiwanego
- Nastąpiło odchylenie od dokumentacji (każde odchylenie od dokumentacji jest defektem)
W przypadku testów możemy mieć do czynienia z wynikiem fałszywie pozytywnym wynikającym z błędów związanych z wykonaniem testów, defektów w danych testowych, środowisku lub innych testaliach.
Błąd, Defekt, Awaria
Awaria – zdarzenie, w którym moduł lub system zachowaniem odbiega od oczekiwanego rezultatu. Z awarią mamy do czynienia (ale nie zawsze), gdy kod zawierający defekt zostanie wykonany. Wpływ na wystąpienie awarii mogą też mieć czynniki zewnętrzne, tj.:
- Warunki pogodowe
- Promieniowanie
- Pole elektromagnetyczne
Jak im zapobiegać?
Dzięki odpowiednim technikom testowania stosowanych na odpowiednich poziomach i fazach cyklu wytwarzania oprogramowania częstotliwość wcześniej wymienionych można zmniejszyć poprzez:
- Zaangażowanie testerów we wczesnych fazach – przeglądach wymagań lub uszczegółowiania historyjek użytkownika pozwala wykryć defekty w dokumentacji
- Współpraca testerów z zespołem projektującym system pozwala na lepsze rozumienie działania systemu
- Współpraca z developerem w trakcie procesu tworzenia kodu pozwala na jego lepsze zrozumienie
Koszty błędów
Bardzo często defekty nie powodują poważnych konsekwencji – bywa, że jest to prosty błąd powodujący trudności z korzystania strony, czasem błąd może naliczyć nam zły zniżkę w sklepie. Jednakże są przypadki, kiedy defekt i wywołana przez niego awaria mogą skutkować utratą zaufania konsumentów do firmy lub zagrożenia życia. Od momentu powstania pierwszych maszyn liczących – raz defekt oprogramowania niemalże doprowadził do III Wojny Światowej. Gdyby nie rosyjski podpułkownik Pietrow i jego zdrowy rozsądek – odczyty rosyjskiego systemu wczesnego ostrzegania wykrył atak rakietowy z USA – jednakże Pietrow nie przeprowadził defensywy, gdyż stwierdził, że nie do końca wierzy odczytowi – według jego oceny – USA wystrzeliłoby zdecydowanie więcej rakiet. Decyzja, którą podjął, nie tylko okazała się słuszna, ale także uchroniła świat od kolejnej wojny. Jak się okazało, odczyt był błędny przez defekt w oprogramowaniu. System zinterpretował odbłyski słońca nad terenem USA jako wystrzelenie rakiet. System jak się później okazało zawierał bardzo dużo defektów, jednakże ZSRR w strachu przed atakiem nuklearnym podjęli decyzje o wdrożeniu go mimo wszystko. Decyzja ta nie tylko była nieodpowiedzialna, ale także potencjalnie mogła zmienić bieg historii świata jaki znamy. Można sobie wyobrazić, że w tych czasach także mamy do czynienia z podobnymi projektami i testerami, którzy biorą odpowiedzialność za testowanie takich systemów.
Koszt usuwania defektu w odniesieniu do faz wytwarzania oprogramowania
Koszty usunięcia defektu rosną wraz z postępem faz cyklu wytwarzania oprogramowania – jest to bardzo istotne, by wykrywać defekty w możliwie najszybszym czasie od momentu rozpoczęcia projektu. Ma to bardzo duże znaczenie we wszystkich modelach wytwarzania oprogramowania. Największe konsekwencje w czasie i budżecie projektu spowodowane jest niewykryciem odpowiednio wcześnie defektów w projektach typu Waterfall.
Reguła Pareto
Reguła Pareto odnosi się do założenia, że 20% przyczyn przynosi 80 procent skutków – w przypadku testowania – ma zastosowanie w 4 zasadzie testowania – Kumulowanie się błędów. 80 % defektów znajduje się w 20 % modułów.
Proces Testowy
Nie ma szablonowego procesu testowania oprogramowania, natomiast istnieją czynności testowe, które występują w procesie testowym, bez których proces ten nie odniósłby sukcesu. Każda jednostka prowadząca testy ma swoją strategię testowania, określa, które czynności testowe będą zaimplementowane oraz w jakiej fazie cyklu zostaną wdrożone. Wybór procesu testowego danego oprogramowania zależy od wielu czynników, tj.:
- Wymagane poziomy i typy testów
- Wymagania biznesowe
- Zobowiązania wynikające z prawa lub zawartych umów
- Ryzyko projektowe i produktowe
- Cykl życia oprogramowania
- Czas i budżet na wykonanie testów
- Normy
Czynności testowe
Formalny proces testowy nie zawsze występuje w organizacjach.
Typowo składają się na niego czynności:
- Planowanie
- Monitorowanie i nadzór testów
- Projektowanie
- Implementacja
- Wykonanie
- Ukończenie
Poziomy Testów
Poziomy testów to zgrupowane czynności testowe, które są organizowane i zarządzane razem.
Sylabus ISTQB na poziomie podstawowym wyróżnia następujące poziomy.
- Testy modułowe
- Testy Integracyjne
- Testy systemowe
- Testy akceptacyjne
Nie każda organizacja wykorzystuje wszystkie poziomy testów, a czasem posiada dodatkowe poziomy tj.: integracja systemów..
Testy modułowe
Według Sylabusa ISTQB zwane także testowaniem jednostkowym, testowaniem programu lub testowaniem komponentów.
Ten poziom testów skupia się na modułach, których przetestowanie można przeprowadzić w izolacji.
Ten typ testów najczęściej wykonywany jest przez programistów
Ze względu na oddzielne testowanie modułów może być konieczne użycie jarzm testowych, zaślepek, sterowników bądź wirtualizacji usług.
Specyfika izolacji tego poziomu testów powoduje, że testy takie można wykonać w różnej kolejności bez wpływu na wynik testu.
Cele testów modułowych
I. Zapobieganie przenoszeniu się defektów na kolejne poziomy testów
II. Budowanie zaufania do jakości
III. Ujawnianie defektów w module
IV. Weryfikacja czy dany moduł spełnia wymagania stawiane w specyfikacji
Charakterystyczne defekty i awarie
I. Niezgodna z dokumentacją funkcjonalność
II. Kłopoty związane z przepływem danych
III. Błędny kod i logika
Podstawa Testów
I. Szczegółowe projekty
II. Modele danych
III. Kod
IV. Specyfikacja modułu
Przedmioty Testów
I. Kod i struktura danych
II. Klasy
III. Moduł baz danych
IV. Jednostka, moduł lub komponent
Zaślepka a Sterownik
Zaślepka i sterownik są atrapami, które symulują działanie innych obiektów, które jeszcze nie istnieją. W przypadku zaślepki – testowany moduł wywołuje zaślepkę, natomiast w przypadku testowania modułu, który musi zostać wywołany zewnętrznie – używany jest do tego sterownik. Przykładem zaślepki może być aplikacja do zegarka sportowego i testowany jest tam moduł odpowiedzialny za czytanie tętna i wyświetlania go w aplikacji. Zaślepka będzie fragmentem kodu, który generuje przykładowe wartości tętna aby ocenić czy aplikacja w sposób poprawny generuje wykres tętna w czasie. Natomiast przykładem dla sterownika może być testowany moduł mikropłatności (aby nie płacić za rzeczy w grze) – możemy skorzystać ze sterownika-serwera, który otrzyma informację od modułu, że chcemy dokonać zakupu, który zwróci nam informację, że płatność przeszła i dzięki temu możemy sprawdzić, czy moduł działa w sposób prawidłowy, czyli czy rzecz, którą postanowiliśmy kupić jest po tej czynności dostępna. W przypadku testów modułowych nie interesuje nas komunikacja między modułem a sterownikiem, a to czy zapytanie (np. aplikacja – API) jest poprawnie przetworzone i wynik został otrzymany. Interesuje nas tylko funkcjonalność danego modułu a nie integracja z innym i ich komunikacja. Gdy w testach używamy zarówno sterowników jak i zaślepek – takie środowisko nazywa się jarzmem testowym.
Testy Integracyjne
Testy te w swoim zakresie skupione są na interakcjach między modułami bądź systemami.
Według Sylabusa ISTQB wyróżnić można dwa poziomy testowania integracyjnego:
I. Testy Integracji modułów – za ten poziom testów najczęściej odpowiadają programiści
II. Testy Integracji systemów – w przypadku tego poziomu główna odpowiedzialność spoczywa na testerach
Cele testów integracyjnych
I. Obniżenie ryzyka
II. Wykrywanie defektów zarówno w interfejsach jak i modułach lub systemach
III. Weryfikacja zgodności ze specyfikacjami
IV. Zapobieganie przenoszenia się defektów na kolejne poziomy testowania
Charakterystyczne defekty i awarie
I. Błędne lub brakujące dane lub niepoprawne ich kodowanie
II. Problemy z komunikacją między modułami
III. Brak komunikacji lub/i obsługi błędów wynikających z komunikacji modułów/systemów
IV. Nieprzestrzeganie przepisów odnośnie zabezpieczeń
Podstawa Testów
I. Przypadki użycia
II. Architektura z poziomu modułów lub systemów
III. Projekt
IV. Specyfikacje systemów/interfejsów
Przedmioty Testów
I. Infrastruktura
II. Baza Danych
III. API
IV. Interfejsy
V. Podsystemy
Testy Integracyjne – planowanie i strategia
- Strategie w oparciu o architekturę systemu
- Strategia zstępująca (TOP-DOWN) – Integracja modułu głównego z jego bezpośrednimi podrzędnymi aż do modułów najniższego rzędu.
- Strategia wstępująca (BOTTOM-UP) – integracja zaczyna się od modułów najniższego poziomu – zaczynamy od dołu i dołączamy kolejne moduły aż do modułu głównego.
- Strategia w oparciu o zadania funkcjonalne – integracja grupy modułów, która odpowiada za daną funkcjonalność oprogramowania
- Strategia w oparciu o przetwarzanie transakcji – testy ścieżki przepływu informacji w systemie – integracja modułów ścieżki a następnie testy pozostałych modułów
- Strategia w oparciu o specyfikę systemu – testy w oparciu np. o krytyczność modułów
- BIG BANG – integracja wszystkich modułów jednocześnie
Testy integracyjne – ćwiczenie
(ćwiczenie zostanie omówione na zajęciach)
Strategia zstępująca:
I: 1-2, 1-3
II: 2-4, 3-5, 3-6
III: 5-7, 6-7
Strategia wstępująca:
I: 5-7, 6-7
II: 2-4, 3-5, 3-6
III: 1-2, 1-3
Strategia w oparciu o przetwarzanie informacji:
I: 2-1, 1-3, 3-6 (integracja ścieżki przepływu informacji)
II: 2-4, 3-5, 5-7, 6-7 (integracja reszty modułów)
Testy Systemowe
- Skupienie się na działaniu zintegrowanego systemu i jego możliwościach, funkcjonalności w nim zawartych, a także zachowań niefunkcjonalnych.
- Jest to obszar działania testera
- Na tym poziomie testów często przeprowadza się testy jakości danych
- Na podstawie wyników testów systemowych podejmowane są decyzje odnośnie wdrożenia na „produkcję”
- Środowisko testowe na tym poziomie testów powinno w najbliższym stopniu przypominać środowisko produkcyjne
- Na tym poziomie testów powstaje najwięcej komunikatów od testerów odnośnie defektów, tzw. bugi
Cele testów systemowych
I. Obniżenie ryzyka
II. Wykrywanie defektów
III. Weryfikacja zgodności zachowań funkcjonalnych i niefunkcjonalnych ze specyfikacjami
IV. Zapobieganie przenoszenia się defektów do testów akceptacyjnych lub produkcji
Charakterystyczne defekty i awarie
I. Nieprawidłowe obliczenia
II. Nie spełniające wymagań zachowania funkcjonalne/niefunkcjonalne
III. Problemy z przepływem danych
IV. Niezgodność działania systemu z instrukcjami użytkownika
Podstawa Testów
I. Przypadki użycia
II. Historyjki użytkownika
III. Specyfikacje funkcjonalne/niefunkcjonalne
IV. Diagramy stanów
Przedmioty Testów
I. System podlegający testowaniu
II. Aplikacja
III. System operacyjny
IV. System łączący sprzęt i oprogramowanie
V. Konfiguracja systemu
Testy Akceptacyjne
Poziom testów, w którym następuje walidacja systemu – sprawdzenie, czy dany system spełnia wymagania użytkownika końcowego.
Testy całego systemu by ocenić możliwość wdrożenia – wykonywane przez klienta.
Testowanie akceptacyjne może być konieczne by spełnić wymagania stawiane przez prawo, normy lub standardy.
W idealnej sytuacji podczas testów akceptacyjnych klient nie powinien znaleźć defektów.
Formy testów akceptacyjnych:
- UAT (User Acceptance Testing) – testowanie akceptacyjne wykonywane przez użytkownika. Skupia się na ocenie, czy dany system może być użytkowany przez użytkowników i spełnia stawiane mu wymagania
- OAT (Operational Acceptance Testing) – testowanie wykonywane przez administratorów lub operatorów w środowisku pseudoprodukcyjnym. Skupiają się na testach instalacji, aktualizacji, usuwania oprogramowania, zarządzania użytkownikami.
- Testowanie Akceptacyjne zgodności z umową i prawem – sprawdzenie czy oprogramowanie spełnia wymagania wynikające z umowy lub prawa. W drugim przypadku możliwe jest wykonywanie tych testów przez testerów niezależnych w obecności organów nadzoru
Testy akceptacyjne mogą też być podzielone ze względu na miejsce i typ użytkownika wykonującym te testy:
- Testy ALFA – wykonywane są w siedzibie firmy przez testerów spoza zespołu lub klientów.
- Testy BETA – wykonywane są poza siedzibą firmy przez klientów.
Testy BETA mogą być poprzedzone testami ALFA, jednakże nie jest to konieczne.
Cele testów akceptacyjnych
I. Budowa zaufania do wytworzonego oprogramowania
II. Ocena czy system jest kompletny i działa w sposób prawidłowy
III. Weryfikacja zgodności zachowań funkcjonalnych i niefunkcjonalnych ze specyfikacjami
Charakterystyczne defekty i awarie
I. Błędnie zaimplementowana logika biznesowa
II. Nie spełniające wymagań stawianych w umowie lub/i prawie
III. Problemy z podatnościami zabezpieczeń, wydajnością, itp.
Podstawa Testów
I. Proces biznesowy
II. Wymagania biznesowe
III. Wymagania użytkowników
IV. Wymagania wynikające z prawa lub umowy
Przedmioty Testów
I. System podlegający testowaniu
II. Procesy biznesowe w kompletnym systemu
III. Formularz
IV. Raporty
Weryfikacja a Walidacja
- Weryfikacja – sprawdzenie czy oprogramowanie jest zgodne z wymaganiami określonymi w dokumentacji
- Walidacja – sprawdzenie czy wytworzone oprogramowanie spełnia wymagania i oczekiwania użytkownika końcowego
Typy Testów
- Testowanie funkcjonalne – CO oprogramowanie robi?
- Testowanie niefunkcjonalne – JAK oprogramowanie działa?
- Testowanie białoskrzynkowe
- Testowanie wynikające ze zmian
Testowanie Funkcjonalne
- Testy mające na celu ocenę poprawności działania określonych funkcji – czyli CO system robi i czy jest to zgodne z tym co robić powinien
- Wymagania funkcjonalne często przedstawiane są w formie specyfikacji wymagania biznesowego, przypadku użycia, historyjki użytkownika a nawet w formie nieudokumentowanej
- Mogą być wykonywanie na wszystkich poziomach testów
- Testy funkcjonalne są najbardziej znanym typem testów
Testowanie Niefunkcjonalne
Testy niefunkcjonalne mają na celu ocenę charakterystyk oprogramowania (wg normy ISO/IEC 25010) tj.:
- Wydajność
- Niezawodność
- Przenaszalność
- Pielęgnowalność
- Użyteczność
- Testy obciążeniowe i przeciążeniowe
Ten typ testów można wykonać na każdym poziomie testów
Testowanie Białoskrzynkowe
- Testy przygotowywane są na podstawie struktury wewnętrznej lub sposobu implementacji systemu
- W strukturze wewnętrznej możemy mieć do czynienia z kodem, architekturą, przepływami pracy/danych
- Do zaprojektowania i wykonania testów białoskrzynkowych może być potrzebna specjalistyczna wiedza lub umiejętności ze względu na potrzebę analizy kodu
- Testy białoskrzynkowe mogą być wykonywane na wszystkich poziomach testów
Testowanie związane ze zmianami
- Przeprowadzane, gdy zostały wprowadzone zmiany naprawiające defekty lub dodano/zmodyfikowano funkcjonalność w systemie
- Mają na celu potwierdzenie, że wykonane zmiany są poprawne i w tym samym czasie nie doprowadziły do niekorzystnych zmian
- Testy te dzielimy według ISTQB na:
- Testy potwierdzające – najczęściej nazywane retestami, polegają na wykonaniu ponownie testu, w którym uprzednio ujawniono defekt. Mają na celu potwierdzenie, czy dany problem został naprawiony.
- Testy Regresji – mają na celu sprawdzenie, czy zmiana w danej części kodu nie spowoduje przypadkowo zmiany zachowania w innych częściach kodu. Testy te wykonywane powinny być w momencie zmian dotyczących środowiska.
- Testy te można wykonywać na każdym poziomie testów