1. Шаг 1
   1. Выбрать подходящий баг-трекер
   2. Определить ЖЦ бага в зависомости от модели разработки
   3. Стандартизировать процесс работы с багами по текущему проекту
   4. Создаем в ТФС запросы и диаграммы, позволяющие оценивать состояние проекта через призму багов
   5. Используем Test & Feedback extension для проведений сессий исследовательского тестирования и фиксации последовательности действий
2. Автогенерируемые поля
   1. Уникальный идентификатор. ID
   2. Автор
   3. Дата и время обнаружения дефекта
3. Наименование
   1. Высокоуровневое описание сути дефекта. Оно должно быть максимально емко, так как именно оно отображается в таск-трекере.
4. Описание
   1. Начальное состояние системы
   2. Сценарий (шаги) воспроизведения
      1. Должен быть четким, ясным, однозначным.
      2. Указываем пошагово сценарий воспроизведения дефекта. Если сценарий воспроизвдения будет неясен или шаги будут неодназначны, то разработчики скорее всего вернут баг с комментарием: Не воспроизводится, что в будущем повлечет дополнительные трудозатраты для доопределения и как следствие- задержка в устранении.
   3. Полученный результат
   4. Ожидаемое поведение
5. Аттач
   1. Логи
   2. Скриншоты
   3. Сертификаты
   4. Пользовательские файлы
6. Сборка
   1. На которой баг был найден
   2. На которой вопроизводится
   3. На которой не воспроизводится
7. Область (Area)
   1. Область приложения, где был обнаружен дефект
8. Дата и время
   1. Время, затраченное на поиск и описание соотвествующего таска в таск- трекере
   2. Время затраченное, на его перепроверку
   3. Номер/Id итерации, в которой дефект был найден
9. Severity&Priority
   1. Серьезность (Severity)
      1. S1 - Critical
         1. Последствие: Невозможность пользователя работать с продуктом
      2. S2-Hight
         1. Последствие: Несоответсвие заявленным требования, ожиданиям пользователя по функционалу
      3. S3 - Medium
         1. Последствие: Потеря или некорректная работа части используемых пользовательских функций
      4. S4 - Low
         1. Последствие: Раздражение пользователя от работы с системой
   2. Приоритет (Priority)
      1. P1 - High
         1. Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для дальнейшего тестирования и работы продукта в целом.
      2. P2- Medium
         1. Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения в ближайшее время.
      3. P3- Low
         1. Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.
      4. P4-Min
         1. Ошибка не обязательна к исправлению, так как текущий функционал не актуален или в ближайщее время будет изменен
10. Взаимосвязи
    1. ЮС (User Story)
    2. ID/шаг Тест-кейса
    3. ID cессии исследовательского тестирования
    4. ID бага
11. Тэги
    1. Доработка
    2. Не из кейсов
    3. Требуется согласование
    4. Недоопределено
    5. Регресс
    6. Релиз
    7. Пропущено
    8. Иссточник возникновения