Cykl wytwarzania oprogramowania

December 1st, 2008
  1. Programista tworzy kod wierząc, że nie zawiera on błędów.
  2. Dział testów znajduje 20 błędów w aplikacji.
  3. Programista poprawia 10 z nich i wyjaśnia, że pozostałych 10 to nie błędy.
  4. Dział testów odrzuca 5 z 10 poprawek i znajduje 15 nowych błędów.
  5. Cykl poprawki/retesty powtarza się 3 razy.
  6. Z powodu nacisków działu marketingu i nadmiernie optymistycznego planu developementu produkt zostaje wypuszczony.
  7. Klient znajduje 137 błędów.
  8. Programista, który stworzył system, pobrał już wynagrodzenie z kontraktu i jest nieosiągalny.
  9. Utworzony na nowo zespół programistów poprawia wszystkie ze 137 błędów, wprowadzając jednocześnie 456 nowych.
  10. Programista, który stworzył system wysyła kartkę z Fiji do niedofinansowanego działu testów. Dział testów odchodzi.
  11. Firma zostaje kupiona przez konkurencję za profity uzyskane ze sprzedaży ich ostatniej aplikacji, która zawiera 783 błędy.
  12. Nowy szef zatrudnia programistę, aby napisał ten sam program od podstaw.
  13. Programista tworzy kod wierząc, że nie zawiera on błędów…

Tags: ,

Analiza ryzyka przy tworzeniu przypadków testowych

November 27th, 2008

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: , , ,

Metodologia WHISKY

November 25th, 2008

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: , ,

Cykl, faza, typ, technika testowania

September 2nd, 2008

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: , , , ,

Smoke test i Sanity test

June 18th, 2008

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: , , , ,

Pages: Prev 1 2 3 4 5 6 7 8 Next