Redakcja
Poprzednio opisaliśmy Wam "eksplozję przypadków testowych" i, pogłębiając koncept zbyt dużej ilości informacji o jakości, analizujemy kwestie tzw. ostrzeżeń. Ostrzeżenie (ang. warning) tym różni się od defektu, że w tym przypadku nie mamy pewności czy coś jest realnym problemem czy tylko niespełnieniem mało znaczącej reguły.
Załóżmy, że Wasze oprogramowanie należy do tych najbardziej popularnych technologicznie, czyli jest aplikacją webową znajdującą się dodatkowo w ogólnodostępnym Internecie. Możecie dzięki temu użyć dziesiątek (a nawet setek) dostępnych walidatorów, jak np.
- walidatory kodu HTML i CSS, JSON, XML...
- walidatory dostępności
- walidatory bezpieczeństwa
- walidatory stron pod kątem kodów 4XX i 5XX
- Lighthouse z Chrome z testami wydajności, „najlepszymi praktykami”, SEO, testem PWA...
- konsole do analizy JS-a
- i wiele, wiele innych.
Każdy z nich potrafi wygenerować dziesiątki i więcej informacji o potencjalnych defektach w oprogramowaniu. Uruchomienie każdego z nich i pozbieranie wyników możemy nazwać eksplozją ostrzeżeń. Każde z nich wymaga analizy ręcznej (czy raczej umysłowej) pod kątem jego wpływu na końcowego odbiorcę oprogramowania lub też wpływu na kryteria akceptacji oprogramowania. Część odpowiedzialności za analizę spada na testerów. Co warto podkreślić znacząc większość ostrzeżeń nie będzie miała żadnego znaczenia dla odbioru jakości, ponieważ albo będą to problemy z kodem niewidoczne na interfejsie, albo dotykające znikomą część użytkowników.
Aby ograniczyć liczbę ostrzeżeń możemy zbudować listę walidatorów (najlepiej ułożonych priorytetami uruchomienia), które zwracają nam informacje przydatne dla naszych klientów. Przykładowo, jeśli zależy im na wydajności nie możemy pominąć dostępnych online narzędzi, które zwrócą nam nie tylko informacje o tym co jest nie tak, ale również co zrobić aby było lepiej. Jest to duży skrót w pracy z programistami.
Innym rozwiązaniem na uniknięcie eksplozji usterek w większości projektów będzie... unikanie walidatorów. Możemy to zrobić, bo ich zastosowanie niezmiernie rzadko pojawia się w umowach lub też wymaganiach klienta. Narzędzie same w sobie mogą nam zwrócić wartościowe informacje o jakości, ale zazwyczaj są one zagrzebane w tysiącach wymagających analizy nic nieznaczących ostrzeżeniach.
Jest też opcja pośrednia by przy pomocy odpowiednich filtrów (lub ustawionych flag) ograniczać zakres analizy i skoncentrować się jedynie na rzeczach ważnych. Innym rozwiązaniem jest skorzystanie z pomocy skryptów i automatycznie analizować logi walidatorów pod kątem rzeczy ważnych w projekcie. Odpowiedzialność spada oczywiście na kontrolerów jakości, którzy podejmują decyzję o tym, czy dane ostrzeżenie jest realnym problemem i czy zasługuje na raport defektu. Raport ma w konsekwencji prowadzić do uzyskania poprawki. Raportowanie ostrzeżeń, które na końcu nie doczekają się naprawy może być postrzegane jako błąd testera.
Grafika wygenerowana w Midjourney.
