Как Вы осуществляете или поддерживаете качество отчетов об ошибках в Вашем средстве отслеживания ошибки? [закрытый]

Другой подход, не использующий глобальные переменные, состоит в том, чтобы использовать передающий объект управления и связывать его свойства с переменными и методами, которые должны быть показаны.

export class MyComponentToControlFromOutside implements OnChanges {

  @Input() // object to bind to internal methods
  control: {
    openDialog,
    closeDialog
  };

  ngOnChanges() {
    if (this.control) {
      // bind control methods to internal methods
      this.control.openDialog = this.internalOpenDialog.bind(this);
      this.control.closeDialog = this.internalCloseDialog;
    }
  }

  internalOpenDialog(): Observable<boolean> {
    // ...
  }

  internalCloseDialog(result: boolean) {
    // ...
  }
}
export class MyHostComponent {
   controlObject= {};
}
<my-component-to-control [control]="controlObject"></my-component-to-control>

<a (click)="controlObject.open()">Call open method</a>
6
задан Vetle 30 August 2008 в 10:45
поделиться

6 ответов

Я соглашаюсь с Jon Limjap - Ваш персонал QA должен быть достаточно компетентен отправить соответствующие отчеты об ошибках, учитывая правильную начальную подготовку и инструкции. Тем не менее, существуют способы осуществить и поощрить лучшее создание отчетов ошибки:

  • Большая часть программного обеспечения отслеживания ошибок имеет способ отметить некоторые поля отчета об ошибках как обязательные, так, чтобы генератор отчетов на самом деле выбрал соответствующее значение для успешного создания ошибки
  • Обычно существует возможность включать основной шаблон для отчета об ошибках, чего-то в строках

Сценарий:

Ожидаемые результаты:

Фактические результаты:

Комментарии:

  • Вы можете (и если) обеспечивают инструмент создания отчетов ошибки, который будет выполнен на проблематичной машине, собрать релевантную информацию и упаковать ее в архивный файл (и возможно поместить ее в рабочий стол). Вы затем даете своему штату команду выполнять его каждый раз, когда они встречаются с ошибкой, они хотят сообщить и присоединить архив к ошибке. Этот инструмент должен быть простым в использовании (просто выполнение исполняемого файла) так, чтобы они присоединили бы информацию о диагностике к любой ошибке, не имея необходимость думать, релевантно ли это или нет. Этот инструмент обычно также очень полезен с клиентами.
  • Наконец, что не менее важно, - "образование, образование, образование". Люди учатся лучше всего из опыта - просто удостоверяются, что каждый раз, когда кто-то открывает ошибку без надлежащей включенной информации, человек, обрабатывающий ошибку, пошел бы и говорил бы с тем, который открыл ошибку, и объясните, что отсутствует и почему это важно.

Это методы, которые мы использовали вполне успешно на моем текущем рабочем месте, и я полагаю, что они довольно универсальны для установки к большинству рабочих сред.

3
ответ дан 17 December 2019 в 00:17
поделиться

Я раньше думал, что качество отчета об ошибках было эквивалентно. Я все еще думаю так... ошибки, что я сообщаю, имеют намного более полезную информацию в них, чем те вводимые QA или Операциями. Однако я возвратился к восхищению моделью FogBugz. Чрезвычайно просто ввести ошибку. Просто знание там является состоянием ошибки, полезно, даже если нет большой поддержки информации. Плюс, пользователи чувствуют, что что-то становится сделанным.

3
ответ дан 17 December 2019 в 00:17
поделиться

Это зависит от того, говорите ли Вы о закрытом обзоре QA и общедоступной бете.

Если это - общедоступная бета, не желательно позволить пользователям непосредственно отредактировать Ваш список ошибки. Кто-то должен быть присвоен совокупным комментариям пользователей и отчетам и различить, которые являются фактическими ошибками и которые являются дубликатами и которые дают своего рода ключ к разгадке о том, как копировать их.

Если это, однако, является объектом ошибки, который отправляется Вашим законным персоналом QA, у Вас есть проблема компетентности относительно Ваших сотрудников. Надлежащие инструкции должны быть установлены о том, как сообщить об ошибках, особенно в получении репликации ступает прямо.

0
ответ дан 17 December 2019 в 00:17
поделиться

Запишите пользу, но не слишком длинное учебное руководство при использовании средства отслеживания и что требуется для каждого поля. Сделайте справочный пример общего назначения, который могут использовать другие, если они застревают.

У меня есть ссылочная копия для редактирования страниц руководства DocBook, и при помощи этого неоднократно я уже знаю большую часть синтаксиса наизусть.

1
ответ дан 17 December 2019 в 00:17
поделиться

Сложный вопрос. Я попытался бы видеть, имеет ли система какой-либо способ осуществить это определенные поля, которых Вы требуете, вводятся, пытаются иметь любые ошибки, которые являются критической случайной встречей с Вашими глазами так или иначе (электронная почта, RSS), таким образом, можно атаковать быстро, но главным образом что команда знает о стандарте качества и придерживается его, инструкции публикуются и общественность, такая вещь.

Принятие это - Ваша команда: Если у Вас может быть определенная структура, которая используется каждый раз в поле комментариев, того, что ожидается, когда она будет введена, то это было бы хорошо также - еще лучше, если Ваше программное обеспечение имеет значение по умолчанию, отмечает схему, где можно определить ту структуру на незаполненном бланке.

До некоторой степени, хотя, это до человека, они должны знать, что это - часть стандартов связи, это ожидается как требование задания, и что они ответственны любому члену команды - потому что другие люди не должны быть в состоянии выслеживания их для обнаружения дальнейших деталей, если этого можно было бы избежать.

Тем более, что срок выполнения работы при исправлении ошибок на более низких приоритетных объектах мог пройти некоторое время, и люди обязаны быть забывчивыми в деталях.

Принятие это - пользователи: Вы не можете в высокой степени, но я попробовал бы - если это возможно, для задавания вопросов на любой форме способом, что люди могли понять.

Не полностью по этой теме, но в "то, как Вы задаете вопросы" способ, является этим сообщением на 37 блогах Сигналов - текст ссылки

Даже если у Вас должна быть другая форма, задавая вопросы, видимые Вашим пользователям, это только подает главным образом данные для прослушивания программы, я сделал бы это только для задавания правильных вопросов.

Какой продукт? Какая версия (изображения, показывающие, как найти его)? Было бы полезно включать снимок экрана, если они могли бы открыть программу и нажать кнопку для отправки через файл журнала автоматически, мешало ли это им делать дальнейшую работу, потеряло ли это их изменения и т.д.

Для пользователей это, вероятно, больше о том, как Вы задаете вопросы и разрешение им знать, что Вы требуете, чтобы определенные были отвечены, или которые Вы нашли бы более полезным, затем Вы, вероятно, получите лучшие ответы.

0
ответ дан 17 December 2019 в 00:17
поделиться

Используйте что-то вроде UserVoice , чтобы конечные пользователи сообщали об ошибках и запросах функций. Записи в системе отслеживания ошибок должны быть внутренними - они слишком технические для конечных пользователей, а также, IMHO, раскрывают слишком много внутренней работы.

0
ответ дан 17 December 2019 в 00:17
поделиться
Другие вопросы по тегам:

Похожие вопросы: