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/
 

5930

Powiązane szkolenia

05-06
czerwca
2023
Jarosław Hryszko
online
Praktyka testowania
1 750PLN
Testowanie aplikacji internetowych
12
Wolnych miejsc
Rezerwuj
06-07
marca
2023
Arnika Hryszko
online
Praktyka testowania
1 770PLN
Testowanie użyteczności
9
Wolnych miejsc
Rezerwuj
20-21
kwietnia
2023
Rafał Stańczak
online
Dobre praktyki testowania
1 700PLN
Testowanie w metodykach Agile
12
Wolnych miejsc
Rezerwuj
23-24
marca
2023
Krzysztof Kołodziejczyk
online
Praktyka testowania
1 770PLN
Testowanie aplikacji mobilnych - Android
9
Wolnych miejsc
Rezerwuj
12-13
czerwca
2023
Krzysztof Skarbiński
online
Automatyzacja testowania
1 800PLN
Testowanie REST API dla początkujących w języku python
11
Wolnych miejsc
Rezerwuj
27-28
lutego
2023
Krzysztof Kołodziejczyk
online
Języki programowania dla testerów
1 800PLN
JavaScript dla testerów oprogramowania
9
Wolnych miejsc
Rezerwuj
24-26
kwietnia
2023
Krzysztof Kołodziejczyk
online
Praktyka testowania
3 000PLN
Tester gier
11
Wolnych miejsc
Rezerwuj
13
marca
2023
-09
kwietnia
2023
Krzysztof Kołodziejczyk
online
Automatyzacja testowania
5 500PLN
Praktyka automatyzacji testowania
5
Wolnych miejsc
Rezerwuj

To powinno Cię zainteresować