Redakcja
To generuje ukryty koszt po stronie zespołu produkującego oprogramowanie. Nie wynika on z samego testowania, ale z analizy, klasyfikacji i doprecyzowania zgłoszeń, które nie są jednoznaczne ani gotowe do pracy.
Osoby prowadzące testy to często użytkownicy, a nie testerzy. To powoduje, że ich zgłoszenia nie trzymają standardu, szczególnie jeśli szkolenia przygotowujące do prowadzenia testów zawiodły.
Defekt kontra zmiana
Defekt to niezgodność z wymaganiami, tzn. że system nie działa tak, jak opisano w specyfikacji. Z kolei zmiana to oczekiwanie modyfikacji istniejącego zachowania.
W praktyce zgłoszenia często mieszają te dwa obszary. Użytkownik zgłasza, że wyniki wyszukiwania powinny być lepiej posortowane. Jeśli system działa zgodnie ze specyfikacją, nie jest to defekt, lecz propozycja zmiany. A jeżeli takie zgłoszenie trafia do backlogu jako defekt, wpływa to na metryki jakości i priorytety pracy zespołu.
Konsekwencje są konkretne:
- liczba defektów jest sztucznie zawyżona,
- backlog przestaje odzwierciedlać rzeczywiste problemy,
- zespół analizuje zgłoszenia, które nie wymagają naprawy,
- priorytety są ustalane na podstawie oczekiwań, a nie defektów.
Problem jakości zgłoszeń
Zgłoszenia z UAT często nie zawierają podstawowych informacji: kroków odtworzenia, danych wejściowych, środowiska czy oczekiwanego rezultatu. Taki ticket nie może być od razu analizowany ani przekazany do realizacji.
Wiąże się to z konieczną do przeprowadzenia serią iteracji usprawnień zgłoszenia:
- próba odtworzenia problemu,
- potencjalny brak możliwości reprodukcji,
- kontakt ze zgłaszającym,
- uzupełnienie danych,
- ponowna analiza.
Każda taka iteracja opóźnia decyzję, czym jest dane zgłoszenie: defektem, zmianą czy pytaniem. Obsługa ticketu zaczyna obejmować kilka osób i kilka cykli komunikacji, zanim w ogóle trafi do realizacji.
SLA
Gdy produkt działa już na produkcji, umowa o poziomie usług definiuje czas odpowiedzi na pojawiające się raporty. Jeśli zgłoszenia podlegają SLA, liczy się czas reakcji. W efekcie zespół koncentruje się na tym, by odpowiedzieć na ticket w określonym czasie, niezależnie od tego, czy problem jest zrozumiały i gotowy do analizy.
SLA często musi być spełnione, mimo że zgłoszenie jest nieprecyzyjne, problem nie został odtworzony albo nawet nie podjęto żadnych działań naprawczych.
Praca przesuwa się w stronę obsługi zgłoszeń zamiast ich rozwiązywania. Czas zespołu jest konsumowany przez reakcję, a nie przez dostarczanie wartości.
Triage
Każde zgłoszenie musi zostać zakwalifikowane: czy jest odtwarzalne, czy wskazuje na defekt, jaki ma wpływ i czy dotyczy właściwego systemu. Przy dużej liczbie nieprecyzyjnych zgłoszeń proces ten szybko staje się wąskim gardłem.
Problem nasila się, gdy:
- zgłoszenia nie zawierają danych potrzebnych do oceny,
- brakuje jasnych kryteriów klasyfikacji,
- decyzje wymagają udziału kilku ról (test, dev, biznes).
Backlog zaczyna więc pełnić funkcję magazynu niezweryfikowanych zgłoszeń. Najcenniejsze problemy są mieszane z tymi, które wymagają dopiero doprecyzowania, przez co trudniej je wyłapać i właściwie zaplanować. Presja SLA dodatkowo spłaszcza ten proces. Zgłoszenia są obsługiwane szybko, ale nie zawsze poprawnie klasyfikowane.
Skutki
Gdy backlog zawiera dużą liczbę niejednoznacznych zgłoszeń, priorytety przestają wynikać z planu produktu i rzeczywistego wpływu na użytkownika.
Oznacza to, że:
- czas zaplanowany na sprint jest konsumowany przez analizę zgłoszeń,
- zadania planowane są wypierane przez bieżące reakcje,
- metryki jakości są zniekształcone przez zgłoszenia, które nie są defektami,
- zespół pracuje w trybie reaktywnym zamiast planowym.
Projekt przestaje być wówczas zarządzany przez cele produktowe, a zaczyna reagować na napływ zgłoszeń.
Wnioski
Koszt testów użytkowników przesuwa się na analizę zgłoszeń, a nie w samym testowaniu. Im mniej precyzyjne są tickety i im słabsza jest ich klasyfikacja, tym więcej czasu zespół poświęca na ich obsługę zamiast na rozwiązywanie problemów.
Ograniczenie tego kosztu wymaga:
- rozdzielenia defektów i zmian już na etapie zgłoszenia,
- wprowadzenia minimalnego standardu jakości (kroki, dane, oczekiwany rezultat),
- oddzielenia metryk reakcji od metryk rozwiązania,
- traktowania triage jako procesu decyzyjnego,
- ustalania priorytetów na podstawie wpływu, a nie subiektywnej pilności.
Bez tych elementów backlog przestaje być narzędziem zarządzania pracą, a staje się źródłem chaosu, który obniża tempo i jakość dostarczania produktu.
