ISTQB PART V: Testowanie wsparte narzędziami (typy, użycie oraz wdrażanie narzędzi do organizacji)

Hejo,

Jednak nie pojechałem na ten basen. Uznałem, że dzisiaj raz na dobre skończę serię o ISTQB, żeby móc jutro zająć się co ciekawszymi Study Case pewnej znanej firmy IT : )

Ostatnia część z sylabusa ISTQB będzie traktować o testowaniu wspieranym narzędziami, ich typami, skutecznym użyciem, korzyściami z ich używania oraz sposobem wdrażania narzędzi do organizacji. Zaczynajmy!

Polecam obejrzeć również ten paru odcinkowy kurs. Rozjaśni w fajny sposób omawiany temat.

Kandydat potrafi podzielić różne typy narzędzi testowych według ich celów, według czynności w podstawowym procesie testowym oraz w cyklu życia oprogramowania. Potrafi również wyjaśnić samo pojęcie "narzędzia testowego" oraz cel wsparcia narzędzia testowego dla testów.

Narzędzia testowe mogą być wykorzystywane w jednej lub wielu czynnościach wspierających testowanie. Mogą to być:

- narzędzia używane wprost w testach takie jak narzędzia wspierające wykonanie testów, narzędzia generujące dane testowe i narzędzia porównujące wyniki,
- narzędzia wspomagające zarządzanie procesem testowym takie jak narzędzia do zarządzania testami, wynikami testów, danymi, wymaganiami, incydentami, defektami itd. oraz narzędzia raportujące i monitorujące wykonanie testów,
- narzędzia używane w rozpoznaniu (eksploracji), np. narzędzia monitorujące dostęp do plików przez aplikację,
- dowolne narzędzie wspierające testy (w takim znaczeniu arkusz kalkulacyjny jest również narzędziem testowym).

W zależności od kontekstu wsparcie narzędziowe dla testów może mieć jeden lub kilka poniższych celów:

- zwiększenie efektywności czynności testowych przez zautomatyzowanie powtarzających się zadań lub wsparcie dla czynności testowych wykonywanych ręcznie takich jak planowanie testów, projektowanie testów, raportowanie i monitorowanie testów,
- automatyzacja czynności, które wymagałyby wielkich nakładów, gdyby były wykonywanie ręcznie (np. testy statyczne),
- automatyzacja czynności, które nie mogą być wykonane ręcznie (np. testy aplikacji klient-serwer na wielką skalę),
- zwiększenie niezawodności testów (np. przez automatyzację porównywanie dużej ilości danych lub symulacje).

Termin "struktura testowa" jest również często używany przynajmniej w trzech znaczeniach:

- biblioteki testowe, które mogą zostać wykorzystane do zbudowania narzędzi testowych,
- typ projektu automatyzacji testów,
- ogólny proces wykonywania testów.

Klasyfikacja narzędzi testowych

Istnieje wiele narzędzi wspierających różne aspekty testowania. Narzędzia testowe można podzielić na wiele sposobów: według celów, na komercyjne, darmowe, o otwartym kodzie, shareware, według wykorzystywanej technologii etc.

Niektóre narzędzia wspierają jeden rodzaj czynności, inne mogą być przydatne w różnych czynnościach testowych. Narzędzia od jednego dostawcy, a szczególnie narzędzia, które zostały zaprojektowane do współdziałania, mogą zostać powiązane w jeden pakiet.

Niektóre typy narzędzi są inwazyjne w tym sensie, że samo narzędzie może wpływać na wynik rzeczywisty testu. Na przykład czasy uzyskane podczas testów wydajnościowych mogą się różnić, ponieważ narzędzie wykonuje dodatkowe instrukcje, albo można uzyskać różne wyniki pokrycia kodu. Zjawisko to jest nazywane efektem próbnika.

Niektóre z narzędzi testowych są przeznaczone bardziej dla programistów (np. w testach modułowych lub testach integracji modułów).

===============

>Wsparcie narzędziowe dla zarządzania testowaniem i testami

Narzędzia do zarządzania przydają się we wszystkich czynnościach testowych przez cały SLC.

Narzędzia do zarządzania testami

Narzędzia te dostarczają interfejsów do wykonywania zadań, śledzenia defektów oraz zarządzania wymaganiami, jak również wspierają analizę ilościową i raportowanie na temat obiektów testów. Wspierają również śledzenie powiązań pomiędzy obiektami testów i mogą posiadać własne mechanizmy zarządzania wersjami lub interfejs do zewnętrznych narzędzi zarządzających wersjami.

Narzędzia do zarządzania wymaganiami

Narzędzia te przechowują tekst wymagań, ich atrybuty (np. priorytet), generują unikalne identyfikatory i wspierają śledzenie powiązań pomiędzy wymaganiami, a poszczególnymi testami. Mogą one również pomóc w znalezieniu niespójnych lub brakujących wymagań.

Narzędzia do zarządzania incydentami

Narzędzia te przechowują i zarządzają raportami incydentów, to jest defektów, awarii, żądań zmian lub zauważonych problemów i anomalii. Pomagają też zarządzać cyklem życia incydentów, opcjonalnie mogą wspomagać analizy statystyczne.

Narzędzia do zarządzania konfiguracją

Chociaż nie są one w ścisłym tego słowa znaczeniu narzędziami testowymi, są konieczne do przechowywania i zarządzania wersjami testaliów (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 uzyte podczas testowania) i innego oprogramowania, a w szczególności gdy konfigurowane jest więcej niż jedno środowisko sprzętowo-programowe.

===================================

>Wsparcie narzędziowe dla testów statycznych

Narzędzia wspierające testy statyczne stanowią opłacalny sposób na znajdowanie większej ilości defektów we wcześniejszych fazach życia oprogramowania.

Narzędzia wspierające przeglądy

Wspomagają one proces przeglądu, listy kontrolne, wytyczne dla przeglądów i są wykorzystywane do przechowywania i komunikowania komentarzy z przeglądów, raportów defektów oraz pracochłonności. Mogą również wspierać przeglądy on-line, co jest przydatne, gdy zespół jest duży lub rozproszony geograficznie.

Narzędzia do analizy statycznej

Narzędzia te pomagają programistom i testerom jeszcze przed testami dynamicznymi przez wymuszenie standardów kodowania (włącznie z bezpiecznym programowaniem), analizę struktur i zależności. Mogą również pomóc w planowaniu i analizie ryzyka przez dostarczanie metryk kodu.

Narzędzia do modelowania

Narzędzia te używane są w walidacji modeli oprogramowania (np. fizycznego modelu danych w bazach relacyjnych) do wymienienia niezgodności i wyszukiwania defektów. Narzędzia te pomagają też często w generowaniu przypadków testowych z modeli.

===================================

> Wsparcie narzędziowe dla specyfikacji testów

Narzędzia do projektowania testów

Narzędzia te wykorzystywane są do generowania wejść do testów, wykonywalnych testów lub wyroczni testowych (źródło dostarczające oczekiwanych rezultatów umożliwiające porównanie ich z otrzymanymi rezultatami. Wyrocznią może być istniejący system (np. dla benchmarków), podręcznik użytkownika, wiedza testera, ale nie może być nią kod.)z wymagań, graficznych interfejsów użytkownika, modeli projektowych lub kodu.

Narzędzia do przygotowywania danych testowych

Przetwarzają bazy danych, pliki lub transmisję danych by uzyskać dane do wykorzystania podczas testów. Korzyścią ich stosowania jest to, że dane produkcyjne przeniesione na środowisko testowe są dla ochrony szyfrowane.

===================================

> Wsparcie narzędziowe dla wykonania testów oraz logowania

Narzędzia do wykonania testów

Umożliwiają automatyczne lub półautomatyczne wykonanie testów z wykorzystaniem zapisanych wejść i oczekiwanych wyników, poprzez użycie języka skryptowego, a także zwykle tworzą log testowy dla każdego przebiegu testów. Mogą one zostać również użyte do nagrania testów, zwykle też wykorzystują język skryptowy lub konfigurację opartą na GUI do parametryzowania danych lub dostosowywania testów na inne sposoby.

Jarzma testowe/struktury do testów jednostkowych

Wspomagają testy komponentów lub części systemu przez symulację środowiska, w którym element testowy będzie działała, dostarczając makiety (sterowniki testowe i zaślepki)

Komparatory testowe

Znajdują różnice pomiędzy plikami, bazami danych oraz wynikami testów. Narzędzia wspomagające wykonywanie testów zwykle zawierają komparatory dynamiczne ale porównania po wykonaniu testów mogą być dokonywane przez odrębne narzędzia. Komparator testowy może wykorzystać wyrocznię testową szczególnie w przypadkach, gdy jest zautomatyzowany.

Narzędzia mierzące pokrycie

Narzędzia te w sposób inwazyjny lub nieinwazyjny mierzą odsetek określonych struktur kodu, które zostały pokryte przez zbiór testów.

Narzędzia do testowania zabezpieczeń

Narzędzia te oceniają cechy oprogramowania związane z zabezpieczeniem. Wchodzi w to ocena zdolności oprogramowania do ochrony poufności danych, spójności, uwierzytelniania, autoryzacji, dostępności oraz niezaprzeczalności. Narzędzia do testowania zabezpieczeń są zwykle związane z konkretną technologią, platformą i celem.

=====================================

> Wsparcie narzędziowe dla wydajności i monitorowania

Narzędzia do analizy dynamicznej

Znajdują usterki, które ujawniają się jedynie podczas działania oprogramowania, takie jak zależności czasowe lub wycieki pamięci. Narzędzia tego typu są zwykle używane podczas testów modułowych lub testów integracji modułów oraz podczas testów warstw pośrednich.

Narzędzia do testów wydajnościowych/narzędzia do testów obciążeniowych/narzędzia do testów przeciążeniowych

Raportują oraz monitorują zachowanie systemu w różnych zasymulowanych warunkach użytkowania uwzględniających liczbę równolegle pracujących użytkowników, ich wzorzec aktywacji, częstość i względny procent transakcji. Symulacja obciążenia jest uzyskiwana przez utworzenie wirtualnych użytkowników wykonujących wybrany zbiór transakcji, rozproszonych na wiele maszyn testowych, które są powszechnie nazywane generatorami obciążenia.

Narzędzia do monitorowania

Bezustannie analizują, weryfikują i raportują wykorzystanie konkretnych zasobów systemowych i ostrzegają o możliwych problemach w obsłudze żądań.

======================================

> Wsparcie narzędziowe dla różnych obszarów zastosowań

Ocena jakości danych

Dane stanowią centrum wielu projektów, takich jak projekty konwersji/migracji danych, czy aplikacje takie jak hurtownie danych, a ich krytyczność i wielkość może się różnić. W takich okolicznościach musza zostać użyte narzędzia do oceny jakości danych do przejrzenia i sprawdzenia konwersji danych oraz reguł migracji, po to żeby zapewnić że przetworzone dane są poprawne, kompletne i zgodne ze zdefiniowanymi standardami.

=====================================

Kandydat potrafi opisać krótko potencjalne korzyści oraz ryzyko automatyzacji testów oraz wspierania testów narzędziami. Pamięta specjalne uwarunkowania dla narzędzi wspierających wykonywanie testów, analizę statyczną oraz zarządzanie testami.

Każdy typ narzędzia może wymagać wykonania dodatkowego wysiłku do osiągnięcia prawdziwych i trwałych korzyści. Z używaniem narzędzi wiążą się potencjalne korzyści i możliwości ale wiążę się też z tym pewne ryzyko.

Potencjalnymi korzyściami z używania narzędzi są:
- zredukowana zostaje powtarzająca się praca,
- zwiększa się spójność i powtarzalność,
- ocena jest obiektywna,
- łatwiejszy jest dostęp do danych o testach i testowaniu.

Ryzyko związane z narzędziami do testowania obejmuje:

- nierealistyczne oczekiwania od narzędzia,
- niedoszacowanie czasu, kosztów oraz pracochłonności wdrożenia narzędzia,
- niedoszacowanie czasu i pracochłonności potrzebnych do osiągnięcia znaczących i trwałych korzyści z narzędzia,
- niedoszacowanie pracochłonności utrzymania artefaktów testowych,
- zbytnie poleganie na narzędziu,
- lekceważenie zależności i problemów z współpracą krytycznych narzędzi takich jak narzędzia do zarządzania wymaganiami, do kontroli wersji, do zarządzania incydentami etc.,
- słaba reakcja dostawcy w ramach wsparcia, nowych wersji oraz poprawiania usterek,
- ryzyko wstrzymania projektu dla narzędzia darmowego/open-source,

=====================================

> Specjalne uwagi dla niektórych typów narzędzi

Narzędzia do wykonywania testów

Narzędzia do wykonywania testów uruchamiają skrypty zaprojektowane tak, aby zaimplementować testy przechowywane elektronicznie. Ten typ narzędzi często wymaga wykonania znaczącej ilości pracy, zanim zostaną osiągnięte istotne korzyści.

Nagrywanie akcji wykonywanych przez testy wydaje się być atrakcyjne ale nie skaluje się do dużej liczby zautomatyzowanych skryptów testowych. Nagrany skrypt jest liniową reprezentacją z konkretnymi danymi i akcjami będącymi częścią każdego skryptu. taki typ skryptu może okazać się niestabilny, gdy wystąpią niespodziewane zdarzenia.

Testowanie sterowane danymi wydziale wejścia testowe (dane testowe), zwykle do arkusza kalkulacyjnego i używa bardziej ogólnego skryptu testowego, który może odczytać dane wejściowe i wykonać ten sam skrypt dla różnych danych. Testerzy, którzy nie znają języków skryptowych mogą wtedy tworzyć dane testowe dla tych predefiniowanych skryptów.

Istnieją też inne techniki wykorzystywane w testowaniu sterowanymi danymi, w których zamiast stałych danych zapisanych w arkuszu kalkulacyjnym dane są generowane przy użyciu algorytmów sterowanych parametrami konfigurowalnymi w czasie ich działania i podanymi aplikacji. Na przykład, aby uzyskać powtarzalność, narzędzie może używać algorytmu generującego przypadkowe identyfikatory użytkowników, który jest inicjowany stałą wartością.

W podejściu sterowanym słowami kluczowymi arkusz kalkulacyjny zawiera słowa kluczowe opisujące akcje do wykonania oraz dane testowe. Testerzy mogą w takim przypadku definiować testy przy użyciu słów kluczowych, które zostają dostosowane do testowanej aplikacji.

Techniczna znajomość języków skryptowych jest konieczna przy każdym z wyżej wymienionych podejść.

Niezależnie od tego którakolwiek z technik skryptowych zostanie użyta oczekiwane wyniki dla każdego testu muszą być przechowywane do późniejszych porównań.

Narzędzia do analizy statycznej

Gdy narzędzia do analizy statycznej zostają użyte w kodzie źródłowym mogą wymusić stosowanie się do standardów kodowania, ale takie narzędzie zostanie użyte na kodzie już istniejącym i może generować dużą liczbę komunikatów. Ostrzeżenia nie powodują zatrzymania kompilacji kodu ale powinny być zaadresowane tak, żeby utrzymanie kodu było w przyszłości łatwiejsze.

Narzędzia do zarządzania testami

Narzędzia do zarządzania testami musza się komunikować z innymi narzędziami lub arkuszami kalkulacyjnymi w celu dostarczenia użytecznej informacji w formacie, który najbardziej pasuje do potrzeb organizacji.

=================================


Kandydat potrafi wymienić główne zasady wprowadzania narzędzi do organizacji. Potrafi wymienić cele dowodu słuszności pomysłu w ocenie narzędzia oraz cele fazy pilotażowej we wdrażaniu tego narzędzia. Uznaje, że poza samym zakupem narzędzia potrzebne jest też dobre wsparcie w jego użyciu.

Główne aspekty do wzięcia pod uwagę podczas wyboru narzędzia dla organizacji to:

- ocena dojrzałości organizacji, mocnych i słabych stron oraz identyfikacja możliwości doskonalenia procesu testowania wspierającego narzędziami,
- ocena według jasnych wymagań i obiektywnych kryteriów,
- wykonanie dowodu słuszności pomysłu (proof-of-concept) z użyciem narzędzia testowego po to, żeby zbadać czy jest ono skuteczne dla danego testowanego oprogramowania w ramach istniejącej infrastruktury,
- ocena dostawcy lub firm udzielających wsparcia w przypadku narzędzi komercyjnych,
- identyfikacja wymagań wewnętrznych na doradztwo i szkolenia w użyciu narzędzia,
- ocena potrzeb szkoleniowych z uwzględnieniem obecnych umiejętności automatyzacji testów przez zespół testowy,
- szacowanie stosunku korzyści do kosztów na podstawie konkretnego przypadku biznesowego.

Wdrażanie wybranego narzędzia w organizacji zaczyna się od projektu pilotażowego, który ma następujące cele:

- szczególe zapoznanie się z narzędziem,
- ocena czy i jak narzędzia pasuje do obowiązujących procesów i praktyk oraz ustalenie, co ewentualnie należałoby zmienić,
- ustalenie standardów użycia, zarządzania, przechowywania oraz pielęgnacji narzędzia oraz artefaktów testowych,
- ocena czy korzyści zostaną osiągnięte przy rozsądnych kosztach.

Czynnikami wpływającymi na sukces wdrożenia narzędzia w organizacji są:
-stopniowe wdrażanie narzędzia w pozostałej części organizacji,
- adaptacja i udoskonalenie procesu tak, aby pasował do sposobu używania narzędzia,
- zapewnienie szkoleń i doradztwa nowym użytkownikom,
- zdefiniowanie wytycznych co do użycia narzędzia,
- wdrożenie sposobu na zbieranie użytecznych oraz osiąganych korzyści,
- zapewnienie wsparcia dla zespołu testowego w użyciu danego narzędzia,
- zbieranie wniosków z wykorzystania narzędzia przez wszystkie zespoły.

===================================

Uff, to już wszystko. Tak, praktycznie sam własnoręcznie przeleciałem przez ISTQB pisząc to wszystko (promise, nie było kopiuj-wklej) i jednocześnie utrwalając wiedzę. Mam nadzieję, że przyda się to Wam tak samo, jak przyda się mi :) Z czasem stworzę swoją interpretację ISTQB, bardziej przystępną i popartą konkretnymi przykładami oraz praktyką ale na to musicie poczekać. Nie mam jeszcze odpowiedniej ilości doświadczenia, by móc rozpracować ISTQB w taki sposób, w jaki bym chciał :)

Dziękuję, trzymajcie się!

F.

ISTQB PART IV: Zarządzanie testowaniem (organizacja, planowanie, szacowanie, monitorowanie, konfiguracja testów)

Hejka,

Dzisiaj pomówimy sobie o logistyce zarządzania testowaniem. Jak zawsze teoria będzie przedstawiać sytuacje idealną, niemniej uważam, że jest tutaj wiele prawd, które pozwolą przeprowadzić rzetelne, ekonomiczne (czas, $$) testy, które będą przede wszystkim niezależne, przejrzyste dla teamu oraz będą posiadać konkretne cele. Zacznijmy zatem od ogółów i powoli przenosić będziemy się do szczegółu.

Kandydat uznaje ważność testowania niezależnego. Potrafi wyjaśnić korzyści, jak i wady niezależnego testowania w organizacji. Uznaje również potrzebę włączenia różnych członków zespołu podczas tworzenia zespołu testerskiego oraz pamięta zadania lidera testów oraz testera.

Skuteczność wykrywania usterek w testach i przeglądach może zostać podniesiona przez zaangażowanie niezależnych testerów. Niezależność może (lub nie) występować w różnych wariantach:

- brak niezależnych testerów - programiści testują swój własny kod (brak jakiejkolwiek zależności),
- niezależni testerzy wewnątrz zespołu projektowego testują kod,
- niezależny zespół testowy lub grupa testerów wewnątrz organizacji podlegająca kierownikowi projektu testuje kod,
- niezależni testerzy z departamentów biznesowych lub społeczności użytkowników testują kod,
- niezależni specjaliści od określonych typów testów testują kod,
- niezależni testerzy, którzy zostali wynajęci lub są na zewnątrz organizacji (maksymalna niezależność).

W projektach dużych, złożonych lub przy wytwarzaniu aplikacji krytycznych ze względu na bezpieczeństwo, zwykle najlepiej mieć kilka poziomów testów, z których niektóre lub wszystkie wykonywane są przez niezależnych testerów. Programiści mogą uczestniczyć w testach, szczególnie na niższych poziomach ale ich brak obiektywności często ogranicza skuteczność.

Korzyści z niezależności to przede wszystkim świeże spojrzenie na software bez żadnych uprzedzeń, niezależny tester może również zweryfikować założenia poczynione podczas specyfikacji i implementacji systemu.

Wady niezależności są typowe i są jej następstwem t.j. izolacja od deweloperów oraz obwinianie testerów jako tych złych, którzy opóźniają release poprzez 'wąskie gardło'. Tak, obwiniają deweloperzy. Teraz już rozumiecie, dlaczego ważnym jest kodeks etyczny testera, komunikatywność, uśmiech i ogólnie dobra atmosfera w pracy? : )

Zadania związane z testowaniem mogą być pełnione przez testerów lub też przez kierowników, menadżerów jakości, programistów etc.

Zadania lidera testów oraz testera

Czasem lider testów nazywany jest po prostu kierownikiem (umówmy się, mówmy mu po imieniu) testów, bądź ich koordynatorem. Rolę lidera testów może pełnić kierownik projektu, kierownik zespołu wytwórczego, kierownik zapewnienia jakość bądź kierownik zespołu testowego (co zdarza się najczęściej). W większych projektach wyróżnić możemy dwa stanowiska: lidera oraz kierasa testów. Lider planuje, monitoruje i kontroluje zadania testowe, a tester testuje. Wymienię teraz parę zadań lidera, jak i testera, by mieć clue sytuacyjne (w projektach nigdy nie wchodzimy sobie w swoje zadania bądź kompetencje bez konsultacji z kierownikiem):

typowe zadania lidera testów to m.in.:

- koordynowanie strategii oraz planów testów z kierownikami projektu i innymi zainteresowanymi,
- tworzenie oraz przeglądanie strategii testów w projekcie oraz polityki testowania w organizacji,
- planowanie testów, uwzględniając ich kontekst oraz rozumiejąc cele testów i ryzyko, włącznie z wyborem podejścia do testów, szacowaniem czasu, pracochłonności i kosztów testowania, zdobywaniem zasobów, definiowaniem poziomów testów, cykli testowych oraz planowaniem zarządzania incydentami,
- inicjowanie specyfikacji, przygotowania, implementacji i wykonania testów, monitorowanie ich wyników, sprawdzenia kryteriów zakończenia,
- sporządzanie raportów podsumowujących testy bazując na informacjach zebranych podczas testów,

typowe zadania testera to i.in.:

- przeglądanie i wnoszenie wkładu do planów testów,
- analiza, przegląd oraz ocena wymagań użytkownika, specyfikacji oraz modeli ze szczególnym uwzględnieniem testowalności,
- tworzenie specyfikacji testów,
- współtworzenie środowiska testowego,
- przygotowywanie i pozyskiwanie danych testowych,
- implementacja testów na wszystkich poziomach, wykonanie i logowanie testów, ocena wyników oraz dokumentowanie odchyleń od oczekiwanych wyników,
- automatyzacja testów (może być wspierana przez programistę),
- pomiar wydajności modułów i systemów,
- przeglądanie testów wytworzonych przez innych.

Ważne jest, aby wiedzieć, że na różnych poziomach testów te same osoby mogą pełnić różną rolę. Np. na poziomie modułowym oraz integracyjnym testerami zwykle są programiści. na poziomie testów akceptacyjnych eksperci biznesowi, a testerami w produkcyjnych testach akceptacyjnych - operatorzy.

==============



Kandydat rozpoznaje różne poziomy i cele planowania testów. Potrafi omówić krótko cel i zawartość planu testów, projektu testów, procedury testowej zgodnie ze standardem dokumentacji testowania oprogramowania. Rozróżnia również odmienne podejścia do testowania, takie jak analityczne, oparte na modelach, metodyczne, zgodne z procesem lub standardem, dynamiczne/heurystyczne, konsultatywne oraz regresywne. Odróżnia planowanie testów systemu od harmonogramowania ich wykonania. Potrafi napisać harmonogram wykonania testów dla danego zbioru przypadków testowych, uwzględniając ich priorytety oraz zależności logiczne i techniczne. Potrafi wymienić czynności przygotowania i wykonania testów, które należy wziąć pod uwagę przy planowaniu. Pamięta typowe czynniki, które mają wpływ na pracochłonność testowania. Odróżnia od siebie dwa koncepcyjnie odmienne podejścia do szacowania: podejścia bazujące na metrykach i podejścia wykorzystujące ekspertów. Potrafi rozpoznać i uzasadnić odpowiednie kryteria wejścia oraz zakończenia konkretnych poziomów testowania oraz grup przypadków testowych.

Na planowanie testów wpływ ma polityka testowania w organizacji, zakres samych testów, ich cele, ryzyko, ograniczenia, krytyczność, testowalność oraz dostępność zasobów. Logicznie - im dłużej trwa planowanie projektu u testów, tym więcej informacji jest dostępnych i tym więcej szczegółów może być włączone do planowania.

Planowanie testów jest czynnością stałą i wykonuje się je dla wszystkich procesów i zadań SLC.

Informacje zwrotne z czynności testowych są używane do wykrywania zmieniających się ryzyk, tak, że planowanie może zostać dopasowane do bieżącej sytuacji w projekcie.

Czynności związane z planowaniem testów

- ustalenie zakresu i ryzyka oraz zidentyfikowanie celów testowania,
- zdefiniowanie ogólnego podejścia od testowania włącznie z definicją poziomów testów oraz kryteriów wejścia i zakończenia,
- integrowanie i koordynowanie zadań testowych z innymi zadaniami SLC,
- podejmowanie decyzji co testować, którym rolom będą przypisane które zadania testowe,
- harmonogramowanie analizy i projektowania testów oraz implementacji i wykonania oceny testów,
- przydzielanie zasobów do zadań testowych,
- definiowanie ilości, poziomu szczegółowości, struktury oraz wzorców do dokumentacji testowej,

! Kryteria wejścia

Definiują one warunku pozwalające na rozpoczęcie testów na początku poziomu testów lub gdy zbiór testów jest gotowy do wykonania.

Kryteria wejścia zwykle mogą zawierać następujące zagadnienia:
- dostępność i gotowość środowiska testowego,
- gotowość narzędzi testowych w środowisku testowym,
- dostępność testowalnego kodu,
- dostępność danych testowych

! Kryteria zakończenia

Celem kryteriów zakończenia jest zdefiniowanie momentu zakończenia testów na danym poziomie testów lub gdy zbiór testów osiągnął cel.

Typowo kryteria zakończenia mogą składać się z:
- miar staranności, takich jak pokrycie kodu, funkcjonalności lub ryzyka,
- estymat gęstości błędów lub miar zawodności,
- kosztu,
- istniejącego ryzyka, takiego jak niepoprawione usterki lub brak pokrycia pewnych obszarów,
- harmonogramów np. zdefiniowanych na podstawie czasu do wypuszczenia produktu na rynek.

!Szanowanie testów

Istnieją dwa podejścia do szacowania pracochłonności testów:

> podejście oparte na metrykach - szacowanie pracochłonności testów bazując na pomiarach minionych lub podobnych projektów lub bazujące na typowych wartościach,

> podejście oparte na ekspertach - szacowanie zadań przez ich przyszłych wykonawców :)

Gdy pracochłonność zostanie oszacowana następuje przyporządkowanie zasobów do zadań oraz zaczyna się rozpisywać harmonogram.

Pracochłonność testów zależy od wielu czynników, np od:

- cech produktu - jakości specyfikacji produktu, informacji o używanych modelach testowych, wielkości, złożoności, wymagań na niezawodność oraz zabezpieczenie, wymagań na dokumentację,

- cech procesu produkcyjnego - stabilności organizacji, użytych narzędzi, procesu testowego, umiejętności ludzi oraz presji czasu,

- wyników testów - liczby usterek oraz pracochłonności napraw i przeróbek.


Podejście do testowania, strategia testowania

Podejście do testów jest implementacją strategii testów w konkretnym projekcie. Podejście do testów jest definiowane i uszczegóławiane w planach testów oraz projektach testów. Zawiera ono zwykle decyzje podejmowane na podstawie celów projektu oraz oceny ryzyka. Stanowi ono punkt wyjściowy do planowania procesu testowania, wyboru technik projektowania testów i stosowanych typów testów, a także do definiowania kryteriów wejścia i zakończenia.

Typowe podejścia do testów.

> podejścia analityczne, takie jak testy oparte na ryzyku, w którym testowanie jest kierowane na obszary o największym ryzyku,
> podejścia oparte na modelach, takie jak testowanie stochastyczne wykorzystujące informacje statystyczne na temat współczynników awarii,
> podejścia metodyczne - podejścia oparte na awariach, oparte na doświadczeniu, na listach kontrolnych lub na atrybutach jakościowych,
> podejścia zgodne ze standardem lub procesem, takie jak te określone przez standardy przemysłowe,
> podejścia dynamiczne i heurystyczne, takie jak testowanie eksploracyjne, w którym testowanie bardziej reaguje na zdarzenia podczas testów niż jest wykonywane według planu i w którym wykonanie testów i ocena wyników dzieją się równolegle,
> podejścia konsultatywne, w których pokrycie testowe jest sterowane głównie przez wskazówki i porady ekspertów technologicznych lub biznesowych z zewnątrz zespołu testowego,
> podejścia regresywne, w których używa się powtórnie istniejących materiałów testowych, rozbudowanej automatyzacji regresywnych testów funkcjonalnych oraz standardowych zestawów testów.

Różne podejścia mogą zostać połączone, np. w dynamiczne testy oparte na ryzyku.

============

Kandydat potrafi wskazać najczęściej używane metryki do monitorowania przygotowania i wykonania testów. Potrafi wyjaśnić i porównać metryki stosowane w raportowaniu i kontroli testów. Potrafi również omówić krótko cel i zawartość raportu podsumowującego testy zgodnie ze standardem dokumentacji testowania oprogramowania.


Monitorowanie postępów testów i ich nadzór

Celem monitorowania testów jest uzyskanie informacji zwrotnych oraz uzyskanie wglądu w przebieg zadań testowych. Informacje, które mają być monitorowane, mogą zostać zebrane ręcznie lub automatycznie i mogą zostać użyte do pomiarów spełnienia kryteriów zakończenia (np. pokrycia). Metryki mogą również zostać wykorzystane do oceny postępów według zaplanowanego harmonogramu i budżetu.

Takimi metrykami są:

- procent pracy wykonanej przy przygotowaniu przypadków testowych lub odsetek przygotowanych przypadków testowych,
- procent prac wykonanych przy przygotowaniu środowiska testowego,
- wykonanie przypadków testowych,
- informacje o usterkach,
- pokrycie testami wymagań, ryzyka i kodu,
- subiektywne zaufanie testerów do produktu,
- daty kamieni milowych,
- koszt testowania, włączając w to porównanie kosztu do korzyści dla znalezienia kolejnego defektu lub wykonania kolejnego testu.

Raportowanie testów

Raportowanie testów podaje podsumowanie projektu testowego, a w tym:

- co zdarzyło się w czasie testowania, np. daty spełnienia kryteriów zakończenia,
- analizę informacji oraz metryk wspierającą rekomendację oraz decyzje co do przyszłych działań, takich jak pozostałe usterki, opłacalność dalszego testowania, pozostałe obszary ryzyka oraz poziom zaufania do testowanego oprogramowania.

Pomiary testów powinny być wykonywane w trakcie oraz na koniec poziomu testów, żeby ocenić:

- dopasowanie celów testów do poziomu testów,
- adekwatność wybranego podejścia do testów,
- skuteczność testów w odniesieniu do celów testowania.

Kierowanie testami

Kierowanie testami to wszystkie działania zarządcze lub korekcyjne podjęte na skutek zebranych i zaraportowanych informacji i pomiarów. Działania te mogą dotyczyć dowolnego zadania testowego lub mogą wpływać na dowolną czynność lub zadanie związane z SLC.

Przykładami działań związanych z kierowaniem testami są:

- podejmowanie decyzji na podstawie informacji uzyskanych z monitorowania testów,
- zmiana priorytetów testów, kiedy zmaterializuje się ryzyko (np. oprogramowanie zostaje dostarczone testerom z opóźnieniem),
- zmiana harmonogramu testów związana z dostępnością lub niedostępnością środowiska testowego,
- ustanowienie kryteriów wejścia wymagających, aby programista zretestował poprawki zanim włączy je do wydania.

Kandydat potrafi opisać krótko, w jaki sposób zarządzanie konfiguracją wspiera testowanie.


Celem zarządzania konfiguracją jest ustanowienie i utrzymanie integralności produktów (modułów, danych i dokumentacji) związanych z oprogramowaniem lub systemem przez cały projekt lub SLC.

Z punktu widzenia testowania - zarządzanie konfiguracją wymaga zapewnienia, że wszystkie elementy oprogramowania zostały zidentyfikowane, poddane kontroli wersji, są śledzone, powiązane między sobą oraz z elementami deweloperskimi, tak, żeby można utrzymać możliwość śledzenia zmian i powiązań przez cały proces testowy. 

Zarządzanie konfiguracja pomaga testerom jednoznacznie wskazać (i odtworzyć) testowany element, dokumenty testowe, testy oraz jarzmo testowe.

Podczas planowania testów powinny zostać wybrane, udokumentowane i wdrożone procedury zarządzania konfiguracją oraz infrastrukturą.

=====================

Kandydat potrafi opisać ryzyko jako potencjalny problem, który zagrażałby osiągnięciu celów projektowych jednego lub kilku interesariuszy projektu. Pamięta, że poziom ryzyka jest określany przez prawdopodobieństwo wystąpienia oraz wpływ. Rozróżnia też elementy ryzyka projektowego i produktywnego Rozpoznaje typowe elementy ryzyka projektowego i produktywnego, potrafi opisać przy użyciu przykładów jak analiza ryzyka i zarządzanie ryzykiem mogą zostać wykorzystane przy planowaniu testów.

Ryzyko definiujemy jako możliwość wystąpienia zdarzenia, niebezpieczeństwa, zagrożenia lub jakiejś sytuacji powodującej niepożądane konsekwencje lub poważny problem. Poziom ryzyka jest określony przez prawdopodobieństwo wystąpienia niekorzystnego zdarzenia oraz jego wpływ (szkoda, jaką może wyrządzić to zdarzenie).

Ryzyko projektowe to obszary języka otaczające zdolność projektu do osiągnięcia postawionych przed nim celów. Te cele to m.in.:

> czynniki organizacyjne 
- brak skilla u uczestników projektu,
- problemy kadrowe,
- problemy polityczne (wieczna wojna dev vs tester),
- nieprawidłowe nastawienie i oczekiwania co do testowania,

> czynniki techniczne
- problemy ze zdefiniowaniem poprawnych wymagań,
- środowisko testowe nie jest gotowe na czas,
- niska jakość projektu kodu, danych konfiguracyjnych, danych testowych i samych testów,

> problemy z dostawcami
- niewywiązywanie się dostawców ze zobowiązań,
- problemy z kontraktami.

Podczas analizowania, zarządzania i łagodzenia powyższych obszarów ryzyka kierownik testów postępuje według uznanych zasad kierowania projektami.

!Obszar ryzyka produktowego

Potencjalne obszary wystąpienia awarii w oprogramowaniu lub systemie nazywane są ryzykiem produktowym, ponieważ stanowią zagrożenie dla jakości produktu. Mogą to być m.in.:

- dostarczanie awaryjnego oprogramowania,
- możliwość wyrządzenia szkody człowiekowi lub firmie przez oprogramowanie lub sprzęt,
- niedostateczne atrybuty oprogramowania (np. niezawodność, funkcjonalność, wydajność etc.),
- niska jakość lub brak spójności danych (np. problemy z ich migracją, konwersją, przekazywaniem),
- oprogramowanie, które nie spełnia założonych funkcji.

Ryzyka używa się do określenia, kiedy rozpocząć testowanie oraz co powinno zostać dokładniej przetestowane. Samo testowanie jest wykorzystywane do zredukowania ryzyka wystąpienia niekorzystnych zdarzeń lub do zredukowania ich wpływu (jakbyście jeszcze nie wiedzieli).

Testowanie jako działanie kontrolujące ryzyko dostarcza informacji na temat istniejących obszarów ryzyka przez pomiar skuteczności usuwania krytycznych usterek oraz planów awaryjnych.

Oparte na ryzyku podejście do testowania umożliwia w sposób aktywny obniżanie ryzyka produktowego rozpoczynając już od wstępnej fazy projektu. Zawiera ono identyfikacje obszarów ryzyka produktowego, co umożliwia użycie ich jako wskazówek w planowaniu i kontroli testów, ich przygotowywaniu i wykonaniu. W podejściu do testów opartych na ryzyku zidentyfikowane obszary ryzyka mogą zostać wykorzystane do:

- określenia technik testowania, które powinny zostać użyte,
- określenia zakresu testów,
- priorytetyzacji testów w celu znalezienia usterek krytycznych tak wcześnie, jak to tylko możliwe,
- określenie, czy nie można użyć działań niezwiązanych z testowaniem w celu redukcji ryzyka.

Testowanie oparte na ryzyku bazuje na grupowej wiedzy i obserwacji wykonawców projektu w celu określenia obszarów ryzyka oraz poziomów testowania wymaganych, żeby odnieść się do nich.

W celu zapewnienia minimalizacji szansy wystąpienia awarii produktu, zarządzanie ryzykiem daje zdyscyplinowane podejście do:

- oceny co może pójść nie tak,
- ustalenia, którymi obszarami ryzyka należy się zająć,
- wdrożenia działań zarządzających tymi obszarami ryzyka.

Dodatkowo testy mogą wspierać identyfikację nowych obszarów ryzyka, mogą pomóc w ustaleniu, które obszary ryzyk powinny zostać zminimalizowane oraz mogą zmniejszyć niepewność co do ryzyka.

Kandydat zna zawartość raportu incydentu zgodnie ze standardem dokumentacji testowania oprogramowania. Potrafi napisać raport incydentu zawierający opis awarii zaobserwowanej podczas testowania.

Ponieważ jednym z celów testowania jest znajdowanie usterek, rozbieżności pomiędzy oczekiwaniami i rzeczywistymi wynikami muszą być zapisywane jako incydenty. Incydenty powinny być analizowane, bo może się okazać, że stanowią defekty. Odpowiednie czynności, mówiące jak należy postępować z incydentami i defektami, powinny zostać zdefiniowane. Incydenty i defekty muszą być śledzone od momentu wykrycia i klasyfikacji do naprawy i potwierdzenia rozwiązania. Żeby być w stanie zarządzać wszystkimi incydentami aż do ich zamknięcia, organizacja powinna wprowadzić proces zarządzania incydentami oraz reguły klasyfikacji.

Incydenty można zgłaszać podczas programowania, przeglądów, testowania lub użytkowania produktu. Mogą to być problemy w kodzie lub działającym systemie oraz dokumenty dowolnego typu, wymagań, dokumentów deweloperskich, dokumentów testowych lub informacji dla użytkownika takich jak pomoc lub instrukcja instalacji.

Raporty incydentów istnieją w celu:

- dostarczenia programistom i innym stronom informacji na temat problemów tak, aby umożliwić ich identyfikację, wyodrębnienie i naprawę. 

- dostarczenia liderom testów środków do śledzenia jakości testowanego systemu oraz postępów testów,

- dostarczenia pomysłów na doskonalenie procesu testowania.

!Raport incydentów może zawierać takie szczegóły, jak:

- datę zgłoszenia, organizacje zgłaszającą i imię autora,

- wyniki oczekiwane oraz rzeczywiste,

- wskazanie na element testowy oraz na środowisko,

- SLC w którym incydent został zaobserwowany,

- opis incydentu (w celu odtworzenia i rozwiązania, włącznie z logami, zrzutami ekranu oraz baz danych),

- obszar lub stopień wpływu na interesy interesariuszy,

- stopień wpływu na system,

- pilność, priorytetyzowanie naprawy,

- status incydentu (np. otwarty, duplikat, oczekujący na naprawę, poprawiony, oczekujący na retest, zamknięty),

- podsumowania, rekomendacje oraz zgody,

- zagadnienia globalne, takie jak inne obszary, na które mogą mieć wpływ zmiany związane z incydentem,

- historię zmian np. ciąg czynności podjętych przez zespół w celu wyizolowania incydentu,

- referencję, włączając w to identyfikator specjalizacji przypadku testowego, który wykrył problem.

=============

Uff, wszystko z zarządzania testami. Zwróćcie uwagę zwłaszcza na raportowanie incydentów. Jako przyszli testerzy poznacie tę sztukę, gwarantuję wam to : )

Zostaje nam jeszcze jedna kwestia - następna i zarazem ostatnia część kursu traktująca o narzędziach wpierających testowanie. Postaram się, żeby była jeszcze dzisiaj ale najpierw skoczę na basen. Muszę odświeżyć umysł i dać sobie dla odmiany trochę innego wycisku, niźli ten umysłowy ;)

Trzymajcie się, ej!

F.

ISTQB PART III: Techniki projektowania testów (czarnoskrzynkowe, białoskrzynkowe, oparte na doświadczeniu)

Hejo,

Chyba jeszcze nie zdarzyło się, żebym publikował więcej, niż jeden post dziennie. Jesienna chandra, piąteczek oraz chęć przelania wiedzy tak, by móc ją usystematyzować są znacznie większe, niźli chęć wyjścia nawet na basen. #jakzostacnerdem

Żeby nie zwalniać będziemy kontynuować przyjęty wcześniej schemat. Cele nauczania i bezpośrednia odpowiedź. W tym poście zajmiemy się technikami projektowania samych testów, także będzie ciekawiej, niż poprzednio (chociaż w praktyce jest na odwrót).

Kandydat odróżnia projekt testów od specyfikacji przypadków testowych oraz od procedury testowej, potrafi porównać następujące pojęcia: warunek testowy, przypadek testowy, procedura testowa oraz potrafi ocenić jakość przypadków testowych, przez sprawdzenie czy mają one jednoznaczne powiązania z wymaganiami oraz czy zawierają wynik oczekiwany. Ponadto kandydat potrafi utworzyć z przypadków testowych dobrze ustrukturalizowaną procedurę testową na poziomie szczegółowości odpowiadającym wiedzy testerów.

Okay. Wiem, że cel pomimo tego, że opisany został konkretnie jest sporych rozmiarów. Dlatego przewrotnie proponowałbym obejrzeć film nt. przypadków testowych, który zamieszczę poniżej (zamieszczałem go również we wcześniejszych postach). Oczywiście niezbędna będzie znajomość angielskiego przynajmniej na poziomie B2 ale w tej branży bez tego języka imho nie ma sensu się wkręcać.

via. guru99

via software test training

Oczywiście ja sam rozpiszę się trochę dla czystego egoizmu i potrzeby poukładania sobie w głowie zdobytej niedawno wiedzy. Chciałbym tylko zaznaczyć, iż proces rozwoju testów, jaki przedstawię, to ten, na jakim opiera się sylabus ISTQB. Sam proces zazwyczaj wygląda przyjemniej, jest mniej formalny (zwłaszcza przy zgranym teamie) ale myślę, że warto znać pewien schemat, który jest zazwyczaj schematem wyjściowym znacznie zwiększającym produktywność wykonywanej przez team pracy.

Jak wiadomo podczas analizy testów przeglądana (baaardzooo dokładnie) jest dokumentacja podstawy testów w celu określenia co należy przetestować - czyli warunków testowych. Warunek testowy będziemy definiować zatem jako element lub zdarzenie, które może zostać sprawdzone przez jeden lub więcej przypadków testowych (np. funkcja, atrybut jakościowy, element struktury etc.).

Podczas projektowania testów tworzy się i opisuje przypadki testowe i dane testowe. Przypadek testowy składa się ze zbioru wartości wejściowych, warunków wstępnych, oczekiwanych wyników oraz warunków zakończenia utworzonych żeby pokryć pewne cele testów lub warunki testowe. 

Przykład wymagania funkcjonalnego (testerzy.pl)

Przykład przypadku testowego bazującego na tabeli powyżej (testerzy.pl)

Jako część specyfikacji przypadku testowego powinny zostać określone wyniki oczekiwane (patrz tabela powyżej). Powinny one zawierać opis wyjść, zmian w danych i stanie oprogramowania oraz inne skutki testu. Gdy wyniki oczekiwane nie są zdefiniowane, może się zdarzyć, że wiarygodne ale błędne wyniki zostaną uznane za poprawne! 

Oczywiście podczas implementacji testów przypadki testowe są rozwijane, priorytetyzowane oraz układane w specyfikację procedur testowych. Procedury te zawierają kolejności działań podczas wykonywania testów. Jeżeli testy wykonywane są przy pomocy narzędzia do wykonywania testów, ciąg akcji jest zawarty w skrypcie testowym.  Przy tworzeniu harmonogramu wykonywania testów bierze się pod uwagę takie czynniki jak testy regresywne, priorytety oraz zależności techniczne i logiczne. 

Kandydat pamięta do czego przydatne są techniki projektowania testów oparte na specyfikacji (czarnoskrzynkowe) oraz techniki oparte na strukturze (białoskrzynkow) oraz potrafi wymienić typowe dla nich techniki. Potrafi również objaśnić cechy, podobieństwa oraz różnice pomiędzy technikami opartymi na specyfikacji, strukturze i doświadczeniu.

Celem technik projektowania testów jest oczywiście zdefiniowanie warunków, przypadków i danych testowych.

Klasyczny podział wyróżnia techniki czarnoskrzynkowe oraz białoskrzynkowe. 

Czarnoskrzynkowe techniki projektowania testów są sposobem na wywodzenie oraz wybieranie warunków testowych, przypadków testowych i danych testowych bazującym na analizie podstawy testów. Można ich używać zarówno w testowaniu funkcjonalnym, jak i niefunkcjonalnym. Techniki czarnoskrzynkowe z definicji nie wykorzystują żadnych informacji o strukturze wewnętrznej testowanego modułu lub systemu. 

via guru99

Białoskrzynkowe techniki projektowania testów (również nazywane strukturalnymi lub technikami opartymi na strukturze) bazują na analizie struktury modułu lub systemu. 

via guru99

Zarówno testy biało i czarnoskrzynkowe mogą korzystać z doświadczenia programistów, testerów i użytkowników w celu określenia CO powinno zostać przetestowane. Niektóre techniki da się przyporządkować jednoznacznie do jednej kategorii, niektóre jednak zawierają elementy więcej niż jednej kategorii. 

Warto wiedzieć, że cechą wspólną testów opartych stricte na specyfikacji jest to, iż w specyfikacji problemu do rozwiązania, oprogramowania lub jego komponentów używane są modele, a z nim można w sposób usystematyzowany wywodzić przypadki testowe.

Cechy wspólne technik projektowania testów opartych na strukturze jest to, iż do tworzenia przypadków testowych wykorzystywana jest wiedza o tym, jak oprogramowanie jest skonstruowane (np. kod źródłowy). Cechą wspólną jest również to, że można mierzyć stopień pokrycia istniejących przypadków testowych, można też w sposób usystematyzowany tworzyć nowe przypadki testowe w celu zwiększenia pokrycia.

Cechy wspólne technik projektowania testów opartych na doświadczeniu to:

- przede wszystkim do tworzenia przypadków testowych niezbędna jest zaawansowana wiedza oraz doświadczenie ludzi biorących udział w projekcie tj:

> wiedza testerów, programistów, użytkowników o oprogramowaniu, jego środowisku i sposobie użytkowania,

> wiedza o prawdopodobnych defektach i ich położeniu (tak, z czasem zaczniecie zauważać, że jest wiele defektów, które są typowe dla danego poziomu testów, praktyka czyni mistrza!).

Kandydat potrafi napisać przypadki testowe na podstawie podanych modeli oprogramowania używając techniki klas równoważności, analizy wartości brzegowych, testowania w oparciu o tablicę decyzyjną, testowania przejść pomiędzy stanami. Potrafi również wyjaśnić główny cel każdej z czterech technik testowania, to na jakim poziomie testowania mogą zostać użyte i jak mozna dla nich zmierzyć pokrycie. Poza tym wie, jak wyjaśnić na czym polega testowanie w oparciu o przypadki użycia i korzyści płynące z jego zastosowania.

Tutaj warto się skupić, ponieważ wiedza z tego fragmentu jest niezbędna i będzie przewijać się praktycznie ciągle podczas waszych przyszłych doświadczeń. Podobnie będzie zresztą z następnym celem sylabusa. Obejrzyjcie również materiał z YouTube, który zamieściłem powyżej, myślę, że fajnie wprowadzi Was w kwestię technik czarnoskrzynkowych. Polecam również obejrzeć każdy z materiałów, jakie zamieściłem do każdego z opisu technik czarnoskrzynkowych :) Chyba lepiej słuchać, niż czytać, co nie?

Podział na klasy równoważności (Equivalence Partiotioning)

via guru99 (jest tutaj również wyjasnione BVA, o którym szerzej poniżej)

W tej technice wejścia programu lub systemu są dzielone na grupy, które powodują podobne zachowanie oprogramowania, więc wysoce prawdopodobne jest to, że są przetwarzane w ten sam sposób. Klasy równoważności można znaleźć dla danych poprawnych (dane akceptowalne przez oprogramowanie), jak i dla danych niepoprawnych (dane odrzucone). Klasy równoważności można znaleźć również dla wyjść, wartości wewnętrznych, wartości zależnych od czasu oraz parametrów interfejsów.

Testy można tak zaprojektować, żeby pokrywały akceptowalne i nieakceptowalne klasy równoważności. Technikę tę można zastosować na każdym poziomie testowania. 

Zajrzyj również tutaj.

Analiza wartości brzegowych (Boundary Value Analysis) 

BVA

Istnieje większe prawdopodobieństwo, że software będzie się błędnie zachowywać dla wartości krawędziach klas równoważności, niż w ich środku, więc testowanie tych obszarów najprawdopodobniej wykryje błędy. Minimum i maksimum klasy równoważności to jej wartości brzegowe. Testy można zaprojektować tak, aby pokrywały zarówno poprawne, jak i niepoprawne (wartość brzegowa niepoprawnego przedziału) wartości brzegowe.

Analiza wartości brzegowych może zostać zastosowana na każdym poziomie testowania. Technika ta jest często uważana za rozwinięcie techniki podziału na klasy równoważności.


Testowanie w oparciu o tablicę decyzyjną (Decision Table Testing)

via. guru99

Tablice decyzyjne są b. dobrym sposobem na uchwycenie tych wymagań na system, które zawierają zależności logiczne, oraz na udokumentowanie wewnętrznej budowy systemu. Mogą być używane do zapisywania złożonych reguł biznesowych, które system ma obsługiwać. 

Podczas tworzenia tablic decyzyjnych analizuje się specyfikację systemu i wyszukuje warunki oraz wynikające z nich zachowanie systemu. Warunki wejściowe oraz zachowanie systemu często muszą być zapisane jako prawda lub fałsz (funkcja Boolean - jeśli sprawdzałeś kurs MySQL na moim blogu to teraz pewnie uśmiechasz się tak szeroko, jak ja). Właśnie stąd nazwa - tabela decyzyjna, bo zawiera warunki uruchamiające, często jako kombinacje prawy (1) i fałszu (0) oraz wszystkich warunków wejściowych oraz działania oprogramowania wynikające z każdej z tych kombinacji :) 

Standardowe pokrycie stosowane dla testowania w oparciu o tabelę decyzyjną wymaga zaprojektowania jednego testu dl każdej kolumny w tablicy, co zwykle oznacza wykorzystanie wszystkich kombinacji warunków uruchamiających. 

Testowanie przejść między stanami (State Transition Testing)

via guru99

System może różnie odpowiadać w zależności od aktualnych warunków oraz od jego stanu. W takim przypadku zachowanie systemu można opisać diagramem przejść stanów. Pozwala to testerowi spojrzeć na oprogramowanie od strony stanów, przejść między stanami, wejść lub zdarzeń, które powodują zmiany stanów (przejścia) oraz na działania, które mogą wynikać z tych przejść. Stany testowanego systemu są rozdzielne, zdefiniowane oraz ich liczba jest skończona. 

Testy można zaprogramować tak, żeby pokrywały typowe sekwencje stanów, każdy stan, każde przejście, konkretny ciąg przejść lub żeby testowały przejścia nieprawidłowe. 

Testowanie przejść między stanami jest często używane w testowaniu oprogramowania wbudowanego oraz ogólnie w automatyce.

Testowanie w oparciu o przypadki testowe 

via guru99

Testy można projektować na podstawie przypadków użycia. Przypadek użycia opisuje interakcje pomiędzy aktorami (użytkownikami bądź systemami), które powodują powstanie wyniku wartościowego z punktu widzenia użytkownika lub klienta. Przypadek użycia może być opisany na wysokim poziomie abstrakcji lub na poziomie systemowym. Każdy przypadek użycia posiada warunki wstępne, które muszą zostać spełnione, żeby przypadek użycia został wykonany. Każdy przypadek użycia kończy się warunkami końcowymi. Przypadki użycia zwykle posiadają scenariusz główny (ten najbardziej prawdopodobny) oraz czasami scenariusze poboczne.

Co ważne i ciekawe to to, że przypadki użycia opisują 'przepływy' procesu przez system bazując na najbardziej prawdopodobnym rzeczywistym jego użyciu, co sprawia, że przypadki testowe wywiedzione z przypadków użycia najbardziej przydają się w wyrywaniu usterek w przepływach praocesów z rzeczywistego użytkowania systemu. Przydatne jest to przy testach akceptacyjnych, w których ma brać udział klient. 

============

Kandydat potrafi opisać pojęcie pokrycia kodu u jego znacznie. Potrafi wyjaśnić pojęcia takie jak pokrycie instrukcji i pokrycie decyzji oraz podać powody, dla których te pojęcia mogą zostać użyte nie tylko na poziomie testów modułowych ale też np. dla procedur biznesowych. Potrafi napisać przypadki testowe dla danych przepływów sterowania stosując techniki testowania instrukcji i testowania decyzji. Potrafi też ocenić kompletność testów wg. zdefiniowanych kryteriów zakończenia na podstawie pokrycia instrukcji i decyzji.

No dobrze, po opisie technik czarnoskrzynkowych przejdziemy do technik białoskrzynkowych. Tak, jak w przypadku technik czarnoskorzynkowych i tutaj będę podawać materiały z YouTube, które wg. mnie lepiej wyjaśniają poszczególne kwestie :) Zacznijcie zatem najpierw od fajnego wprowadzenia (po raz kolejny) w świat technik opartych na strukturze kodu software'u.

via. guru99

Testowanie oparte na strukturze bazuje na rozpoznanej strukturze oprogramowania lub systemu. Przykładami takich struktur są:

- testy modułowe: kod, to jest instrukcje, decyzje, rozgałęzienia lub rozróżnialne ścieżki,

- w testach integracyjnych strukturą może być hierarchia wywołań - diagram, który pokazuje jak moduły wywołują moduły,

- w testach systemowych strukturą może być budowa menu, proces biznesowy lub struktura strony www.

Testowanie i pokrycie instrukcji.

Materiał jest długi ale warto go obejrzeć, ponieważ działając na wyobraźnie fajnie 'rozrysuje' Wam to czym są schematy blokowe, algorytmy i to w jaki sposób działają i oczywiście czym jest to pokrycie instrukcji ;)

W testowaniu instrukcji stosuje się pokrycie instrukcji, które polega na zmierzeniu, jaki odsetek instrukcji wykonywalnych został przetestowany przez zestaw testów. W technice tej projektuje się przypadki testowe, tak by wykonać określone instrukcje, zwykle po to, żeby zwiększyć pokrycie.

Pokrycie instrukcji oblicza się przez podzielenie liczby wykonywalnych instrukcji pokrytych przez przypadki testowe, przez liczbę wszystkich wykonywalnych instrukcji w testowanym kodzie.

Testowanie i pokrycie decyzji

Pokrycie decyzji (spokrewnione z testowaniem gałęzi) polega na zmierzeniu jaki odsetek wyników decyzji (np. wyniku true or false w instrukcji if) został przetestowany przez zestaw testów. W technice testowania decyzji projektuje się przypadki testowe tak, aby pokryć określone wyniki decyzji. Gałęzie zaczynają się w punktach decyzyjnych i pokazują przekazanie sterowania do różnych miejsc w kodzie. Testowanie decyzyjne skupia się tylko na samych gałęziach, w przeciwieństwie do testowania instrukcji, które skupia się również na mierzalności instrukcji. 

Pokrycie decyzji jest wyliczane przez podzielenie liczby wyników decyzji pokrytych przez przypadki testowe przez liczbę wszystkich wyników decyzji znajdujących się w testowanym kodzie.

Należy pamiętać, iż testowanie decyzji jest jedną z form testowania przepływu sterowania, ponieważ podąża za konkretnym przepływem sterowania przez punkty decyzyjne. Pokrycie decyzji jest mocniejsze niż pokrycie instrukcji. Sto% pokrycia decyzji gwarantuje sto% pokrycia instrukcji ale nie odwronie!

Inne techniki oparte na strukturze

Istnieją techniki jeszcze mocniejsze, niż pokrycie decyzji - na przykład pokrycie warunków lub wielokrotne pokrycie warunków.

Pojęcie pokrycia może zostać również zastosowane na innych poziomach testowania. Na przykład w testowaniu integracyjnym odsetek modułów, komponentów lub klas, które zostały przetestowane przez zestaw testów można wyrazić jako pokrycie modułów, komponentów lub klas. 

===================

Kandydat pamięta powody pisania przypadków testowych opierających się na intuicji, doświadczeniu oraz wiedzy na temat często spotykanych usterek. Potrafi również porównywać techniki oparte na doświadczeniu z technikami opartymi na specyfikacji.

Testowanie oparte na doświadczeniu

Mamy z nim styczność wtedy, kiedy testy projektuje się na podstawie wiedzy i intuicji testerów (wow!) oraz ich doświadczenia z podobnymi aplikacjami i technologiami. Zaleca się, aby zostało użyte jako uzupełnienie technice systematycznych zaraz po nich, co może okazać się użyteczne w uchwyceniu specjalnych przypadków testowych, których nie da się łatwo zaprojektować używając technik formalnych. Należy pamiętać, że skuteczność testowania oparta jest na doświadczeniu testerów ;)

Szeroko wykorzystywaną technika opartą na skillu jest zgadywanie błędów. Testerzy przewidują usterki bazując na autopsji. Ustrukturalizowane podejście do zgadywania błędów polega na sporządzeniu listy możliwych defektów i zaprojektowaniu testów, które atakują te defekty. To systematyczne podejście jest nazywane atakiem usterkowym.

Testowanie eksploracyjne  polega na równoległym projektowaniu testów, ich wykonaniu, zapisaniu wyników i uczeniu się, bazując na zamówieniu na testy zawierającym cele testów i trzymając się ram czasowych. To podejście okazuje się najpożyteczniejsze, gdy nie ma specyfikacji albo jest ona niekompletna, bądź przestarzała, również w sytuacjach bardzo krótkiego czasu na testy. 

===================

Kandydat potrafi podzielić techniki projektowania testów według ich dopasowania do danego kontekstu, podstawy testowania, modeli oraz cech oprogramowania.

Wybór, która technika testowania powinna zostać użyta zależy od wielu czynników - są to czynniki tj. wybór systemu, regulacji prawnych, wymagań klienta lub kontraktu, poziom ryzyka, typu ryzyka, celu testów, dostępnej dokumentacji, wiedzy testerów, czasu i budżetu, cyklu rozwoju oprogramowania, modelu przypadków użycia oraz doświadczenia zwiazanego ze znajdowanymi typami usterek.

Niektóre z technik można z większą korzyścią zastosować tylko na niektórych poziomach testowania. Inne techniki można z równym powodzeniem stosować na wszystkich poziomach testów.

Podczas projektowania przypadków testowych testerzy zwykle stosują różne techniki projektowania testów - włącznie z technikami opartymi na procesie, regułach oraz danych, po to żeby zapewnić odpowiednie pokrycie testowanego obiektu.

==================

Dzięki za kolejną część przejścia przez ISTQB FL. Starałem się trzymać bardzo mocno sylabusa, jednak uzupełniłem wiedzę o materiały, które wg. mnie przedstawiają problem bardziej dostępnie i poglądowo.

Dzięki śliczne!

Na dzisiaj mam fajrant. Wracam jutro z rana ^_^

F.

ISTQB PART II: Statyczne techniki testowania (przegląd ręczny, statyczna analiza automatyczna)

Hejo,

Jest piątek, wieczorowa pora i właśnie uświadomiłem sobie, jak bardzo muszę być w to wszystko wkręcony, skoro nie wyszedłem zobaczyć się ze znajomymi, odrzuciłem fajną propozycję spotkania i spędzę dłuugi wieczór z tematem testowania. Powinienem postukać się w głowę, prawda? Nie chcę traktować górnolotnymi hasłami ale szukaj podpowiedzi w nazwie bloga, sam właśnie na to wpadłem. Meh.

Okay, Statyczne techniki testowania. Zrobimy to tak samo, jak w poprzednim poście - wymienimy sobie cele nauczania (wg. mnie te najważniejsze i najbardziej interesujące) i je opiszemy starając się żyć w zgodzie z sylabusem ISTQB FL. Zaczynajmy!


=======================

Kandydat potrafi rozpoznać produkty, które mogą zostać sprawdzone przez różne techniki testowania statycznego. Potrafi również opisać ich znaczenie oraz wartość w ocenie produktów procesu rozwoju oprogramowania. Dodatkowo potrafi wyjaśnić różnice pomiędzy testami statycznymi i dynamicznymi.

Okay, zacznijmy od końca. W przeciwieństwie do technik dynamicznych (które wymagają uruchomienia oprogramowania) techniki statyczne polegają na sprawdzeniu ręcznym (robi się przeglądy) lub na analizie automatycznej (analiza statyczna) kodu źródłowego testowanego produktu (software'u) lub innych dokumentów projektowych bez uruchamiania kodu :)

Co ważne, to to, że przeglądy są jednym ze sposobów na testowanie produktów procesu wytwarzania oprogramowania i to łącznie z kodem. Może je wykonywać długo przed wykonaniem testów dynamicznych. Dzięki temu usterki, jakie uda się znaleźć w tak wczesnej fazie produkcji oprogramowania są o wiele tańsze to załatania/usunięcia, iż te wykryte podczas testów dynamicznych.

Jak wcześniej wspomnieliśmy przeglądy wykonujemy ręcznie ale istnieje do nich wsparcie narzędziowe. Główną czynnością wykonywaną manualnie jest sprawdzenie produktu i zanotowanie uwag. Przeglądom mogą podlegać wszystkie produktu SLC - od specyfikacji wymagań, poprzez projekt, kod, plany i specyfikacja testów, przypadki testowe, skrypty na podręcznikach użytkownika i stronach webowych kończąc.

Po co robić testowanie przeglądowe? Ano najważniejszym wariantem jest tutaj ekonomia wykonania. Przeglądy pozwalają zaoszczędzić mnóstwo pieniędzy, pozwalają również na wczesną naprawę usterek, zwiększenie produktywności produkcji software'u i notowanie uwag, które inkrementują doświadczenia osób pracujących przy danym projekcie. Dodatkowo przeglądy mogą wykrywać braki, które trudno wykryć na poziomie testów dynamicznych.

Ciekawostka - do tych najbardziej typowych usterek wykrywanych za pomocą testów przeglądowych należą: odchylenia od standardów, usterki w wymaganiach, usterki w projekcie czy nieprawidłowa pielęgnowalność oraz specyfikacje interfejsów.


Warto zajrzeć w ten link, gdzie fajnie pokazano porównanie pomiędzy tymi dwoma typami testowania (statycznego oraz dynamicznego).

Kandydat pamięta kroki, role i odpowiedzialności związane z typowym przeglądem formalnym, potrafi wyjaśnić różnice pomiędzy różnymi typami przeglądów oraz potrafi wskazać czynniki wpływające na skuteczne przeprowadzanie przeglądów.

Okay, pora wejść głębiej w testowanie statyczne (przeglądowe - ręczne), a dokładniej w jego typy. Wyróżniamy ich wiele - od tych nieformalnych (które cechują się notabene brakiem spisanych instrukcji dla przeglądających - co jest częste w tej branży), do systematycznych, które z kolei uwzględniają przygotowanie zespołu, zapisanie wyników przeglądu oraz udokumentowanie procedury wykonania przeglądu.

Warto wiedzieć, iż stopień sformalizowania przeglądu zależy od takich czynników jak dojrzałość procesu produkcyjnego oraz wymagań wynikających z prawa lub też konieczności udokumentowania przebiegu przeglądu.

PRZEGLĄD FORMALNY 

Chcę zaznaczyć, iż to, co teraz przeczytacie to idealnie zaplanowany, rozpisany i wykonany proces przeglądu formalnego. W zależności od specyfiki pracy, teamu, potrzeb, projektu może to wyglądać zupełnie inaczej i zazwyczaj jest to budujące i niezwykle inspirujące doświadczenie, tylko na papierze wygląda to nudno. Podkreśliłem te czynności, które imho wzbogacają naszą wiedzę oraz doświadczenie najbardziej.

Zatem przegląd formalny składa się z następujących po sobie faz:

1. planowanie, a w nim:
- definiowanie kryteriów przeglądu,
- przydział ról,
- ustalenie kryteriów wejścia i zakończenia dla bardziej formalnych typów przeglądów,
- wybór fragmentów dokumentu do przejrzenia,

2. rozpoczęcie, a w nim:
- rozesłanie dokumentów,
- opisanie celów przeglądu, procesu i dokumentów uczestnikom przeglądu,
- sprawdzenie kryteriów wejścia,

3. przygotowanie indywidualne
- przygotowanie przed spotkaniem przeglądowym przez przejrzenie dokumentów,
- zapisywanie potencjalnych defektów, pytań i komentarzy,

4. kontrola/ocena/zapisanie wyników (spotkanie przeglądowe)
- dyskusja lub spisywanie, z udokumentowaniem wyników i sporządzeniem protokołu,
- zapisywanie defektów i rekomendacji dotyczących ich poprawiania, podejmowanie decyzji co do defektów,

5. poprawki
- naprawianie znalezionych defektów, zwykle wykonywane przez autora kodu,
- uaktualnianie statusów defektów,

6. zakończenie
- sprawdzenie, że usterki zostały obsłużone,
- zbieranie metryk,
- sprawdzenie kryteriów zakończenia.

Jak możecie się domyślać praca testera jest ściśle kooperacyjna, nawet, jeśli my jako osoba mamy wyznaczone pojedyncze zadania musimy być komunikatywni, spostrzegawczy, ambitni, nie możemy zostawać w tyle za zespołem - i tutaj dobrze w zespole mieć ludzi, którzy 'pchają' do przodu - czasem na dobre wychodzi wskoczenie w ocean - jeżeli uda się wypłynąć, to wypłynie się z ogromną wiedzą i satysfakcją. Napominam również o tym dlatego, że w każdym z projektów biorą udział osoby, które posiadają różne role. Wymienię je teraz w skrócie:

kierownik - myślę, że wyjaśniać nie trzeba - osoba decyzyjna, ustalająca harmonogram projektu oraz sprawdza poszczególne cele wykonania projektu,

moderator - osoba ta prowadzi przegląd dokumentu (włącza w to planowanie przeglądu, prowadzenie spotkań i odhacza, czy wszystkie kryteria spotkania zostały spełnione),

autor - jest to osoba, która nadzorowała powstawanie dokumentu, który podlega przeglądowi,

przeglądający - są to osoby z odpowiednimi kompetencjami (posiadający zaplecze techniczne etc.), którzy znajdują i spisują uwagi (np. usterki) do przeglądanego produktu.

protokólant - dłubie w nosie ołówkiem ale tą stroną z naoszczonym przodem.

Podczas tego typu spotkań warto robić burzę myśli - spojrzenia różnych specjalistów na sprawy kluczowe opisane np. w dokumencie pozwalają podejść do problemu na wiele sposobów, co ostatecznie pozwala na wykrycie większej ilości defektów :)

==================

Pojedynczy produkt programistyczny może podlegać więcej niż jednemu przeglądowi. Głównymi cechami, opcjami i celami powszechnie stosowanych typów przeglądów są:

przegląd nieformalny - brak kompletnego procesu, nie musi być udokumentowany, jego głównym celem jest tani sposób na osiągnięcie niewielkich korzyści (tak, wiem, jak to brzmi),

przejrzenie - są to nieograniczone czasowo sesje, których celem jest przede wszystkim uczenie się, zrozumienie oraz (a jakże!) znajdowanie usterek,

przegląd techniczny - posiada zdefiniowany proces wykrywania defektów, może być organizowany bardziej lub mniej formalnie, w praktyce może być bardzo nieformalny albo bardzo formalny, a jego głównymi celami są dyskusja, podjęcie decyzji nt. zaistniałych problemów, ocena alternatyw, wyszukiwanie usterek oraz rozwiązywanie problemów technicznych :)

inspekcja - przeprowadzana jest przez moderatora, który sprawdza kolegów, czy robią wszystko tak, jak jest to zapisane w harmonogramie, planie, dokumencie technicznym, przyjętymi na spotkaniu wytycznymi, jej efektem jest raport dla kierownika, głównym celem jest oczywiście wyszukiwanie usterek,

======

Czynniki, które mogą wpływać pozytywnie na powodzenie przeglądów to:

- jasno określony cel przeglądu,
- znalezione usterki są przyjmowane pozytywnie i wyrażane w sposób obiektywny,
- rozwiązuje się problemy personalne i psychologiczne,
- przegląd prowadzone jest w atmosferze zaufania,
- kierownictwo wspiera dobry proces przeglądu,
- kładzie się nacisk na uczenie się oraz doskonalenie procesów.


Kandydat pamięta typowe błędy wykrywane przez analizę statyczną i umie porównać je z przeglądami i testami dynamicznymi, potrafi opisać używając przykładów typowe korzyści z analizy statycznej oraz potrafi wymienić typowe defekty kodu i projektu, które mogą zostać wykryte przez narzędzia do analizy statycznej.

Celem analizy statycznej jest wyszukanie usterek w kodzie programu lub w modelach bez uruchamiania samego programowania, które jest sprawdzane przez narzędzie używane w tym procesie.  Analiza statyczna może znaleźć usterki, które są trudne do znalezienia podczas testowania dynamicznego (wspominaliśmy o tym wcześniej ale to najważniejsza różnica i powód dla robienia ręcznych przeglądów). Analiza statyczna znajduje usterki, a nie awarie. Narzędzia do analizy statycznej analizują kod oprogramowania (np. przepływ sterowania lub przepływ danych) jak również wygenerowane wyjście w postaci htmla lub xmla.

O wartości analizy statystycznej świadczą następujące cechy:
- (znowu) wczesne wykrywanie usterek, jeszcze przed wykonaniem prawilnych testów,
- wczesne wykrywanie podejrzanych aspektów kodu lub projektu przez wyliczenie miar (np. stopień złożoności kodu),
- identyfikacja defektów trudnych do wykrycia podczas prawilnego testowania,
- zwiększenie pielęgnowalności kodu i projektu,
- zapobieganie defektom, jeżeli zastosowane zostają wnioski z analizy z SLC.

Analiza statyczna zwykle wykrywa następujące typy usterek:

- odwołanie do niezainicjowanej zmiennej,
- niespójne interfejsy między modułami,
- niewykorzystywane lub niepoprawnie zadeklarowane zmienne,
- martwy kod,
- brakująca albo błędna logika,
- zbyt skomplikowane instrukcje,
- naruszenie standardów kodowania,
- słabe punkty zabezpieczeń,
- naruszenie reguł składni kodu i modeli oprogramowania.

Narzędzia do analizy statycznej używane są zwykle przez programistów przed lub w trakcie testów modułowych lub integracyjnych. Narzędzia te mogą zaraportować dużą liczbę ostrzeżeń, którymi trzeba jednak dobrze zarządzać, by uzyskać jak największą skuteczność użycia narzędzia.

================

Wybaczcie mi za to, że ta część to praktycznie sam tekst. W praktyce jest ciekawiej, bardziej stresująco, a sama teoria często w ogólnym zarysie wygląda inaczej. ISTQB to model idealny, a wiadomo, że ilu ludzi w teamie, tyle kombinacji pracy tego teamu nad danym projektem :)

Trzymajcie się,

F.

Ps. Jeżeli nie rozumiecie pojęć tj. kryteria wejścia i im podobnych to najprawdopodobniej będą one wyjaśnione w kolejnych częściach :) Poza tym używanie Googla nie boli, prawda? A przynajmniej w odwrotną stronę..

ISTQB PART I - Testowanie w SLC

Hejo,

Z racji, iż za niecały tydzień podchodzę do egzaminu na certyfikat ISTQB (International Software Testing Qualifications Board) FL chciałbym podzielić się odrobiną wiedzy. Nie będzie to wiedza podparta przykładamy czy też ćwiczeniami. Wynika to z faktu, iż FL opiera się przede wszystkim na przyswojeniu sylabusa oraz jego zrozumieniu.

Zacznę trochę nietypowo, ponieważ od rozdziału drugiego sylabusa. Uznałem, że rozdział pierwszy to podstawy podstaw i będzie mi szkoda czasu i miejsca, by się nad nim rozwodzić : )

Będę opisywać tutaj swoje przemyślenia oraz wiedzę, jaką przyswoiłem odpowiadając na to, co wg. sylabusa powinienem potrafić po zakończeniu danego modułu. Czyli taka wiedza w pigułce z każdego działu. Easy!

Zaczynajmy!

===============

Modele wytwarzania oprogramowania:

Kandydat potrafi wyjaśnić powiązania pomiędzy rozwojem oprogramowania, czynnościami testowymi oraz produktami w cyklu życia oprogramowania i podać przykłady na podstawie cech projektu i produktu oraz kontekstu. 

Okay, kandydat potrafi. Kandydat przekaże.

Wyróżniamy wiele modeli powstawania oprogramowania, jednak ja skupię się na tych, które są w sylabusie:

- model V (inaczej model sekwencyjny) - jest najczęściej spotykany, co najważniejsze posiada cztery poziomy testowania odpowiadające czterem poziomom rozwoju software'u. Oczywiście istnieje wiele wariantów tego modelu, zapewne co projekt to każdy będzie się różnić szczegółami, niemniej założenie jest już nam znane.

Obraz pobrany z testerzy.pl

W sylabusie użyli przykładu z czterema poziomami testowania, a są to po kolei:
a) testy modułowe (jednostkowe),
b) testy integracyjne,
c) testy systemowe,
d) testy akceptacyjne.

Co ważne to to, że w porównaniu do innych modelu powstawania oprogramowania (np. waterfall'a), ten ma wyraźnie więcej plusów. Otóż testowanie oraz projektowanie/powstawanie software'u odbywa się w tym samym czasie, co pozwala szybciej zniwelować defekty, zaoszczędzić masę pieniędzy oraz co najważniejsze poprawiać jakość software'u na bieżąco.

Po więcej info zapraszam pod tym linkiem :)

-  modele iteracyjno-przyrostowe - jest to proces zbierania wymagań, projektowania, budowania oraz testowania software'u w krótszych cyklach rozwojowych. System wyprodukowany wg. takiego modelu może być przetestowany na wielu poziomach w każdej iteracji. Przyrost, dodany do innych wytworzonych wcześniej staje się rosnącym systemem częściowym, który również powinien być przetestowany.

Schemat modelu przyrostowego w SLC (za http://www.fizyka.umk.pl/~grochu/wiki/doku.php?id=zajecia:ppz:cykl_zycia_oprogramowania)

===============

W każdym SLC 'dobre testowanie' charakteryzuje się kilkoma niezmiennymi cechami:

- dla każdej czynności związanej z powstawaniem software'u istnieją odpowiadające im czynności związane z testingiem,
- każdy z poziomów testowania ma zdefiniowane cele,
- analiza i projektowanie testów dla danego poziomu powinny rozpoczynać się już podczas odpowiadającej im fazie powstawania software'u,
- testerzy powinni uczestniczyć w przeglądach już od wczesnych wersji dokumentacji tworzonej podczas wytwarzania software'u,

Poziomy te mogą być oczywiście łączone lub organizowane na różne sposoby. Jest to zależne od projektu, architektury powstającego systemu etc.


Kandydat potrafi porównać różne poziomy testów: główne cele, typowe poziomy testów, typowe cele testowania (np. strukturalne bądź funkcjonalne) i związane z nimi produkty, testerów, typy usterek i awarii do znalezienia.

Okay, zacznijmy od tego, że dla każdego poziomu testowania można i trzeba zdefiniować ogólne cele, produkty, przypadki testowe, przedmiot testów, typowe defekty i awarie do wykrycia,, wymagania na jarzmo testowe oraz wsparcie narzędziowe, środowisko testowe.

Jeżeli chodzi o pojęcia, które mogę wyjaśnić i ciężko można się ich domyślić to:

* jarzmo testowe to nic innego jak zestaw zaślepek, sterowników, które będą potrzebne do wykonania określonych testów (np. kiedy jeden z modułów nie jest jeszcze gotowy).
* przypadek testowy to 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 610] [Słownik wyrażeń związanych z testowaniem, wersja 2.0].  

Tak, w tym przypadku posiłkowałem się słownikiem, dlatego, że uważam, iż najlepiej obejrzeć ten materiał (i w ogóle samo zobaczenie informacji zebranych w przypadek testowy wyjaśni nam więcej, niż jakakolwiek definicja): 

* środowisko testowe to narzędzia dobrane w taki sposób podczas testowania, by jak najbardziej zbliżyć się do oprogramowania, na jakim będzie operować użytkownik końcowy. 

O poziomach testów wspomnieliśmy wyżej, teraz pora je po kolei wyjaśnić:

TESTY MODUŁOWE (unit tests)

Stosujemy je wtedy, kiedy software jest podzielony na moduły, posiadamy projekt oraz jego specyfikację. Typowymi obiektami testów modułowych są moduły (tak, nie wpadłbyś na to, co nie?), programy, które służą do konwersji bądź migracji danych oraz moduły bazodanowe.

Testy modułowe polegają przede wszystkim na wyszukiwaniu błędów oraz weryfikacji funkcjonalności oprogramowania, które można testować oddzielnie. Takie testy mogą być wykonywane w izolacji od reszty systemu i w zależności od kontekstu SLC oraz samego systemu można tutaj stosować wspomniane wcześniej jarzmo testowe (np. sterownik, który będzie imitować brakujący moduł).

Testy modułowe mogą zawierać testy funkcjonalności software'u oraz niektórych atrybutów niefunkcjonalnych, takich jak stopień wykorzystania zasobów (np. wycieków pamięci), bądź też odporności danego software'u na obciążenie klientów docelowych.

Przypadki testowe projektowane są na podstawie specyfikacji danego podułu, projektu oprogramowania oraz modelu danych, z jakich software korzysta. 

Charakterystyczne dla tych testów jest również to, że wykonuje się je posiadając dostęp do kodu źródłowego, przy wsparciu środowiska rozwojowego oraz często same testy angażują autora testowanego kodu, tak by same usterki mogły zostać usunięte zaraz po wykryciu.

Warto automatyzować testy modułowe. Podejście 'najpierw testuj' sprawdza się tutaj doskonale. Podejście to jest iteracyjne, opiera się na cyklach tworzenia przypadków testowych, a następnie na budowaniu i integracji niewielkich fragmentów kodu, i ponownego testowania.

Polecam poświęcić te 5 minut na obejrzenie materiału powyżej : ) Myślę, że jeszcze bardziej wyklaruje spojrzenie na ten poziom testów.


TESTY INTEGRACYJNE (integration tests)

Podstawy do wykonania testów pojawiają się wtedy, kiedy mamy zamiar przetestować implementację baz danych poszczególnych podsystemów, infrastrukturę software'u, interfejsy software'u, konfigurację systemu i dane konfiguracyjne. Testy te będą kłady mocny nacisk na projekt software'u, jego architekturę, przepływ procesów wykonywanych przez software.

Jednymi słowy testy integracyjne sprawdzają działanie interfejsów występujących pomiędzy modułami. Sprawdzają interakcje pomiędzy oraz z innymi częściami systemu (t.j. OS, system plików) oraz interfejsy pomiędzy systemami.

Co ważne to to, że testy integracyjne mogą być wykonywane na więcej niż jednym poziomie i dla przedmiotów testów o różnej wielkości. Np: testowanie integracji modułów sprawdza interakcje z innymi częściami systemu, testowanie integracji systemów sprawdza interakcje pomiędzy różnymi systemami lub pomiędzy sprzętem, a oprogramowaniem etc.

Im większy zakres integracji, tym trudniejsze może być określenie, jaki moduł lub system zawiera defekt. Systematyczne strategie integracji mogą bazować na architekturze systemu, zadaniach funkcjonalnych, sekwencjach przetwarzania transakcji albo na innym aspekcie systemu lub modułu.

Żeby ułatwić namierzenie usterek oraz ich wczesne wykrywanie w normalnych warunkach integracja powinna być raczej prowadzona metodą inkrementalną, niż metodą 'big bangu'.

Podczas testów integracyjnych można wykonać testy niektórych atrybutów niefunkcjonalnych (np. wydajności systemu) na równi z testami funkcjonalnymi.

W wypadku testów integracyjnych osoba testująca powinna rozumieć architekturę oprogramowania oraz mieć wpływ na planowanie integracji.

via. guru99

TESTY SYSTEMOWE (system tests)

Obiektami testów systemowych są.. uwaga.. podręczniki systemowe (nie zazdroszczę), użytkownika oraz operacyjne, jak i konfiguracje systemu oraz same dane konfiguracyjne. Podstawą to testowania systemowego są, jak możemy się domyślać wymagania software'u na OS oraz oprogramowanie, przypadki użycia software'u, jak i raport z analizy ryzyka.

Jednym słowem testy systemowe zajmują się zachowaniem systemu/produktu i czy jest ono zgodne ze specyfikacją końcową klienta. Same testy mogą być opare na ryzyku lub wymaganiach, procesie biznesowym, przypadkach użycia software'u etc. Testy te powinny sprawdzać funkcjonalne, jak i niefunkcjonalne wymagania na system oraz jakość danych. Tester w tym przypadku musi umieć poradzić sobie z wymaganiami niekompletnymi lub też nieudokumentowanymi. Testowanie systemu wymagań funkcjonalnych startuje poprzez użycie technik opartych na specyfikacji (czarnoskrzynkowe) dla testowanego aspektu systemu. Można również użyć technik opartych na strukturze (białoskrzynkowe) do oceny dokładniości testowania w odniesieniu do elementów struktury, takich jak menu, czy nawigacja po stronach www.

Takie testy wykonywane są przez niezależny zespół testowy.

TESTY AKCEPTACYJNE 

Obiektami testów akceptacyjnych są proces biznesowy (już na w pełni zintegrowanym systemie), procesy utrzymania oraz obsługi systemu, formularze, raporty czy dane konfiguracyjne. Podstawą do testów będą przede wszystkim wymagania systemowe, wymagania użytkownika software'u, przypadki użycia software'u, raporty z analizy ryzka.

Odpowiedzialność za testy akceptacyjne leży często po stronie klientów lub użytkowników systemu.

Celem testów akceptacyjnych jest nabranie zaufania do systemu, jego części bądź pewnych atrybutów niefunkcjonalnych (np. szybkość przekazywania procesów etc). Testy akceptacyjne mają za zadanie ocenić gotowość systemu do wdrożenia oraz użycia, chociaż nie muszą być ostatnim etapem testowania - testy akceptacyjne mogą pojawić się w wielu momentach SLC.

Typowymi formami testów akceptacyjnych są: testy akceptacyjne przez użytkownika, testy produkcyjne, akceptacja systemów przez adminów (testowanie kopii zapasowych, uruchamiania systemu po awarii, ładowanie danych i zadania związane z migracją etc.).

 Testy ALFA wykonywane są u producenta ale nie przez zespół projektowy. Mają za zadanie uzyskanie opinii potencjalnych lub obecnych klientów nt. systemu przed wypuszczeniem go do sprzedaży. Testy BETA (testy polowe) wykonywane są przez klientów. 


================

Kandydat potrafi porównać podając przykłady cztery typy testów (funkcjonalne, niefunkcjonalne, strukturalne oraz związane ze zmianami).

Skoro mamy typy testów to logicznym jest, że każdy z nich skupia się na określonym celu. Takie cele to np. przetestowanie jakiegoś niefunkcjonalnego atrybutu jakościowego, przetestowanie struktury czy architektury systemu, przetestowanie zmian zachodzących w oprogramowaniu etc.

Oczywiście można opracować swój własny model oprogramowania i użyć go w testach różnego typu:) My skupimy się na podstawowych czterech typach testów :)

Testowanie funkcji (testowanie funkcjonalne)

Funkcje, jakie ma pełnić dany system, moduł, podsystem etc. opisane są w specyfikacji. Warto jednak zwrócić uwagę na to, że nie zawsze specyfikacja jest dostępna dla testerów. W skrócie testy funkcjonalne mają za zadanie sprawdzić 'co system właściwie robi'.

Testy funkcjonalne dotyczą funkcji lub innych cech systemu oraz ich współdziałania z innymi systemami.  Można je wykonywać na wszelkich poziomach.

Do tworzenia warunków testowych oraz przypadków testowych dla funkcjonalności systemu mogą zostać użyte techniki oparte na specyfikacji (czarnoskrzynkowe) - testy funkcjonalne zajmują się zewnętrznym zachowaniem oprogramowania. 

Testowanie zabezpieczeń np. sprawdza funkcje pozwalające na wykrycie zagrożeń (np. wirusy). Inne typy testów funkcjonalnych to: testowanie współdziałania, ocenia zdolność software'u do współpracy z jednym lub większą liczbą wskazanych modułów bądź systemów.

Myślę, że najlepszy sens testów odda definicja via wiki: "Testy funkcjonalne znane są także jako testy czarnej skrzynki, ponieważ osoba testująca nie ma dostępu do informacji na temat budowy programu, który testuje. Często testy takie są wykonywane przez osoby inne niż programiści tworzący program". 

Testowanie atrybutów niefunkcjonalnych (testowanie niefunkcjonalne)

Obejmuje ono następujące typy testów: wydajnościowe, obciążeniowe, przeciążeniowe, użyteczności, pielęgnowalności, niezawodności, przenaszalności. Testowanie te w przeciwieństwie do funkcjonalnego polega na tym, aby sprawdzić jak właściwie dany system działa. 

Testowanie niefunkcjonalne może być wykonywane na wszystkich poziomach testów. Termin tych testów oznacza testy wymagane do zmierzenia właściwości systemów i oprogramowania, które mogą zostać określone ilościowo na zmiennej skali, takich jak czasy odpowiedzi w testach wydajnościowych. 

Testowanie struktury/architektury oprogramowania (testowanie strukturalne)

Moje ulubione. Testy strukturalne w przeciwieństwie do testów funkcjonalnych opierają się na wiedzy testera na temat testowanego systemu. Testy takie, oparte na strukturze systemu, oprogramowania nazywamy białoskrzynkowymi. Można je wykonywać na każdym poziomie testowania, najlepiej jednak użyć je po testach opartych na funkcji danego systemu (opartych na specyfikacji), po to, by zmierzyć dokładność testowania przez ocenę stopnia pokrycia wybranego typu struktury.

Pokrycie to nic innego, jak opis stopnia przetestowania odeska pokrytych elementów. Tj. jeżeli pokrycie struktury kodu źródłowego programu będzie niższe, niż sto%, można wtedy zaprojektować więcej testów, by przetestować elementy, które zostały pominięte. 

Do pomiaru pokrycia (np. decyzji lub instrukcji) na wszystkich poziomach, a szczególnie na poziomie testów modułowych i testów integracji modułów mogą zostać użyte narzędzia. Testowanie strukturalne może zostać oparte na architekturze systemu :)

Testowanie związane ze zmianami: testowanie potwierdzające oraz regresywne

Po wykryciu i naprawieniu defektu przez programistę powinien zostać wykonany retest po to, by potwierdzi usunięcie usterki. To właśnie testy potwierdzające. Debagowanie (lokalizacja oraz poprawienie usterek) jest czynnością programistyczną, a nie testową.

Testowanie regresywne zaś to powtórzenie testów na już wcześniej przetestowanym systemie, oprogramowaniu wykonywane po modyfikacjach tylko po to, żeby stwierdzić, czy przy aktualizacji, usunięciu usterek nie powstały nowe defekty na skutek tych zmian. Testy regresywne wykonuje się po wszystkich zmianach w oprogramowaniu, a także po zmianach w jego środowisku.

Obydwa wyżej wymienione testy muszą być powtarzalne.

Testy regresywne można wykonać na wszystkich poziomach testów i dla wszystkich typów testów. :)


Kandydat potrafi porównać testy pielęgnacyjne (testowanie istniejącego systemu) do testowania nowej aplikacji uwzględniając typy testów, powody rozpoczęcia testowania oraz ilość testów. Potrafi również wymienić powody wykonywania testów pielęgnacyjnych (zmiany, migracja, cofnięcie systemu - odp. w pytaniu) oraz opisać rolę testów regresywnych i analizy wpływu w utrzymaniu.

Wiadomym jest, że wdrożony system musi działać przez lata. W tym czasie system, jego dane konfiguracyjne, czy środowisko są często poprawiane, zmieniane i rozszerzane (zmiana IDE, nowe dane w BZ etc.). Dla dobrego testowania pielęgnacyjnego krytyczne jest planowanie wydań z wyprzedzeniem. Konieczne jest również rozróżnianie pomiędzy planowanymi wydaniami oraz szybkimi poprawkami. Testowanie pielęgnacyjne wykonuje się na działającym systemie na skutek modyfikacji, migracji lub złomowania oprogramowania bądź systemu.

Takimi modyfikacjami mogą być planowane ulepszenia, poprawki, naprawy awaryjne, zmiany IDE etc.

Testy pielęgnacyjne migracji oprogramowania (np. pomiędzy platformami) powinny prócz testów zmian w oprogramowaniu uwzględniać również testy produkcyjne nowego IDE. Testy te są również potrzebne, gdy dane z innej aplikacji są migrowane do utrzymywanego systemu.

Testy pielęgnacyjne związane z wycofywaniem oprogramowania mogą zawierać testy migracji lub archiwizacji danych, jeżeli wymagany jest długi okres ich przetrzymywani :)

Testy pielęgnacyjne prócz przetestowania tego, co zostało zmienione zawierają również testy regresywne tych części systemu, które się nie zmieniły. Zakres testów pielęgnacyjnych zależy od ryzyka zmian, wielkości istniejącego systemu oraz zakresu tych zmian. W zależności od tych zmian testowanie pielęgnacyjne może być wykonywane na różnych poziomach testów lub na wszystkich oraz dla wybranych lub wszystkich typów testów.

Analiza wpływu to określenie, jaki wpływ na istniejący system mogą mieć zmiany. Stosuje się ją, aby ustalić zakres testów regresywnych :) (cięcie kosztów, ekonomia). Może i jest często używana do wybierania zestawu testów regresywnych.

Warto pamiętać, iż testowanie pielęgnacyjne jest trudne do wykonania, jeśli specyfikacja oprogramowania jest przestarzała lub jest jej brak. 

=====================

Na tym zakończymy pierwszą część. Jest ona oparta w dużej mierze na sylabusie ISTQB rozdział 2 ale z moimi uwagami i trochę rozszerzonym materiałem. Nie rozwodziłem się nad pierwszym rozdziałem, bo wg. mnie nie ma w nim zbyt wielu konkretów, a sam jest przedstawiony w całości w serii kursów na YT, gdzie sam film znajdziecie poniżej tego zdania. Czekajcie na kolejne części pewnie już jutro.

Trzymajcie się,

F.