Мажорная и минорная ошибка

• Серьезность
• Приоритет
• Глобальный приоритет
• Высокий приоритет и низкая серьезность
• Высокая серьезность и низкий приоритет

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

Поэтому баги, внесенные в системы отслеживания (bug-tracking системы), дифференцируются.

Каждый баг имеет атрибуты серьезности (Severity) и приоритета (Priority). На первый взгляд может показаться, что разницы между этими понятиями нет, но она все же есть. Серьезность больше касается технической стороны дела, а приоритет — организационной.

Серьезность (Severity) бага

Severity — это атрибут, характеризующий влияние бага на общую функциональность тестируемого продукта.

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

Пример классификации серьезности багов:

• Blocker. Блокирующая ошибка. Она делает невозможной всю последующую работу с программой. Для возобновления работы нужно исправить Blocker.
• Critical. Критическая ошибка. Нарушает работу основного функционала. Баг проявляется постоянно и делает невозможным использование основных функций программы.
• Major. Существенный баг. Затрудняет работу основного функционала или делает невозможным использование дополнительных функций.
• Minor. Незначительный баг. На функционал системы влияет относительно мало, затрудняет использование  дополнительных функций. Для обхода этого бага могут быть очевидные пути.
• Trivial. Тривиальный баг. Не влияет на функционал проекта, но ухудшает общее впечатление от работы с продуктом.

Приоритет (Priority) бага

Приоритет — атрибут, определяющий скорость устранения бага.

Приоритет бага сперва определяет инициатор, но в дальнейшем он корректируется менеджером продукта. Именно менеджер имеет общее представление о тестируемой системе и понимает, насколько срочно нужно исправить тот или иной баг.

Виды приоритетов:

• Top. Наивысший приоритет. Назначается экстренным ситуациям, которые очень отрицательно влияют на продукт или даже бизнес компании. Такие баги нужно устранять немедленно.
• High. Высокий приоритет. Назначается багам, которые должны быть устранены в первую очередь.
• Normal. Обычный приоритет, назначается по умолчанию. Эти баги устраняются во вторую очередь, в штатном порядке.
• Low. Низкий приоритет. Назначается багам, не влияющим на функционал. Исправление таких багов происходит в последнюю очередь, если есть время и ресурсы.

Также нужно упомянуть о частоте проявления бага.

Частота (Frequency) — это показатель количества пользователей, которые сталкиваются с ошибкой. Определяется при анализе алгоритмов.

Частота бывает:

• High. Высокая: с багом сталкиваются больше 80% пользователей.
• Medium. Средняя: баг обнаружат от 30% до 80% пользователей.
• Low. Низкая: баг проявляется у 10-30% пользователей.
• Very low. Незначительная: такой баг встретится меньше чем 10% пользователей.

Глобальный приоритет бага (Global Severity)

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

Таким образом, для определения глобального приоритета бага нужно:

1. Определить серьезность бага.
2. Отдельно от серьезности определить приоритет.
3. Определить частоту (независимо от серьезности и приоритета).
4. Рассчитать влияние частоты на изначально определенный приоритет.

Если частота у бага высокая, приоритет возрастает на одну позицию. Скажем, если изначально приоритет был Normal, но частота высокая, приоритет определяется как High.

Средняя частота бага меняет приоритет только с низкого на обычный.

Низкая или незначительная частота вообще не меняет приоритет бага.

Для определения глобального приоритета можно пользоваться следующей таблицей:

Если глобальный приоритет — Critical, значит, баг нужно непременно исправить. Баги с приоритетом Minor тоже желательно исправить до релиза, хотя некоторое количество таких дефектов может остаться в проекте. Баги с приоритетом Trivial могут вообще не исправляться.

Высокий приоритет и низкая серьезность

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

Вот пара примеров:

1. Кнопки перекрывают друг друга. Они кликабельны, но визуальное впечатление портится.
2. Логотип компании на главной странице содержит орфографическую ошибку. На функционал это вообще не влияет, но портит пользовательский опыт. Этот баг нужно исправить с высоким приоритетом, несмотря не то, что на продукт он влияет минимально.

Высокая серьезность и низкий приоритет

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

Примеры:

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

Итоги

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

Время на прочтение
7 мин

Количество просмотров 6.7K

Всем доброго дня!

Наша компания занимается разработкой ПО для госсектора и постоянно сертифицирует свои программы для обработки гос. тайны. А это накладывает определенные ограничения и самое главное из них: мы должны предоставить все исходные коды нашего проекта и если попросят — суметь объяснить, что делает каждая строчка. Проблема в том, что если используешь готовые компоненты, то их исходники тоже нужно предоставлять и уметь все про них рассказать. Поэтому мы решили сделать свой фреймворк, ведь про него мы будем знать все. Фреймворк мы сделали и назвали его «Platform». Он продолжает развиваться и все свои проекты мы делаем на нем. Проблема заключается в том что, после выпуска продукта и его сдачи мы вынуждены его замораживать и не можем в него вносить больших изменений — только исправлять баги, а большинство багов обнаруживается как раз в самом фреймворке и в результате мы вынуждены иметь версии фреймворка для каждого сданного проекта (ну, или для группы одновременно выпущенных продуктов). В итоге, нам пришлось придумать свой набор правил и схему ветвления в GIT для разработки Platform. Схема приведена ниже вместе с примером работы по ней:

Общие правила ветвления проектов:

1.     Введены следующие понятия:

a.      Мажорная версия программы – версия программы в рамках определенной концепции, меняется при значительных изменениях концепции, обозначается v-m, где m – номер мажорной версии;

b.     Минорная версия программы – подверсия в рамках одной концепции, меняется при добавлении нового функционала или незначительной переделке существующего, обозначается v-m-n, где m – номер мажорной версии, n – номер минорной версии;

c.      Релиз программы – вариант минорной версии, номер релиза меняется при незначительных изменениях и/или исправлении багов в соответствующей минорной версии программы, обозначается r-m-n-p, где m – номер мажорной версии, n – номер минорной версии, p – номер патча;

2.     Разработка нового функционала ведётся в ветке master. Ветка master защищённая, для помещения изменений в неё разработчиками выполняется merge-request. Решение по принятию merge-request принимает технолог на основании просмотра исходного кода вносимых изменений (code review).

3.     Для каждой мажорной версии создается ветка разработки нового (дополнительного функционала). Для текущей мажорной версии это ветка master, для прошлых мажорных версий ветки разработки называются по шаблону: dev-v-m, где m – номер мажорной версии. Работа с этой веткой аналогична работе с веткой master. Для каждой ветки dev-v-m создается своя база данных и именуется по шаблону project_name_dev_v_m. Ветка разработки для мажорной версии создается сразу после начала работы над следующей мажорной версии.

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

a.      t-xxxxx, если это задача на разработку нового функционала  (xxxxx – номер задачи из корпоративной системы)

b.     b-xxxxx, если это задача по исправлению бага (xxxxx – номер задачи из корпоративной системы).

5.     После выполнения задачи и помещения коммитов тематической ветки в ветку, для которой выполнялась задача, разработчик удаляет тематическую ветку.

6.     При постановке задачи на исправление бага нужно указывать минорную версию, в которую нужно вносить изменения, например, в версию v-1-1 (если ничего не указано, то баг исправляется в тестируемой на данный момент минорной версии). При исправлении бага в ветке master, главный технолог должен принимать решение о необходимости включения этого исправления в ветку с актуальной версией. Задачи по добавлению функционала предполагают помещение их в ветку master по умолчанию, иначе должна быть указана конкретная ветка (ветки) разработки прошлой мажорной версии.

7.     Периодически (по мере реализации функционала) формируются минорные версии. Каждая минорная версия – это отдельная ветка. Ветка минорной версии обозначается по шаблону v-m-n, где m – мажорный номер версии, n – минорный номер версии. В рамках версий формируются релизы. Релизы формируются тогда, когда исправлены все обнаруженные баги в тестируемой минорной версии. Релиз обозначается тегом формата r-m-n-p, где m –   мажорный номер версии, n – минорный номер версии, p – номер патча (патч выпускается только для исправления багов). После создания ветки минорной версии в ней правятся только баги. Ветка минорной версии создается главным технологом в момент окончания разработки функционала версии, но до начала основного тестирования. При формировании минорной ветки, нужно дополнять в проекте файл с изменениями в этой версии по отношению к предыдущей.

8.     После формирования релизного тега, ветка минорной версии должна быть слита с основной веткой разработки.

9.     После выпуска релиза следующей минорной версии, поддержка предыдущей минорной версии прекращается.

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

11. Небольшую доработку функционала можно вносить в ветки минорной версии, но это только в крайних случаях.

12. Коммиты именуются по следующему правилу: t-#####-taskname или b-#####-bugname.

На  рисунке представлен пример стратегии ветвления для условного проекта, который отражает вышеизложенные  правила. Рассмотрим пример подробно:

Проект начался с 01.01.17 с создания нового репозитория и инициирующего коммита C1 в ветке master. Ветка master предназначена для основного процесса разработки и добавления нового функционала. Ветка мастер защищенная и никто, кроме главного технолога или его заместителя (далее под главным технологом так же подразумевается и его заместитель) не имеет права вносить в неё изменения. Для получения первого релиза было запланировано добавить функционал, описанный в задача 1 и 2 в корпоративной системе. Для реализации каждой из задач на основании коммита C1 разработчиками были созданы ветки и названы в соответствии с соглашением о наименовании (t-####) t-1 и t-2. В рамках данных веток были сделаны коммиты (например, в ветке t-1 t-1-C1 и t-1-C2). После создания функционала в своих ветках разработчики хорошо его протестировали самостоятельно, потому что они профессионалы и хорошие люди и им не наплевать на то, что они делают и на остальной коллектив. После этого разработчики выполняют merge request для своих веток, т.е. сигнализируют технологу, что они закончили свою работу и хотят, чтобы их код был внесен в основную ветку разработки. Главный технолог отправляет задачу на code review (поручает это другому программисту или производит самостоятельно). Если код не устраивает, то merge request отклоняется, и программист переделывает работу. Если код успешно проходит стадию code review, то главный технолог принимает merge request и в ветке мастер появляются коммиты C2 и С3. После появления этих коммитов в ветке master задачи начали тестировать тестировщики и аналитики ответственные за за задачу. Если были обнаружены ошибки, то задачи возвращаются на переделку, если нет, то задача закрывается в корпоративной системе.

         08.01.17 был готов функционал для версии 1-0 и главный технолог принял решение о создании релизной ветки v-1-0. Релизную ветку v-1-0 начала тестировать команда релизного тестирования. Для ветки v-1-0 создается отдельная база. Команда тестироания обнаружила ряд багов и поставила задачи в корпоративной системе. На основании этих задач были созданы ветки b-1 и b-3 и после исправления багов разработчики сделали merge request’ы в ветку v-1-0. Далее повторяются шаги, описанные выше по обработке merge request и ветке v-1-0 появляются коммиты v-1-0-C1, v-1-0-C2 и v-1-0-C3. Отметим, что в релизной ветке не добавляется новый функционал, а только исправляются ошибки.

Параллельно в ветке master начали разработку нового функционала, который должен войти в версию v-1-1. Далее в ветке master на рис.1 не отражаются ветки задач для добавления функционала, чтобы не засорять схему, коммиты при этом все равно показаны. Обратим внимание, что после коммита C4, был обнаружен баг b-2 и по результатам его исправления разработчик сделал merge-request и в master и в текущую релизную ветку v-1-0, т.к. этот баг встречается в обеих ветках.

01.02.17 релизная ветка v-1-0, была протестирована командой релизного тестирования и главный технолог принял решение, что можно выпустить первый релиз проекта. Был сформирован тег r-1-0-1. И дистрибутив был передан заказчику. Главный технолог принял решения слить ветку v-1-0 с релизной веткой, т.к. баги, которые были в ней исправлены встречаются и в ветке master.

В процессе использования релиза к-1-0-1 заказчик выявил баг b-3 и он был исправлен в ветке v-1-0 и 08.02.17 было выпущено обновление-патч и сформирован тег r-1-0-2. В этот же момент главный технолог принял решение, что функционал для версии v-1-1 наработан и создал следующую релизную ветку v-1-1.  В ветке master команда разработчиков начала разрабатывать функционал для мажорного релиза v-2-0. Поддержка ветки v-1-0, продолжалась до момента выпуска нового релиза версии v-1-1. При этом баг b-4, исправленный в ветке v-1-0 главный технолог решил не помещать в ветку master, т.к. в ней он оказался не актуален, в связи с переделкой модуля, в котором встречался.

04.03.17 командой разработки был выпущен релиз версии r-1-1-1. Одновременно с этим руководство приняло решение сменить основную версию продукта с 1 на 2. Поскольку необходимость добавлять функционал в версию v-1 может остаться, то была создана отдельная ветка разработки (dev-v-1) для первой версии (для нее была создана отдельная база данных). Ветка dev-v-1 является аналогом ветки master, но для версии v-1. При этом поддержка версии v-1-0, была прекращена, т.к. ей на смену пришла версия v-1-1.

15.03.17 был накоплен функционал для v-2-0 и была создана ветка v-2-0.

18.03.17 был накоплен функционал для выпуска нового релиза версии v-1 и была создана релизная ветка v-1-2.

01.04.17 были выпущены релизы версии v-1 (r-1-2-1) и версии v-2 (r-2-0-1). В этот момент также была прекращена поддержка v-1-1, т.к. ей на смену пришла версия v-1-2.  

Что такое мажорная и минорная версии программного обеспечения

Например, в .NET стандартно используется класс Version, содержащий свойства Major, Minor, Build и Revision. Переведу кусок официальной документации:

Номер версии состоит из следующих компонент: мажорный* (старший) номер версии, минорный (младший), номер билда**, и номер ревизии, из которых используется две, три или четыре. Мажорный и минорный номера обязательны, ревизия или ревизия и номер билда могут быть опущены. Значения свойств — неотрицательные целые числа. Номер версии записывается в виде

major.minor[.build[.revision]]

(части в квадратных скобках необязательны).

Компоненты должны означать следеующее:

• Мажорный номер: Сборки (то есть, файлы библиотек) с одним и тем же именем, но разными мажорными версиями не взаимозаменяемы. Старшая версия может означать полное переписывание кода, без сохранения обратной совместимости.

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

• Номер билда: Одинаковый номер билда означает рекомпиляцию того же самого исходного текста. Различные номера билдов нужны, если повторная компиляция производится для другого процессора, платформы, опций оптимизации, или другим компилятором.

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

Последовательные выпуски версий сборки, отличающиеся лишь номером билда и/или ревизией, считаются хотфиксами (заменами, закрывающими проблемы) предыдущей версии.

*Термины «мажорный» и «минорный» — калька от «major» и «minor», но они, кажется, устоялись.

**Слово «сборка» в мире .NET имеет устоявшееся значение.

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

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

• решение технических проблем;

• устранение опасных уязвимостей;

• добавление новых функциональных возможностей;

• адаптацию под новые устройства или платформы;

• и мн. др.

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

Минорное обновление — это часть планового внесения изменений

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

Различают несколько видов внесения изменений в программу:

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

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

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

Часто можно заметить рядом с устанавливаемой программой какие-то цифры, например: MyProgram 2.0.1.7. Данные цифры как раз показывают, мажорные это обновления, минорные или патчи. Конкретно в этом случае будет так:

• «2.0» — версия программы или мажорное обновление второго поколения;

• «1» — версия минорного обновления;

• «7» — номер примененного патча.

Например, та же программа может быть версии «2.0.2.8», где сохраняется второе поколение программы, но вносятся изменения в виде минорного обновления «2» и патча «8». Если программа будет начинаться на «3.0», то это будет означать, что внесены кардинальные обновления.

Как минорное обновление влияет на пользователей

Минорное обновление никак не влияет на пользователя. Как правило, когда выходит минорный вид апгрейда или патч программы, то все изменения происходят «внутри» программы. Пользователь просто запускает программу, она обновляется какое-то время, и он ею пользуется.

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

Чтобы правильно оценить масштабы вероятных изменений в категориях апгрейда, приведем пример:

• патч может затронуть только одну строчку кода, чтобы исправить какой-то баг;

• минорное обновление затрагивает какую-то часть программного продукта, не меняя сам продукт, например, добавляется новая игровая карта в игре;

• при мажорном внесении изменений может произойти смена языка программирования всего проекта или игрового движка в игре. 

Заключение

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

Баг — это ошибка в работе системы (программы или сайта).

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

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

Обычно, выделяют следующие серьезности бага:

Critical (критическая серьезность) — баг блокирует либо всю функциональность (не проходят дымовые сценарии), либо некоторые важные части системы.

Major (средняя серьезность) — баг, иллюстрирующий то, что несмотря на то, что некоторая часть функциональности не работает, в системе есть обходные пути, которые позволять выполнить сценарий.

Minor (минорная серьезность) — мелкая ошибка, недочет, обычно это баги, связанные с удобством использования.

В зависимости от договоренностей в команде, уровни могут быть разными (например, еще могут быть Blocker, Trivial).