Привет!
Мой вопрос может показаться глупым и очевидным (по крайней мере он мне таким кажется), но все таки хотелось бы узнать ваше мнение:
Обязательно ли Bug Report должен содержать сценарий?
Что правильней:
- Если можно написать сценарий, то нужно его написать
- Если можно не написать сценарий, то нужно его не писать (если кому-то не понятно, то пусть спрашивают)
Конечно бывают случаи, когда сценария просто быть не может. Например если баг звучит так: Make Providers class public.
Что скажете по поводу темы?
Здравствуйте.
Мне кажется, что задаваться вопросом "что правильнее" в данном случае не очень корректно. Есть случаи когда правильнее написать, а есть, случае когда можно и не писать шаги воспроизведения проблемы.
Вот, что точно не правильно, это описывать дефект думая о том, что "если кому-то не понятно, то пусть спрашивают". Если есть сомнения - то надо написать.
Советы:
1. Если действия тривиальные или очевидные - то можно съэкономить время и опустить описание действий.
2. Можно описать дефект таким образом, что дополнительное описание шагов становится излишним.
3. Поробуйте найти более простой способ воспроизвести проблему. Зачастую, последовательность шагов, которая привела к ошибке, может быть существенна сокращена.
4. Есть такое понятие как root cause analysis. Т.е. поиск истинной причины дефекта. Бывают случаи, когда одна проблема имеет несколько путей воспроизведения. Писать несколько дефектов в этом случае - неправильно. Но вот указать, что данный дефект имеет различные проявления лишним не будет.
5. Если в дефекте описан четкий алгоритм воспроизведения проблемы это может съэкономить время разработчика, который будет чинить проблему. Да и понизит вероятность закрытия разработчиком бага как not reproducible.
6. Помните, что наличие шагов воспроизведения проблемы в описании дефекта значительно упрощает верификацию данного дефекта, после того как его починят. Ведь не факт, что его будет верифицировать человек, который написал.
7. Старайтесь описывать проблему так, чтобы она была понятна...ну например новичку, недавно начавшему работать в вашей команде. В данном случае, если у вас есть такой новичок - ему без проблем можно поручить верикацию дефектов, а он будет задавать при этом меньше вопросов.
Как резюме - лучше один раз потратить 5 лишних минут и описать шаги воспроизведения в тот момент когда вы обнаружили и изучили проблему и пишите ее в дефект-трэкер; чем потом (через неделю, месяц, год) вспоминать или придумывать как же подтвердить то, что проблему реально починили.