Poluj na informacje, a nie na defekty

Poluj na informacje, a nie na defekty
Obowiązkiem testera oprogramowania nie jest wyśledzenie i wynalezienie każdego defektu w oprogramowaniu. Naszą odpowiedzialnością jest zdobycie informacji, która będzie przydatna w projekcie.

Aby to zrobić na pierwszym miejscu musimy zrozumieć kontekst projektu i otoczenie naszego użytkownika. Kupujący oprogramowanie nie rzuci się na nie w poszukiwaniu błędów, a będzie próbował realizować zadania, jakie wspiera dane narzędzie. Czy będzie to gra komputerowa czy oprogramowanie do tworzenia procesów, użytkownik pokłada wiarę, że będzie ono dobrze mu służyło. Dlaczego więc tester oprogramowania miałby koncentrować się na wyszukiwaniu najmniejszych problemów oprogramowania? Dlaczego miałby być zorientowany na problemy, zamiast koncentrować się na scenariuszach pracy użytkownika?

Kiedy zależy nam na projekcie i chcemy pokazać nasze umiejętności, znalezienie defektu staje się naszą małą obsesją. Zaczynamy testować oprogramowanie i póki nie znajdziemy tego pierwszego, ważnego defektu pojawia się denerwujące poczucie braku realizacji celu. Kiedy się już jednak go znajdzie, pojawia się to wyjątkowe uczucie pewności siebie. Te emocje można, a nawet trzeba, zachować dla siebie. Nikt w projekcie nie zrozumie jeśli, niczym piłkarz po strzeleniu gola, będziemy na kolanach przejeżdżać między boksami w przestrzeni biurowej, ciesząc się i krzycząc "Jest!". Nikt nie ucieszy się na widok wystrzelonego w górę konfetii, kiedy natrafimy na defekt blokujący wejście oprogramowania na produkcję.

Poszukiwanie defektów jest ekscytujące, ale ich znajdywanie nie cieszy użytkowników, programistów czy kierowników. Coś, co testerom dostarcza emocji, resztę może mocno zdenerwować. Z jednej strony lepiej mieć świadomość, że defekt w oprogramowaniu jest i możemy go usunąć niż przepuścić go na produkcję. Najlepiej jednak kiedy udałoby się wyprodukować oprogramowanie bez poważnych defektów.

Warto więc zamiast szukania defektów koncentrować się na informacji. Ilość znalezionych defektów także jest informacją, ale nie warto z tej informacji robić najważniejszej wiadomości dnia. Oprogramowanie z defektami może wyjść do klienta pod warunkiem, że mamy pełną informację o konsekwencjach defektów i przekonanie, że klient jest w stanie działać wydajnie pomimo ich obecności. Nie da się tego osiągnąć jeśli naszym jedynym celem jest znajdywanie defektów.

 

Inspirowane: blog.smartbear.com/testing/hunt-for-information-not-bugs/

 

5587

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ć