Какво да правите, ако след повторното изпращане на грешката, разработчикът твърди, че това не е грешка?

В такъв случай ще предприема следните действия:

1. Проверка на грешката: Ще се уверя, че грешката се възпроизвежда в посочената тестова среда (версия на продукта, среда, ОС, браузър и т.н.), използвайки стъпките за възпроизвеждане от доклада за грешка.
2. Уточняване на стъпките за възпроизвеждане: Възможно е проблемът да е в неточност или непълнота на описанието на стъпките. Ще се опитам да ги направя възможно най-подробни и ясни.
3. Събиране на допълнителна информация: логове, скрийншоти/видео, мрежови заявки (ако е приложимо), данни от базата данни. Това ще помогне да се предостави повече контекст на разработчика.
4. Проверка на подобни случаи: Има ли имало подобни грешки в миналото? Как са били решени?
5. Лично обсъждане с разработчика: Ще изясня неговата гледна точка. Възможно е той да счита поведението за функция, да не е знаел за изискването или да вижда някаква специфика, която не е очевидна за мен. Диалогът често помага да се намери коренът на проблема.
6. Включване на Product Owner/Бизнес анализатор: Ако след обсъждане с разработчика не се постигне консенсус и съм сигурен, че има грешка, ще включа Product Owner или Бизнес анализатор за определяне на приоритета и последващите действия. Те могат да потвърдят, че поведението не съответства на изискванията или, обратно, да решат, че е допустимо.
7. Актуализиране на доклада за грешката: Ще добавя цялата събрана информация, резултатите от дискусиите и взетото решение.
8. Затваряне на грешката (ако е необходимо): Ако след решението на Product Owner/Бизнес анализатора или след постигане на консенсус с разработчика се установи, че това не е грешка или дефектът е допустим, ще затворя доклада с подходящ коментар.