testowanie.net

Analiza ryzyka przy tworzeniu przypadków testowych

Analiza ryzyka pomaga określić na czym skupić się podczas planowania i przeprowadzania testów.  Ponieważ rzadko można pozwolić sobie na przetestowanie każdego aspektu systemu, kombinacji wyjątków czy każdej zależności, stosowanie analizy ryzyka jest niezbędne w większości projektów.

Wymaga to umiejętności wartościowania, zdrowego rozsądku i doświadczenia.  Pod rozwagę można brać następujące czynniki:

• Która grupa funkcjonalności jest krytyczna dla poprawnego działania aplikacji?
• Które funkcjonalności są najbardziej widoczne dla użytkownika?
• Które funkcjonalności mają największy wpływ na bezpieczeństwo?
• Które części aplikacji były tworzone w pośpiechu, np. tuż przed datą oddania modułu?
• Które aspekty podobnych/powiązanych poprzednich projektów powodowały problemy?
• Jaki zdaniem programistów jest najbardziej ryzykowny aspekt tworzonego systemu?
• Jaki rodzaj problemów może wywołać największe niezadowolenie klienta?
• Które funkcjonalności mają największy wpływ na finansową stronę projektu?
• Jakie aspekty aplikacji są najważniejsze z punktu widzenia klienta?
• Które aspekty podobnych/powiązanych poprzednich projektów wymagały największego nakładu pracy w fazie utrzymania (maintenance)?
• Która część wymagań/interfejsów jest niewystarczająco zdefiniowana lub nieprzemyślana?
• Które aspekty aplikacji mogą zostać przetestowane najwcześniej?
• Które fragmenty kodu są najbardziej złożone (zawierają potencjalnie wiele błędów)
• Jaki rodzaj testów może łatwo pokryć możliwie największą liczbę funkcjonalności?
• Które z przeprowadzanych testów będą miały najlepszą zależność: pokrycie funkcjonalności o wysokim priorytecie / czas na wykonanie testów?

Tags: aplikacja, przypadek testowy, ryzyko, Testowanie

Posted in Testowanie | No Comments »

Metodologia WHISKY

Ted Neward powiedział, że nie ma sensu dzielić metodyk zarządzania na kaskadowe, iteracyjne czy na lekkie vel zwinne.

Czemu? I tak wszyscy stosują metodologię WHISKY - Why the Hell Isn’t Somebody Koding Yet?!?

zaczerpniete z Java Developer Day 2008

Tags: Humor, metodologia, Testowanie

Posted in Testowanie | No Comments »

Cykl, faza, typ, technika testowania

Cykl testowy, faza testów, typ testu, technika testowania.

Cykl jest powtarzaną sekwencją akcji lub mówiąc inaczej, pojedyńczym, kompletnym wykonaniem okresowo powtarzalnej aktywności.
“Cykl testów” oznacza wykonanie wszystkich zawartych w nim faz testów, przy czym od projektu zależy jak bardzo “eksploatowana” będzie każda faza.

Każdy projekt w trakcie powstawania, składa się z wielu kolejnych wersji (releases, builds). Cykl testów zawiera w sobie wszystkie te wersje pod warunkiem, że testowanie rozpocznie się na odpowiednio wczesnym etapie tworzenia systemu.

Inne podejście to przypisanie cyklu testów do każdej dostarczanej do testów wersji aplikacji. W niektórych projektach takie podejście może okazać się bardziej odpowiednie.

Faza jest zazwyczaj definiowana jako konkretny etap w powtarzającym się okresowo procesie. Fazę można traktować jak część kompletnego cyklu testów. Przykłady faz:
- testy specyfikacji
- testy jednostkowe
- testy integracyjne
- testy systemowe
- testy akceptacyjne

Typ testu jest składową fazy, przy czym ten sam typ testu może powtarzać się w różnych fazach. Np. testy funkcjonalne występują zarówno w fazie testów systemowych jak i akceptacyjnych. Przykłady typów testów:
- funkcjonalny
- bezpieczeństwa
- wydajnościowy
- użyteczności

Technika testowania jest to procedura wg której realizowane są (zazwyczaj złożone) zadania. Inaczej mówiąc jest to metoda lub zbiór metod używanych do osiągnięcia pożądanego rezultatu. Technika testowania jest składową typu testu co zazwyczaj oznacza sposób w jaki dany typ testu jest wykonywany.

W zależności od typu przeprowadzanego testu używane są różne techniki testowania, np:
- regresywna
- klasy równoważności
- badanie wartości brzegowych
- sprawdzanie integralności danych

Tags: cykl testu, faza testu, technika testowania, Testowanie, typy testów

Posted in Testowanie | No Comments »

Smoke test i Sanity test

Smoke test określa czy możliwe jest przeprowadzenie testów.
Sanity test odpowiada na pytanie czy jest to zasadne.

Smoke test

Smoke test mówi nam, czy program/system da się uruchomić, czy jego interfejsy są dostępne i czy reagują na działania użytkownika. Jeżeli smoke test nie powiedzie się nie ma powodu aby przechodzić do sanity testów. Ten typ testów przeprowadzany jest przez programistów tuż przed oddaniem wersji aplikacji lub przez testerów, przed zaakceptowaniem otrzymanej do testów aplikacji.

Pojęcie “smoke test” powstało na potrzeby testów sprzętu. Sam test polegał na włączeniu nowego urządzenia i sprawdzeniu czy nie pojawił się dym lub ogień
Somke testy mogą być wykonywane na podstawie istniejących przypadków testowych lub przy użyciu narzędzi do testów automatycznych

Przeznaczeniem smoke testów jest “dotknięcie” każdej z części aplikacji bez zagłębiania się w logikę jej działania. Chodzi o upewnienie się, czy najbardziej krytyczne funkcje działają.

Sanity test

Sanity test sprawdza pojedyńcze funkcjonalności i daje odpowiedź na pytanie: czy logika aplikacji jest zgodna z dostarczonymi wymaganiami. Jeżeli przeprowadzenie sanity testu da negatywne rezultaty, nie ma powodu, aby przechodzić do następnej fazy testowania.

Sanity oraz smoke test należą do tej samej grupy testów, której atrybutami są:
- szybko,
- w szerokim zakresie,
- bez zagłębiania się w szczegóły działania testowanej funkcjonalności.

Sanity test koncentruje się na jednym lub kilku obszarach systemu badając jego zgodność z logiką biznesową.Zazwyczaj nie jest opisany w przypadkach testowych.

Jest to odmiana testów regresywnych - obszar systemu testowany jest po dokonaniu w nim znaczących zmian dotyczących sposobu jego działania.

Sanity test daje odpowiedź na pytanie czy to co testujemy jest zgodne z wymaganiami i specyfikacją systemu.

Tags: oprogramowanie, sanity test, smoke test, software, Testowanie

Posted in Testowanie | 1 Comment »

Dlaczego oprogramowanie zawiera defekty?

Przyczyny dla których w projekcie mogą pojawić się błędy, można przypisać do kilku grup.

• Wprowadzone przez człowieka na każdym z etapów SDLC, począwszy od etapu analizy wymagań na instalacji gotowego produktu kończąc.

• Sprzęt/środowisko. “Błędy” z tej grupy nie są wynikiem źle napisanego czy nieprzetestowanego kodu, ale jego brakiem, np. brak funkcji obsługującej sytuację w której zerwane zostaje połączenie sieciowe w trakcie przesyłania danych przez aplikację.

• Złożoność systemu
Złożoność systemu może być trudna do zrozumienia dla kogoś bez doświadczenia w funkcjonującym dzisiaj sposobie tworzenia oprogramowania. Interfejsy wzorowane na oknach, technologia klient-serwer, aplikacje rozproszone, komunikacja danych i relacyjne bazy mają swój udział w szybko przyrastającej złożoności oprogramowania/systemów. Również użycie technik obiektowych, zamiast uprościć może skomplikować projekt jeżeli nie jest on dobrze skonstruowany.

• Błędy w kodzie
Programiści jak każdy z nas, popełniają błędy. Część z nich może powstać w wyniku interpretacji źle lub niewystarczająco jasno zdefiniowanych wymagań. Zakładając, że błędów nie da się uniknąć i że zostaną one odnalezione przez testerów jest ważne aby być przygotowanym do zarządzania nimi za pomocą narzędzi komercyjnych np. Rational, lub opensource np. Mantis.

• Zmieniające się wymagania
Klient może nie być świadomym efektów zmian lub chce je wprowadzić pomimo ryzyka z którego zdaje sobie sprawę - redefiniowanie wymagań, estymacja liczby godzin przeznaczonych na dodanie/modyfikację funkcjonalności, wpływ zmian na równoległe projekty, konieczność ponownego wykonania tej samej pracy lub porzucenia części działającego i przetestowanego już kodu, zmiana wymagań sprzętowych (zazwyczaj w górę).

Wiele drobnych lub kilka dużych zmian może wpłynąć na wytworzone (zdefiniowane lub nieformalne) zależności wewnątrz projektu i stać się przyczyną problemów, podobnie jak rosnąca złożoność procesu zarządzania.

• Presja czasu
Planowanie w projektach informatycznych jest w najlepszym przypadku trudne, częściowo opiera się na przewidywaniu. Może zdarzyć się, że zbliżający się termin oddania aplikacji staje się jedynym wyznacznikiem jakości kodu.

Tags: błędy, defekty, oprogramowanie, przyczyny błędów, wymagania

Posted in Testowanie | No Comments »