nobugteam tes

t
e
s
t
o
w
a
n
i
e
j
e
s
t
ł
a
t
w
e
testerzy.pl
Podstawą tego tekstu jest Foundation Level Syllabus wydany przez ISTQB.
Zarządzanie
Zarządzanie testami
Organizacja testów
Niezależność organizacyjna testów
Efektywność w znajdowaniu defektów może zostać poprawiona dzięki niezależnej grupie
testowej. Wyróżniamy następujące typy niezależności:
- niezależny tester wewnątrz grup programistów
- niezależna grupa testowa lub po prostu grupa wewnątrz organizacji, raportująca do
kierownika projektu lub zarządu
- niezależność testera od organizacji biznesowej, społeczności użytkowników czy działu IT
- specjalista testów niezależny od testerów takich jak testerzy użyteczności, bezpieczeństwa
czy certyfikacji (certyfikujący produkt zgodnie ze standardami i regulacjami)
- niezależny tester spoza organizacji.
Dla potrzeb skomplikowanych i rozbudowanych projektów najlepsze jest stosowanie testowania na
każdym poziomie przez niezależną grupę testową. Programiści mogą uczestniczyć w procesie
testowym, szczególnie na niskich poziomach, ale ich brak obiektywności często skutkuje ich niską
skutecznością. Niezależny tester może mieć umiejętności wymagane i zdefiniowane w procesie
testowym, ale nade wszystko koniecznie powinien on mieć mandat do wykonania wszystkich zadań
związanych z przypisanymi mu obowiązkami nadany mu przez kierownictwo.
Korzyści płynące z niezależności to:
- postrzeganie różnych defektów w sposób bezstronny
- weryfikacja założeń wprowadzanych przez ludzi zajmujących się specyfikacją i
implementacją systemu.
Istnieją również negatywne aspekty:
- izolacja od programistów (w przypadku pełnej niezależności)
- niezależny tester może być zwężeniem a przez to opóźniać projekt jako jego ostatni punkt
kontrolny
- programiści przestają przejmować się jakością wiedząc, że ktoś i tak ich sprawdzi
(ewentualnie zaproponuje poprawki).
Zadanie testowe są wykonywane przez ludzi o określonych rolach, ale mogą one być również
wykonywane przez ludzi na innych stanowiskach jak np. kierownik projektu, kierownik jakości,
programista, ekspert biznesowy lub pracownicy IT.
Zadania lidera i testera
Zadanie i obowiązki ludzi na tych dwóch kluczowych stanowiskach zależą od projektu i
sytuacji wokół produktu. Zależą również od ludzi na konkretnych stanowiskach i struktury samej
organizacji.
Wyłączne prawa autorskie do tego dokumentu posiadają „testerzy.pl”. Rozpowszechnianie dla celów komercyjnych jak i
niekomercyjnych jest dozwolone tylko pod warunkiem podania źródła.
t
e
s
t
o
w
a
n
i
e
j
e
s
t
ł
a
t
w
e
Czasami liderzy testowi nazywani są kierownikami testów lub koordynatorami testów. Zadania lidera
mogą być wykonywane przez kierownika projektu, kierownika programistycznego, kierownika ds.
zapewnienia jakości lub kierownika grupy testowej. W dużych projektach zazwyczaj rozróżniamy dwa
stanowiska: lider i kierownik testów. Lider zazwyczaj planuje, monitoruje i kontroluje czynności
testowe.
Zadania lidera grupy testowej:
- planowanie i koordynacja strategii wraz z kierownikiem projektu i innymi udziałowcami
- pisanie i przegląd strategii testów dla projektów oraz polityki testowej dla organizacji
- stosowanie perspektywy testów dla innych aktywności testowych takich jak planowanie
integracji
- planowanie testów - rozważanie kontekstu i rozumienie ryzyka - włączając w to wybór metod
testowych, szacowanie czasu, wysiłku i kosztów testowania; zdobywanie zasobów, definiowanie
poziomów testowych, cykli, metodologii i celów oraz planowanie zarządzania przypadkami
- inicjowanie, specyfikacja, przygotowanie, implementacja i wykonanie testów oraz późniejsze
ich monitorowanie i kontrola
- korekty planowania oparte na wcześniejszych planach w odniesieniu do postępu testów
(czasami udokumentowanych w statusie) oraz podjęcie niezbędnych czynności dla kompensacji
problemów
- dla ułatwienia śledzenia wersji ustanowienie adekwatnego zarządzania konfiguracją dla
narzędzi testowych
- decydowanie, co powinno być zautomatyzowane, do jakiego stopnia oraz jak powinno to być
przeprowadzone
- zaproponowanie dopasowanych miar dla pomiarów postępu testowego oraz szacowania
jakości testowania oraz jakości produktu
- decydowanie o implementacji środowiska testowego
- rozpisanie na osi czasu testów
- pisanie raportów podsumowujących testy, opartych na informacjach zebranych podczas
testowania.
Typowe zadania testera:
- przegląd i własny wkład w plany testów
- analiza, przegląd i ocena wymagań użytkowników, specyfikacji i modeli pod kątem
testowalności
- tworzenie specyfikacji testowej
- ustanowienie środowiska testowego (często koordynacja z administratorem systemu i sieci)
- przygotowanie i zdefiniowanie danych testowych
- implementowanie testów na wszystkich poziomach testowych, wykonanie i zapisywanie
wyników testów, ocena wyników i dokumentacja różnic w stosunku do oczekiwanego rezultatu
- użycie narzędzi administrowania, zarządzania i monitorowania testów
- automatyzacja testów (wspierana programistami lub ekspertami od automatyzacji testów)
- pomiar wydajności komponentów systemu (gdy wymagane)
- przegląd i sprawdzenie testów napisanych przez innych.
Ludzie pracujący nad analizą, projektowaniem i automatyzacją testów mogą być specjalistami w tych
zadaniach. W zależności od poziomu testowego oraz ryzyka powiązanego z produktem i projektem,
różni ludzie mogą przyjmować zadania testerów, zachowując ciągle niezależność.
Typowo testerzy na poziomie komponentu lub integracji będą programistami, testerzy na poziomie
testów akceptacyjnych będą ekspertami biznesowymi i użytkownikami, a testerzy operacyjnych testów
akceptacyjnych będą po prostu operatorami.
Planowanie i estymacja testów
Planowanie testów
Ta część podejmuje się zdefiniować cel planowania testów wewnątrz projektu tworzenia
oprogramowania, implementacji i potrzeb serwisowych. Planowanie może być udokumentowane w
projektowym lub głównym planie testów lub oddzielnym planie testów stworzonym specjalnie dla
poszczególnych poziomów testowych, takich jak testowanie systemu i testowanie akceptacyjne.
Dokładne wskazówki jak planować testy można znaleźć w "Standard for Software Test
Documentation" (IEEE 829).
Wyłączne prawa autorskie do tego dokumentu posiadają „testerzy.pl”. Rozpowszechnianie dla celów komercyjnych jak i
niekomercyjnych jest dozwolone tylko pod warunkiem podania źródła.
t
e
s
t
o
w
a
n
i
e
j
e
s
t
ł
a
t
w
e
Na planowanie wpływa polityka testów organizacji, zakres testowanie, cele, ryzyko, ramy, ważność,
testowalność i dostępność zasobów. Czym bardziej planowanie projektu i testów jest zaawansowane
tym więcej informacji jest dostępnych i więcej szczegółów może zostać dołączonych do planów.
Planowanie testów jest ciągłą czynnością wykonywaną w ciągu trwania cyklu życia projektu.
Informacja zwrotna z czynności testowych jest użyta do rozpoznania ryzyka tak by planowanie mogło
być dopasowane do rzeczywistych warunków.
Czynności związane z planowaniem testów obejmują:
- zdefiniowanie ogólnej metody testowej (strategia testów), włączając w to definiowanie
poziomów testowych oraz kryteriów rozpoczęcia i zakończenia testów
- integracja i koordynacja czynności testowych w ramach cyklu tworzenia oprogramowania:
zakupu, dostarczenia, rozwoju, operacji i serwisu
- dokonywanie decyzji o tym, co należy testować, kto ma wykonywać każdą z czynności
testowych, kiedy i jak czynności testowe powinny być wykonane, jak wyniki testów będą analizowane i
kiedy przerwać testowanie (kryterium wyjścia)
- przypisanie zasobów dla różnych, zdefiniowanych zadań
- definiowanie ilości, poziomu dokładności, struktury i wzorców dokumentacji testowej
- wybór miar dla monitorowania i kontrolowania przygotowania testów, rozwiązywania
problemu defektów oraz oceny ryzyka
- ustanawianie poziomu dokładności dla procedur testowych w celu dostarczenia
wystarczającej informacji do wsparcia reprodukowanych czynności przygotowania i wykonania testów
Kryterium zakończenie testów
Celem definiowania kryterium zakończenia testów jest określenie, kiedy przerwać testowanie,
na różnych poziomach lub kiedy zestaw testów zostanie wyczerpany.
Kryterium wyjścia zawiera:
- dokładne metryki takie jak pokrycie kodu, funkcjonalności lub ryzyka
- kalkulacja ilości defektów w stosunku do tych, możliwych do wystąpienia lub miary
niezawodności
- koszty
- pozostałe ryzyko, takiej jak pozostawione defekty, niepełne pokrycie testów w określonym
obszarze
- rozpiska planów w czasie, takich jak data dostarczenia produktu na rynek.
Ocena testów
Dwie metody oceny wysiłku testowego:
- ocena wysiłku testowego oparta na metrykach poprzedniego lub podobnego projektu lub
oparte na znanych, typowych wartościach
- ocena zadań dokonana przez właściciela tych zadań lub przez eksperta.
Kiedy wysiłek zostanie już oceniony, zasoby mogą zostać określone oraz można przygotować plan
działań.
Wysiłek testowy zależy od różnych czynników takich jak:
- parametry produktu: jakość specyfikacji i innych informacji użytych dla modeli testowych,
rozmiar produktu, złożoność obszaru problemu, wymagań niezawodności i bezpieczeństwa, wymagań
względem dokumentacji
- parametry procesu rozwoju oprogramowania: stabilność organizacji, użyte narzędzia,
procesy testowe, umiejętności ludzi zaangażowanych w projekt oraz presja czasu
- wynik testowania: ilość znalezionych defektów i ilość wymaganych poprawek
Strategie testów
Jedna z metod klasyfikacji strategii testów jest oparte na okresie czasu, w którym największe
nawał pracy w projektowaniu testów się rozpoczyna:
- metoda prewencji, gdzie testy projektowane są jak najwcześniej
- metoda reaktywna, gdzie testy projektowane są po wyprodukowaniu oprogramowania lub
systemu.
Do typowych metod lub strategii zaliczamy:
Wyłączne prawa autorskie do tego dokumentu posiadają „testerzy.pl”. Rozpowszechnianie dla celów komercyjnych jak i
niekomercyjnych jest dozwolone tylko pod warunkiem podania źródła.
t
e
s
t
o
w
a
n
i
e
j
e
s
t
ł
a
t
w
e
- analityczne metody oparte na ryzyku testowym gdzie testowanie jest ukierunkowane na
obszary najbardziej narażone na ryzyko wystąpienia błędów
- metody oparte na modelu takie jak testowanie stochastyczne z użyciem informacji
statystycznych o kalkulacji problemów występujących po wystąpieniu defektów
- metodologiczne takie jak oparte na konsekwencjach błędów (włączając w to zgadywanie
błędów), oparte na punktach kontrolnych, oparte na jakości parametrów
- metody zgodne z procesami i standardami, takie jak te opisane przez standardy
przemysłowe lub różne metodologie Agile
- metody dynamiczne, takie jak wyczerpujące testowanie gdzie testowanie jest bardziej
konsekwencją zdarzeń poprzednio zaplanowanych i gdzie wykonywanie i ocenianie są równoległymi
zadaniami
- metody konsultatywne, kierowane wcześniejszą radą, przy pomocy przewodnika
technologicznego i/lub obszarem biznesowych ekspertyz wykonanych poza zespołem testowym
- metody regresywne takie jak ponowne użycie materiałów testowych, automatyzacji testów
regresji oraz standardów testowych.
Różne metody mogą być ze sobą łączone np. dynamiczne metody oparte na ryzyku.
Wybór strategii powinien być poprzedzony rozważaniem kontekstu:
- ryzyka wystąpienia konsekwencji błędów w projekcie, niebezpieczeństwo dla produktu i
ryzyko narażenia bezpieczeństwa użytkownika, środowiska lub firmy
- umiejętności i doświadczenie ludzi w zaproponowanych technikach, narzędziach i metodach
- cele zdolności testowania i misja zespołu testowego
- aspekty regulujące takie jak wewnętrzne i zewnętrzne regulacje dla procesu tworzenia
oprogramowania
- natura produktu i biznesu.
Wyłączne prawa autorskie do tego dokumentu posiadają „testerzy.pl”. Rozpowszechnianie dla celów komercyjnych jak i
niekomercyjnych jest dozwolone tylko pod warunkiem podania źródła.
t
e
s
t
o
w
a
n
i
e
j
e
s
t
ł
a
t
w
e
Monitorowanie i kontrola postępów w testowaniu
Monitorowanie postępu testów
Celem monitorowania testowania jest otrzymywanie informacji i zdobywanie jasności o
czynnościach testowych. Efekt monitorowania może być zbierany ręcznie lub automatycznie i może
być użyty dla pomiaru kryterium zakończenie testów takich jak pokrycie. Miary mogą być użyte do
oceny postępu w odniesieniu do tego, co zostało zaplanowane i zabudżetowane.
Najczęściej metryki testowe zawierają:
- procent wykonanej pracy w przygotowaniu przypadków testowych (lub procent
zaplanowanych przypadków testowych już przygotowanych)
- procent pracy wykonanej do przygotowania środowiska testowego
- wykonanie przypadków testowych (np. liczba wykonanych/niewykonanych przypadków
testowych i ilość przypadków testowych, które "przeszły"/"nie przeszły")
- informacje o defektach (np. ilość defektów, ilość defektów znalezionych i naprawionych,
ocena konsekwencji błędów, wyniki retestów)
- pokrycia wymagań, ryzyka lub kodu
- daty kamieni milowych testowania
- koszty testowania, włączając w to koszty porównane z korzyściami płynącymi ze
znajdowania następnych defektów lub przeprowadzania następnych testów.
Raportowanie
Raportowanie testowe jest postrzegane jako zbieranie informacji o wysiłku w testowaniu:
- co stało się podczas testowania, np. daty, kiedy kryterium zakończenia testów zostanie
osiągnięte
- przeanalizowanie informacji i metryk do wsparcia rekomendacji i decyzji o przyszłych
działaniach takich jak ocena pozostałych defektów, ekonomiczne korzyści z kontynuacji testów,
pozostałe ryzyko i poziom niezawodności testowanego oprogramowania.
Metryki powinny być zbierane podczas i na koniec każdego poziomu testowego dla oceny:
- poziomu jakości w odniesieniu do celów założonych dla danego poziomy testowego
- efektywności testowania w odniesieniu do celów
- adekwatności obranej metody testowej.
Kontrola
Kontrola opisuje wszystkie działania korygujące i naprowadzające powzięte jako rezultat
informacji i metryk zebranych i zaraportowanych. Czynności mogą pokrywać czynności testowe i
mogą wpływać na inne czynności w cyklu tworzenia oprogramowania.
Przykłady kontroli testów:
- zmiana priorytetów testów w przypadku, gdy pojawi się ryzyko
- zmiana planu testów zgodnie z dostępnością środowiska testowego
- zestaw kryteriów jakości wymagających naprawy, które muszą zostać przetestowane przez
programistę, zanim zostaną zaakceptowane do integracji.
Wyłączne prawa autorskie do tego dokumentu posiadają „testerzy.pl”. Rozpowszechnianie dla celów komercyjnych jak i
niekomercyjnych jest dozwolone tylko pod warunkiem podania źródła.
t
e
s
t
o
w
a
n
i
e
j
e
s
t
ł
a
t
w
e
Zarządzanie konfiguracją
Celem zarządzania konfiguracją jest ustanowienie i serwisowanie integralności produktów
(komponentów, danych i dokumentacji) programistycznych lub systemów w czasie trwania projektu i
cyklu tworzenia oprogramowania.
Dla testowania, zarządzanie konfiguracją obejmuje zapewnienie, że:
- wszystkie elementy środowiska narzędziowego testów zostały zidentyfikowane, ich wersje
podlegają kontroli, zmiany są śledzone w całym czasie trwania procesu
- wszystkie zidentyfikowane dokumenty i elementy oprogramowanie znajdują odniesienie (w
sposób bezsprzeczny) w dokumentacji testowej.
Zarządzanie konfiguracją pomaga testerowi zidentyfikować (i zreprodukować) testowane elementy,
dokumenty testowe, testy i narzędzia wspierające testowanie.
Podczas planowania, procedury i infrastruktury (narzędzi) zarządzania konfiguracją
powinno być wybrane, udokumentowane i zaimplementowane.
Wyłączne prawa autorskie do tego dokumentu posiadają „testerzy.pl”. Rozpowszechnianie dla celów komercyjnych jak i
niekomercyjnych jest dozwolone tylko pod warunkiem podania źródła.
t
e
s
t
o
w
a
n
i
e
j
e
s
t
ł
a
t
w
e
Ryzyko
Ryzyko można definiować jako przypadek, niebezpieczeństwo, możliwość lub sytuację
występującą w projekcie z niepożądanymi konsekwencjami - potencjalny problem. Poziom ryzyka
będzie określony prawdopodobieństwem wystąpienia zdarzenia i jego wypływem (możliwości
uszkodzeń).
Ryzyko w projekcie
Ryzyko projektowe jest ryzykiem otaczającym zdolność projektu do dostarczenia określonych
dla niego celów. Wyróżniamy:
- czynniki dostawcy:
- niemożność dostarczenia produktu/podzespołu przez zewnętrzną grupę
- czynniki kontraktowe
- czynniki organizacyjne:
- brak umiejętności i ludzi
- czynniki osobiste i treningi
- czynniki polityczne takie jak problem z komunikacją, niemożność uczenia się na
własnych błędach
- niepoprawny odbiór lub oczekiwania względem testowania (np. brak doceniania
wartości błędów znalezionych podczas testowania)
- czynniki techniczne
- problem ze zdefiniowaniem właściwych wymagań
- zakres wymagań, który może zostać osiągnięty dla istniejących ram
- jakość projektów, kodu i testów.
Kiedy kierownik testów analizuje, zarządza i przeciwdziała ryzyku, wypełnia założenia zarządzania
projektem. Norma IEEE 829 wymusza zawarcie w test planie informacji o potencjalnym ryzyku i jego
konsekwencjach.
Ryzyko produktu
Potencjalne obszary występowania awarii (powodujące przyszłe niebezpieczeństwa) w
oprogramowaniu lub systemie nazywane są ryzykiem produktu, gdyż są ryzykiem w odniesieniu do
jakości produktu.
Wyróżniamy następujące ryzyko produktu:
- oprogramowanie dostarczone na rynek zawierające defekty powodujące awarie
- potencjalne zagrożenia zranienia osoby lub wprowadzenie niebezpieczeństwa uszkodzeń
wewnątrz organizacji
- słabe parametry oprogramowania (np. funkcjonalność, bezpieczeństwo, niezawodność,
użyteczność i wydajność)
- oprogramowanie, które nie zachowuje się tak jak powinno (nie spełnia swoich założeń).
Pojęcia ryzyka używa się dla zdecydowania gdzie zacząć testowanie i gdzie przetestować bardziej
dogłębnie; testowanie jest używane do zredukowania ryzyka występowania niepożądanych efektów
lub do zredukowania wpływu tych efektów.
Ryzyko produktu jest specjalnym typem ryzyka do wsparcia sukcesy projektu. Testowanie jako
kontrola ryzyka dostarcza informacji zwrotnej o pozostałym ryzyku poprzez miarę efektywności
usuwania krytycznych błędów i planom ich zapobiegania.
Metoda testowa oparta na ryzyku zawiera szanse (użyte od najwcześniejszych etapów projektu)
przeciwdziałania błędom zanim się pojawią, a przez to zredukowania poziomu ryzyka. Zawiera ona
identyfikację ryzyka produktu i zawarcie informacji o nim w planowaniu testów, specyfikacji i podczas
przygotowania i wykonywania testów.
Ryzyko to możemy użyć by określić:
- używane techniki testowe
- zakres testów
- ważność poszczególnych testów w celu znalezieniu najbardziej krytycznych błędów we
wczesnej fazie
- czy czynności pozatestowe mogące zostać zaprzęgnięte by zredukować ryzyko (np.
dostarczenie treningów dla niedoświadczonych architektów).
Wyłączne prawa autorskie do tego dokumentu posiadają „testerzy.pl”. Rozpowszechnianie dla celów komercyjnych jak i
niekomercyjnych jest dozwolone tylko pod warunkiem podania źródła.
t
e
s
t
o
w
a
n
i
e
j
e
s
t
ł
a
t
w
e
Testowanie oparte na ryzyku podsumowuje zebraną wiedzą i pokazuje udziałowcom ryzyko i poziom
potrzebny do jego wyeliminowania.
Dla zapewnienia, że szanse na awarie produktu są minimalne, czynności zarządzania ryzykiem
dostarczają wsparcia w postaci:
- oceny (regularnie powtarzanej), co może pójść źle (ryzyko)
- określenia, z jakim ryzykiem i o jakiej ważności będziemy mieli do czynienia
- wprowadzenia akcji do przeciwdziałania ryzyka.
Dodatkowo, testowanie może wspierać identyfikację nowego ryzyka, może pomagać określić ryzyko,
jakie można zredukować oraz może obniżyć niepewność w występowaniu ryzyka.
Wyłączne prawa autorskie do tego dokumentu posiadają „testerzy.pl”. Rozpowszechnianie dla celów komercyjnych jak i
niekomercyjnych jest dozwolone tylko pod warunkiem podania źródła.
t
e
s
t
o
w
a
n
i
e
j
e
s
t
ł
a
t
w
e
Zarządzanie przypadkami
Jednym z celów testowania jest znajdywanie defektów, różnica między aktualnym i oczekiwanym
wynikiem muszą zostać zakwalifikowane jako przypadki. Przypadek powinien być śledzony od
momentu jego odkrycia aż po przedstawienie dla niego rozwiązania. W celu zarządzania przypadkami
organizacja powinna ustanowić proces i zasady klasyfikacji przypadków.
Przypadek może zostać dostrzeżony podczas czynności programistycznych, przeglądów, testowania
lub użycia oprogramowania. Może być odniesiony do kodu lub do systemu, ale również do
dokumentacji programistycznej, dokumentów testowych lub informacji dla użytkownika jak np.
"Pomoc".
Cele raportów o przypadkach:
- dostarczyć programistom i innym uczestnikom informację zwrotną o problemach, aby wspomóc
identyfikacją, izolacją i korekcją, gdy jest to konieczne
- dostarczyć liderom testów narzędzi do śledzenia jakości systemu będącego testowanym i postępu w
testowaniu
- dostarczać pomysły dla poprawy procesu testowego.
Tester lub osoba dokonująca przeglądu zazwyczaj zapisują następujące informacje o przypadkach:
- data wykrycia, część organizacji gdzie został znaleziony przypadek, autor, potwierdzenie i
status
- zakres, negatywne konsekwencje i priorytet przypadku
- referencje, zawierające, jaki przypadek testowy pozwolił wykryć problem.
Szczegóły raportu o przypadku zawiera:
- oczekiwany i aktualny rezultat
- data, kiedy przypadek został wykryty
- identyfikacja i konfiguracja oprogramowania lub systemu
- cykl życia oprogramowania, w którym przypadek został zaobserwowany
- opis anomalia dla wsparcia znalezienia rozwiązania
- poziom wpływu na zainteresowanych udziałowców
- negatywny wpływ na system
- pilność/priorytet naprawy
- status przypadku (np. otwarty, duplikat, czeka na naprawę, naprawiony - oczekujący na
potwierdzenie, zamknięty)
- konkluzje i rekomendacje
- czynniki zewnętrzne, jak inne obszary mogące być zainfekowane zmianą wprowadzoną dla
naprawy przypadku
- historia zmian, jako sekwencja działań podjętych, przez członków zespołu projektowego, dla
wyizolowania i naprawienia przypadku.
Wyłączne prawa autorskie do tego dokumentu posiadają „testerzy.pl”. Rozpowszechnianie dla celów komercyjnych jak i
niekomercyjnych jest dozwolone tylko pod warunkiem podania źródła.
t
e
s
t
o
w
a
n
i
e
j
e
s
t
ł
a
t
w
e
Modele tworzenia oprogramowania
Testowanie nie jest czynnością wykonywaną w izolacji, jest powiązane z tworzeniem
oprogramowania. Różne cykle tworzenia oprogramowania wymagają różnych metod testowych.
Wodospad
Model wodospadu w pełni oddaje pierwsze projekty informatyczne. Jest to prosta próba
przedstawienia czynności w projekcie, gdzie dwie najważniejsze fazy: projektowanie i weryfikacja,
następują po sobie. W uproszczeniu najpierw tworzony jest system lub oprogramowanie a dopiero
potem następują testy.
Model V
Różne modele V testowe zostały opisane, ale można wyróżnić cztery poziomy
testowe, powiązane z czterema poziomami rozwoju oprogramowania.
Te poziomy to:
- testy komponentów
- testy integracji
- testy systemu
- testy potwierdzające.
Czytaj więcej w artykule na stronie www.testerzy.pl
Model iteratywny
Rozwój oprogramowania oparty na metodach iteratywnych jest procesem ustalania wymagań,
projektowania, budowania i testowania systemu, wykonane przez podzielenie całego procesu na jego
mniejsze elementy. Wyróżniamy dwa główne nurty: inkrementacji, czyli wzrostu poprzez dodawania
małych cząstek oraz ewolucyjny, czyli stopniowy. Przykłady: procesy prototypowe, szybki rozwój
aplikacji (ang. RAD), zunifikowany process firmy Rational (RUP), model Agile. Efekt iteracji może być
testowany na różnych poziomach rozwoju oprogramowania. Elementy dodane do procesu wcześniej,
tworzą cały system, który również musi zostać przetestowany. Szczególnie ważne jest testowanie
regresyjne po każdej iteracji. Weryfikacja i walidacja może również być włączona w każdą
inkrementacją.
Testowanie w modelu cyklu życia
W modelu cyklu życia, możemy wyróżnić parametry dobrego testowania:
- dla każdej czynności programistycznej możemy wyróżnić odpowiadającą jej czynność
testową
- każdy poziom testowy ma cele specyficzne dla niego
- analiza i projekt testów dla konkretnego poziomu powinien rozpoczynać się wraz z
odpowiadającym mu poziomem programistycznym
- tester powinien być zaangażowany w przegląd dokumentów od momentu pojawienia się ich
pierwszych szkiców.
Poziomy testowe mogą być łączone i reorganizowane w zależności od natury projektu lub architektury
systemu. Przykładowo: integracja komercyjnego oprogramowania prosto z półki sklepowej z
systemem, klient kupujący taki produkt sam wykonuje testy integracji w systemie (np. integracja z
infrastrukturą i innymi systemami) i testy akceptacyjne (funkcjonalne i niefunkcjonalne)
Wyłączne prawa autorskie do tego dokumentu posiadają „testerzy.pl”. Rozpowszechnianie dla celów komercyjnych jak i
niekomercyjnych jest dozwolone tylko pod warunkiem podania źródła.
t
e
s
t
o
w
a
n
i
e
j
e
s
t
ł
a
t
w
e
Metodologie
Agile - czyli metoda ułatwionego ruchu, bardziej dotyczy deweloperów, którym coraz
bliżej do testerów
XP - ekstremalne programowanie
Test Driven Developmnet - czyli rozwój oprogramowania kierowany poprzez
testy jest niesamowitym połączeniem testowania i programowania. Jest to zupełnie nowe podejście do
tematu projektowania i zarządzania, który przestaje wreszcie tworzyć sztuczne granice między
testerami i programistami. Drużyny tworzone w projektach łączą jednych i drugich w celu osiągnięcia
właściwej jakość oprogramowania na czas. Ekspert tej techniki Jack Gansleyy powiedział/napisał:
"Testowania i integracja nie są już osobnymi kamieniami milowymi projektu".
TTD łączy w sobie dwie techniki testowania:
- jednostki (unit) - testy białej skrzynki pisane i wykonywane przez programistów
- akceptacji - testy czarnoskrzynkowe dla każdej części produktu tworzone przez ludzi związanych z
zapewnieniem mu jak najwyższej jakości.
Podstawowe hasło tej metody to: Testy na początku!
Cykl testowania zintegrowany z programowaniem jest dość prosty:
1) Dodaj test
2) Wykonaj test i obserwuj przypadki negatywne
3) Dokonaj zmian
4) Wykonaj testy i obserwuj przypadki pozytywne
5) Przeanalizuj duplikaty i usuń
RUP - zunifikowany proces firmy Rational
RAD - szybki rozwój aplikacji
Prototyping – testowanie prototypów
Wyłączne prawa autorskie do tego dokumentu posiadają „testerzy.pl”. Rozpowszechnianie dla celów komercyjnych jak i
niekomercyjnych jest dozwolone tylko pod warunkiem podania źródła.