Co zrobić, jeśli po ponownym zgłoszeniu błędu programista twierdzi, że to nie jest błąd?

W takim przypadku podejmę następujące działania:

1. Sprawdzę błąd: Upewnę się, że błąd jest odtwarzalny w zadanym środowisku testowym (wersja produktu, środowisko, OS, przeglądarka itp.), korzystając z kroków reprodukcji z raportu błędu.
2. Wyjaśnię kroki reprodukcji: Możliwe, że problem wynika z nieścisłości lub niepełności opisu kroków. Postaram się uczynić je jak najbardziej szczegółowymi i jednoznacznymi.
3. Zbiorę dodatkowe informacje: Logi, zrzuty ekranu/filmy, żądania sieciowe (jeśli mają zastosowanie), dane z bazy danych. To pomoże dostarczyć więcej kontekstu deweloperowi.
4. Sprawdzę podobne przypadki: Czy w przeszłości występowały podobne błędy? Jak zostały rozwiązane?
5. Porozmawiam osobiście z deweloperem: Wyjaśnię jego punkt widzenia. Może uważać zachowanie za funkcję, nie znać wymagań lub widzieć jakąś specyfikę, która nie jest dla mnie oczywista. Dialog często pomaga znaleźć źródło problemu.
6. Zaangażuję Product Ownera/Analityka biznesowego: Jeśli po dyskusji z deweloperem nie osiągnięto konsensusu i jestem pewien, że to błąd, zaangażuję Product Ownera lub Analityka biznesowego, aby określić priorytet i dalsze działania. Mogą potwierdzić, że zachowanie nie spełnia wymagań lub, odwrotnie, uznać je za dopuszczalne.
7. Zaktualizuję raport błędu: Dodam wszystkie zebrane informacje, wyniki dyskusji i podjętą decyzję.
8. Zamknę błąd (jeśli konieczne): Jeśli po decyzji Product Ownera/Analityka biznesowego lub po osiągnięciu konsensusu z deweloperem okaże się, że to nie jest błąd lub wada jest dopuszczalna, zamknę raport błędu z odpowiednim komentarzem.