Сортировка ошибок

From The Document Foundation Wiki
< QA‎ | BugTriage
Jump to: navigation, search

Введение

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

Где найти других членов команды QA

Есть несколько мест где можно найти членов из команды QA. Многие кто может помочь с вопросами по сортировке и люди, которые сами занимаются сортировкой часто появляются:

  1. Списки рассылки - члены команды часто общаются в чате в сети freenode.
    • libreoffice-qa@lists.freedesktop.org
    • libreoffice@lists.freedesktop.org
  2. IRC-каналы на Freenode.
  3. Члены команды QA
    • Список членов команды QA - не стесняйтесь добавлять свое собственное имя, если вы собираетесь участвовать в команде QA. Пожалуйста, связывайтесь с пользователем на прямую только в том случае, когда получили от него разрешение на это.

Шаги в сортировке ошибок

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

  1. Подготовка.
  2. Воспроизведение.
  3. Определение приоритета.

Порядок операций

  1. Найти ошибку для сортировки;
  2. Поиск дубликатов ошибки;
  3. Проверить информацию, представленную в отчет об ошибке;
  4. Попытаться воспроизвести ошибку
  5. Установить статус ошибки
  6. Определить приоритет
  7. Сообщить разработчикам - Нужно только в очень редких случаях, когда ошибка, кажется, блокирующей выпуск или критической.

Объяснение шагов

Подготовка

В основном, вы всегда будете хотеть сделать следующие шаги в процессе сортировки ошибок. Помните, что вы можете работать над ошибками, только будучи авторизованным в Bugzilla. Если у вас ещё нет учетной записи создайте её. После того как создадите учетную запись, если вы хотите быть уведомлены каждый раз, когда кто-нибудь отвечает в сообщении, в котором вы оставили комментарий, пойдите в настройки и установите Automatically add me to the CC list of bugs I change в Only if I have no role on them.

Шаг 1. Поиск ошибки для сортировки

Поиск Bugzilla - Перейдите в bugs.documentfoundation.org трекер ошибок LibreOffice. После авторизации просмотрите открытые ошибки по компонентам или сделайте пользовательский поиск:

  1. в поле Product: выберите LibreOffice;
  2. в поле Status: выберите UNCONFIRMED и/или REOPENED;
  3. добавьте любые другие критерии, которые вам интересны.

Когда вы авторизовались, вы можете начать искать ошибки, которые вам интересно обработать. Используйте расширенный поиск или введите условие в поле быстрого поиска (Помощь по быстрому поиску). Вы также можете использовать нижеприведённые прямые ссылки. Щелчок по ссылке переместит вас к результатам запроса на Bugzilla:

Шаг 2. Поиск ошибок дубликатов

Дубликаты являются ошибками отмеченные как RESOLVED DUPLICATE. Они очень близки или полностью совпадают с одной из ошибок, но отчет об ошибке подан разными пользователями. Отмеченные таким образом ошибки автоматически считаются Bugzilla и доступны на странице Most Frequently Reported Bugs for LibreOffice (Наиболее часто сообщалось об ошибках). При сортировке пожалуйста, проверьте этот список и сделайте быстрый поиск по ошибкам в Bugzilla, чтобы увидеть, есть ли какие-либо дубликаты. Но не следует тратить всю жизнь на это. :) Когда вы просмотрите большое число ошибок, вы сможете вспомнить аналогичные ошибки.

Если вы нашли дубликат ошибки перейдите к Шагу 5

Шаг 3. Проверка информации

Качественно преподнесённая информация необходима для программистов. Вам нужно проверить следующие пункты:

  1. Понятное и содержательное резюме;
  2. Понятное описание проблемы;
  3. Шаги воспроизведения проблемы, если это не понятно из темы или описания проблемы;
  4. Вложения - во многих случаях они необходимы, чтобы воспроизвести проблему, если вложения нет, это может затруднить исправления.

Если информация в отчете об ошибке не точная или её мало, перейдите к Шагу 5.

Некоторые вопросы не относятся к Bugzilla вообще. Для получения более подробной информации смотрите страницу Как сообщить об ошибке в LibreOffice?.

Если одна из этих ошибок подана в Bugzilla, измените статус на RESOLVED NOTOURBUG и добавьте следующий комментарий:
Thank you for getting in touch with us!    
Although Bugzilla sometimes feels like the center of the        
Universe, there are a few topics that need to be        
reported elsewhere. To find the right place to report   
your issue, please look at the BugReport wiki page:     
https://wiki.documentfoundation.org/QA/BugReport#Not_all_bugs_go_to_Bugzilla

Шаг 4. Попытка воспроизвести

Если отчет об ошибке прошёл все предыдущие шаги, осталось только попробовать воспроизвести ошибку.

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

  1. Привело ли ваше воспроизведение проблемы к тому же результату? Может быть они похожи, не не одинаковы?
  2. Оставил ли репортёр достаточно информации об ошибке, нужны ли дополнительные шаги, нужны ли дополнительные вложения?

Дополните её оставив комментарий, при необходимости, или запросите дополнительную информацию у репортёра.

Шаг 5. Установка статуса

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

Статус ошибки (Status) зависит от ваших результатов вышеупомянутых шагов. Ниже приводится краткое описание использования каждого статуса.

  1. NEW: Подтвержденные ошибка, вся необходимая информация есть.
  2. NEEDINFO: Отсутствует важная информация для воспроизведения ошибки. Попросите человека её дополнить.
  3. RESOLVED: Эта категория имеет несколько вариантов использование. Если вы не можете воспроизвести ошибку, в статусе нужно указать RESOLVED WORKSFORME. Для подробной информации смотри: WORKSFORME.
  4. VERIFIED: Эта возможность доступна только тогда, когда текущая ошибка получила статус RESOLVED. Вы можете установить статус ошибки RESOLVED FIXED (исправлена) как VERIFIED, когда вы подтверждаете, что она исправлена в упомянутой версии отчета об ошибке. Это также приятное для разработчика, который выполнил исправление, и является подтверждением решения проблемы. Иначе, репортёр ошибки может отметить свою собственную ошибку которая в статусе RESOLVED WORKSFORME как VERIFIED WORKSFORME, чтобы подтвердить её как исправленную.
  5. INVALID: Существует много причин почему ошибка может быть отмечена как необоснованная. Но это обычно требует участия других членов команды QA. Если вы столкнулись с ошибкой, которую считаете необоснованной, лучшим решением будет получение стороннего мнения от членов команды QA в рассылке или на канале.
  6. UNCONFIRMED: Этот статус получают все новые ошибки, которые не прошли сортировку.

Каждый раз, когда вы вносите изменения, вы должны сделать комментарий, вежливо объясняя, почему вы сделали эти изменения!

Ниже приведённые блок схемы показывают, как можно визуализировать установку статуса. Если у вас есть идеи, не стесняйтесь их выкладывать.

PDF file
LibreOffice Draw file

Шаг 6. Установка приоритета

В настоящее время выделяются только критические ошибки путём добавления в копию письма разработчиков, специальных записей в whiteboard, keywords и обновления трекера MAB (Самых досадных ошибок). Смотри: Дополнительные полезные шаги.

Пока что выставление приоритетов в сортировке ошибок находится в беспорядке, но люди, которые сортируют их, должны всегда активно стараться сделать её наилучшим образом. Также, выставление приоритетов относительно субъективно, но команда должна действовать согласовано в определении приоритета. Члены команды QA должны иметь четкое представление что собой представляет каждое состояние приоритета и стараться придерживаться этой методологии. Также, оставляя комментарий к ошибке после выставления приоритетов, невероятно важно дать знать репортёру (а также, разработчикам и другим пользователям) чем вы руководствовались при выборе приоритета.

Блок-схемы ниже примеры того, как визуально думать об установке статуса.

Пример в формате JPG
Пример в формате Draw

Дополнительные полезные шаги

Keywords

Поле Keywords содержит ключевые слова относящиеся к категории этой ошибки.

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

Новые регрессии, как правило, очень сильно раздражают пострадавших пользователей и легче в исправлении. Поэтому, они должны иметь более высокий приоритет. С другой стороны, если регрессия присутствует уже несколько месяцев или даже лет, и только теперь её нашли, видимо, эта малоиспользуемая функция. И таким образом, это менее важно.

Статус Whiteboard

Статусы Whiteboard - это дополнительные статусы, которые полезны для дополнения других элементов отчета. Некоторые эти статусы предназначены для привлечения внимания определённых груб разработчиков. Мы могли бы разделить их по назначению:

  • нарушается функциональность в конкретных областях: filter:xxx (filter:ooxml, filter:doc, filter:rtf, ...), perf
  • запрошена или предоставлена отладочная информация: bibisectRequest, bibisected
  • простые задачи: easyHack, difficultyBeginner, skillCPP
  • другие статусы, которые останавливаются автоматически: target:X.Y.Z, BSA

Существует один интересный статус: needsDevEval. easyHack это ошибка, которая, вероятнее всего, не отберёт много времени для исправления и может быть исправлена новым разработчиком или разработчиком без глубоких знаний программирования. Как команда QA мы не должны просто отмечать ошибку как easyHack, так как это требует дополнительных шагов (например, поиск разработчика как наставника и обратной трассировки). Если вы думаете, что это ошибка должна быть простой для исправления, пометьте её как needsDevEval и отправьте письмо в в список рассылки разработчиков с темой POSSIBLE EASY HACK FDO#.

Проверка дополнительной информации

Как сортировщики мы должны проверять информацию предоставленную репортёром отчета об ошибке. Они включают:

  • Product
  • Version
  • Platform

Добавление разработчиков в копию

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

Добавление членов QA в копию сообщения

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

Самые досадные ошибки

Действительно критические ошибки должны быть выделены в качестве Most Annoying Bugs (MAB). Пожалуйста, подумайте дважды, перед тем как добавлять ошибку в MAB, так как нам нужно вести список на разумном уровне.

Hard Hacks

Если ошибка кажется особенно трудной, влияет на значительное количество пользователей и будет рассматриваться как MAB, ошибка является кандидатом на Hard Hacks. Список этих ошибок можно найти здесь:

HardHacks wiki

Специальные замечания для команды QA

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

Специальное ПО и оборудование необходимое для воссоздания

Иногда нам нужно специальное программное обеспечение или аппаратное обеспечение для воспроизведения ошибки:

Extensions

Мы в настоящее время не имеем стратегии по сортировки ошибок расширений. Вот наш текущий план действий для ошибок с расширениями:

Рекомендуемый порядок сортировки

Целью команды QA является подтверждение в первую очередь самых серьёзных ошибок. Приведенные ниже таблицы, представляют собой предполагаемый порядок, чтобы ускорить сортировку.

Таблица по операционным системам (OS)

Описание Все ошибки Windows Linux OSX Комментарий
Блокирующие BlockerAll BlockerWindows BlockerLinux BlockerOSX В настоящее время пользователи могут устанавливается тяжесть собственных ошибок, если ошибка неправильно помечена как блокирующая, пожалуйста, измените тяжесть и объясните пользователю, почему ошибка не является таковой. Блокирующие ошибки зарезервированы только для самых серьезных ошибок (например, невозможность установить LibreOffice). Для руководства смотри PriorityFlowChart
Аварийное завершение CrasherAll CrasherWindows CrasherLinux CrasherOSX Это ошибки, которые имеют "crash" или какой-либо аналогичное слово в названии ошибки. Для ошибок с аварийным завершением тяжесть должна быть установлена ​​на Major/Critical/Blocker в зависимости от того, сколько пользователей будут затронуты. Кроме того, члены QA должны смотреть, является ли аварийное завершение регрессией или нет, и добавить "regression" в ключевые слова, если ошибка определяется как регрессия.
Потенциальные регрессии PossibleRegressionAll PossibleRegresionWindows PossibleRegressionLinux PossibleRegressionOSX Эти ошибки получают в ключевое поде слово PossibleRegression при добавлении через BSA, если пользователь сообщивший об ошибке сказал, что в той или иной версии ошибка не присутствовал. Если ошибка является регрессией, статус whiteboard PossibleRegression должен быть удален и вместо него поставлено "regression" в ключевые слова (keywords).
Ключевое слово регрессия RegressionAll RegressionWindows RegressionLinux RegressionOSX Сообщивший об ошибке мог поставить regression в поле keyword (ключевое слово). Не менее важно, строка выше, но FDO не позволяет использовать "или" в поиск, поэтому пришлось разбить на два ряда.
Критические ошибки CriticalAll CriticalWindows CriticalLinux CriticalOSX В настоящее время пользователи могут устанавливается тяжесть собственных ошибок, если ошибка неправильно помечена как критическая, пожалуйста, изменить тяжесть и объяснить пользователю, почему ошибка не является таковой. Critical зарезервировано для очень серьезных ошибок (например, потери данных, которые будут влиять на многих пользователей). Для руководства смотри PriorityFlowChart
Важные MajorAll MajorWindows MajorLinux MajorOSX В настоящее время пользователи могут устанавливается тяжесть собственных ошибок, если ошибка неправильно помечена как major, пожалуйста, изменить тяжесть и объяснить пользователю, почему ошибка не является таковой. Major зарезервировано для очень серьезных ошибок (например, потери данных), но которые, скорее всего, не влияют на многих пользователей или которые происходят только в тупиковая ситуация с отдельными документами. Для руководства смотри PriorityFlowChart.
Все другие ошибки AllBugs AllWindows AllLinux AllOSX Список всех отчетов об ошибках (без настройки). Если указанные выше ошибки отсортированы, тогда можно приниматься за сортировку этих. Предлагается делать их в хронологическом порядке (сначала старые, чтобы пользователи, которые сообщили раньше получили больший приоритет).
Запросы на улучшение EnhancementAll EnhancementWindows EnhancementLinux EnhancementOSX Запросы на улучшения обладают самым низким приоритетом для подтверждения.

Таблица по компонентам

Описание Writer Calc Impress Draw Database Other Комментарий
Блокирующие WriterBlocker CalcBlocker ImpressBlocker DrawBlocker DatabaseBlocker OtherBlocker В настоящее время пользователи могут устанавливается тяжесть собственных ошибок, если ошибка неправильно помечена как блокирующая, пожалуйста, измените тяжесть и объясните пользователю, почему ошибка не является таковой. Блокирующие ошибки зарезервированы только для самых серьезных ошибок (например, невозможность установить LibreOffice). Для руководства смотри PriorityFlowChart
Аварийное завершение WriterCrasher CalcCrasher PresentationCrasher DrawingCrasher DatabaseCrasher OtherCrashers Это ошибки, которые имеют "crash" или какой-либо аналогичное слово в названии ошибки. Для ошибок с аварийным завершением тяжесть должна быть установлена ​​на Major/Critical/Blocker в зависимости от того, сколько пользователей будут затронуты. Кроме того, члены QA должны смотреть, является ли аварийное завершение регрессией или нет, и добавить "regression" в ключевые слова, если ошибка определяется как регрессия.
Потенциальная регрессия WriterPosReg CalcPosReg PresentationPosReg DrawingPosReg DatabasePosReg OtherPosReg Эти ошибки получают в ключевое поде слово PossibleRegression при добавлении через BSA, если пользователь сообщивший об ошибке сказал, что в той или иной версии ошибка не присутствовал. Если ошибка является регрессией, статус whiteboard PossibleRegression должен быть удален и вместо него поставлено "regression" в ключевые слова (keywords).
Ключевое слово регрессия WriterRegression CalcRegression PresentationRegression DrawingRegression DatabaseRegression OtherRegressions Сообщивший об ошибке мог поставить regression в поле keyword (ключевое слово). Не менее важно, строка выше, но FDO не позволяет использовать "или" в поиск, поэтому пришлось разбить на два ряда.
Критические WriterCritical CalcCritical PresentationCritical DrawingCritical DatabaseCritical OtherCritical В настоящее время пользователи могут устанавливается тяжесть собственных ошибок, если ошибка неправильно помечена как критическая, пожалуйста, изменить тяжесть и объяснить пользователю, почему ошибка не является таковой. Critical зарезервировано для очень серьезных ошибок (например, потери данных, которые будут влиять на многих пользователей). Для руководства смотри PriorityFlowChart
Важные WriterMajor CalcMajor PresentationMajor DrawingMajor DatabaseMajor OtherMajor В настоящее время пользователи могут устанавливается тяжесть собственных ошибок, если ошибка неправильно помечена как major, пожалуйста, изменить тяжесть и объяснить пользователю, почему ошибка не является таковой. Major зарезервировано для очень серьезных ошибок (например, потери данных), но которые, скорее всего, не влияют на многих пользователей или которые происходят только в тупиковая ситуация с отдельными документами. Для руководства смотри PriorityFlowChart.
Все другие ошибки WriterOther CalcOther PresentationOther DrawingOther DatabaseOther AllOther Список всех отчетов об ошибках (без настройки). Если указанные выше ошибки отсортированы, тогда можно приниматься за сортировку этих. Предлагается делать их в хронологическом порядке (сначала старые, чтобы пользователи, которые сообщили раньше получили больший приоритет).
Запросы на улучшение WriterEnhance CalcEnhance PresentationEnhance DrawingEnhance DatabaseEnhance OtherEnhance Запросы на улучшения обладают самым низким приоритетом для подтверждения.

Список отчетов об ошибках, которые сложны для сортировки или закрыты