Czy narzędzia do śledzenia defektów naprawdę są potrzebne?

Czy narzędzia do śledzenia defektów naprawdę są potrzebne?
Narzędzia do śledzenia defektów istnieją. Wiemy, co zawierają, wiemy, jak ich używać, ale czy możemy jednoznacznie wskazać ich cel? Czas zakwestionować kolejny paradygmat testowania oprogramowania.


Kiedy już wreszcie nauczyliśmy się posługiwać narzędziami, nie możemy bez końca ślepo wierzyć w ich przydatność. Czasami nawet tylko dla pobudzenia mózgu możemy zadać sobie pytanie: Ale po co one są? Czy ciągle są tak konieczne w naszym środowisku? Te pytania, które po raz kolejny uwzględniają kontekst zmieniającego się świata nie są negacją tego, czego się nauczyliśmy, ale są próbą pchnięcia naszych działań do przodu.

 Okoliczności i otoczenie testowania oprogramowania znacząco się zmieniają. Są miejsca i zdarzenia, które przewartościowują raportowanie defektów do narzędzia.

Defekty muszą być raportowane do narzędzia...
Ci, którzy trwają przy swoim posługują się następnymi argumentami:

  • defekty nie zostaną zapomniane
  • możemy później w oparciu o nie wygenerować raporty
  • możemy odwoływać się do danych i statystyk z przeszłości.



AGILE
Obecnie, w podejściu zwinnym, przy nacisku na bezpośrednią komunikację ciężko jednoznacznie udowodnić przydatność narzędzi do śledzenia defektów.
Skoro stawiamy na silną komunikację wewnątrz zespołów, warto zastanowić się nad raportowaniem defektów bezpośrednio programiście. Dzięki temu nie będziemy tracili czasu na raportowanie, "pokażemy" programiście zamiast opisywać. Defekty i tak jakoś muszą zostać opisane, np. jako kartka na tablicy w sekcji TO DO.

DANE
Przetwarzanie danych jest ważne, ale w potoku danych projektowych kierownik ma na nie coraz mniej czasu. Oczywiście możemy obserwować trendy defektów teraz i w przeszłości, ale czy ich malejąca liczba jest jakąś wartościową informacją? Czy zwiększająca się różnica między defektami znalezionymi i naprawionymi mówi o postępie projektowym? Czy mówi coś o jakości produktu? Niekoniecznie.

JAKOŚĆ
Jeśli nie zaraportujemy defektów, to nie wiemy, ile ich całościowo mamy? Jak zmierzymy jakość produktu? Jak ocenimy postęp?

Tylko czy ilość defektów rzeczywiście mówi coś o jakości. Mówi o wysiłku "wprowadzenia" i "wyprowadzenia" defektów do/z oprogramowania, ale niewiele mówi o samej jakości. Łatwo wyobrazić sobie produkt, który ma defekty i jest zaakceptowany przez klienta (de facto tak jest w większości przypadków) i sytuację, w której aplikacja nie ujawnia żadnych poważniejszych defektów, a klient kwestionuje jej przydatność.

Zamiast analizować trendy defektów, może warto od nowa zdefiniować jakość i się do niej odwołać.


Inspirowane artykułem http://gojko.net/2011/05/17/bug-statistics-are-a-waste-of-time/
 

To powinno Cię zainteresować