Минорные ошибки это

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

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

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

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

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

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

• и мн. др.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

Поэтому баги, внесенные в системы отслеживания (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. Допустим, у нас есть приложение для банкинга. Оно правильно рассчитывает ежедневный, ежемесячный и ежеквартальный отчет, но при расчете годового возникают проблемы. Этот баг имеет высокую степень серьезности. Но если сейчас формирование годовой отчетности не актуально, такой дефект имеет низкий приоритет: его можно исправить в следующем релизе.

Итоги

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

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

В отчете Updates Management in Mobile Applications. iTunes vs Google Play анализируются различия обновлений приложений в Google Play и App Store. Ученые пришли к выводу, что обновления лучше стимулируют загрузки на iOS.

В их выборку попали приложения из Топ-1000 в iTunes и Google Play в пяти европейских странах за период в шесть месяцев. Согласно их наблюдениям, обновление вероятнее всего выпускается тогда, когда разработчик наблюдает снижение количества загрузок.

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

Разработчики iOS и Android выпускают обновления, как говорят ученые, с «невероятно высокой частотой», хотя обновления гораздо чаще выходят на Android — в среднем приложения в Google Play обновляются раз в 28 дней, а в iTunes — раз в 59 дней.

Авторы предполагают, что незначительное влияние на загрузки, которое оказывают обновления на Android, обусловлено отсутствием проверки на качество в Google Play — все, качественные и не очень, обновления публикуются и «чрезмерность обновлений» уменьшает влияние обновлений на загрузки.

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

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

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

Среди других обнаруженных исследователями фактов:

• большинство топовых приложений бесплатны (только 17 из 1000 в Google Play оказались платными);
• на iOS процент платных приложений в Топ-1000 больше — 8.3%;
• приложения с покупками внутри более распространены на iOS в сравнении с Google Play, большинство (56.2%) приложений iOS имеют встроенные покупки, тогда как в Google Play этот показатель составляет меньше трети (29.7%);
• показатели загрузок в Google Play в 5 раз выше, чем на iOS;
• пользовательские оценки в Топ-1000 обоих магазинов составляют более 4 звезд, но количество пользователей, поставивших оценку, в Google Play в два раза больше;
• приложения iOS в Топ-1000 в среднем старее, чем в Топ-1000 Google Play, из чего можно сделать вывод о лучшей ротации популярных приложений на Android;
• в обоих магазинах около трети (35%) приложений — локальны (т.е. по крайней мере 40% загрузок приложение получает из родной страны).

Если вы нашли опечатку — выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.

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

Для начала рассмотрим каждый атрибут в отдельности.

Серьезность

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

Серьезность имеет несколько параметров в зависимости от типа дефекта. Ее степень зависит от того, как она влияет на бизнес-логику (реализацию правил программы).

• S1 – Блокирующая (Blocker). Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее функциями становится невозможна.
• S2 – Критическая (Critical). Критическая ошибка, неправильно работающая бизнес-логика, проблема, приводящая в нерабочее состояние некоторую часть системы, но есть возможность для работы с тестируемой функцией, используя другие входные точки.
• S3 – Значительная (Major). Значительная ошибка, часть бизнес-логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
• S4 – Незначительная (Minor). Незначительная ошибка, не нарушающая бизнес-логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
• S5 – Тривиальная (Trivial). Тривиальная ошибка, не касающаяся бизнес-логики приложения, плохо воспроизводимая проблема, малозаметная по средствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Из описания видно, что с помощью Серьезности мы указываем как найденная ошибка влияет на тестируемое приложение. Если из-за ошибки приложение полностью не работает, то Серьезность высокая. Если найденный дефект мало влияет на функционал и больше относится к визуальной части (например, опечатка в слове), то Серьезность низкая.

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

1.Приложение «падает» при попытке найти свободное такси.
Чтобы правильно поставить Серьезность, необходимо определить влияние ошибки на дальнейшую работу функционала. Из названия видно, что после появления ошибки приложение перестает работать. Значит, влияние высокое.

Сразу же отбрасываем Тривиальную и Незначительную Серьезность, так как из их описания понятно, что ошибка не должна сильно влиять на приложение.

У нас остается только три варианта: Значительная, Критическая и Блокирующая серьезности.

Подходит ли нам Значительная Серьезность? Очевидно, что нет. Во-первых, ошибка достаточно критична. Во-вторых, другим способом найти такси мы не можем, т.е. нет возможности работы с тестируемой функцией, используя другие входные точки. Более того, функционал работает не некорректно, а не работает вообще.

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

2. Невозможно указать адрес назначения с помощью “Указать на карте”.
Снова начинаем рассуждать. Тривиальная и Незначительная не подходят, потому что ошибка в какой-то мере нарушают бизнес логику работы приложения. Блокирующую можно не брать, т.к. функционал в целом работает и его можно использовать через другую точку входа, а именно ввести адрес вручную. Остается только два варианта: Критическая и Значительная. Мы уже сказали, что проблема не приводит к полной неработоспособности части функционала. Тем не менее это значительная ошибка, т.к. функционал частично не работает, следовательно остается только вариант Значительная. Его мы и укажем.

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

Приоритет

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

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

• P1 – Высокий (High) – требуется исправить в первую очередь.
• P2 – Средний (Medium) – требуется исправить во вторую очередь, когда нет дефектов с высоким приоритетом.
• P3 – Низкий (Low) – исправляется в последнюю очередь, когда все дефекты с более высоким приоритетом уже исправлены.

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

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

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

Приоритет определяется исходя из масштабности проблем для пользователей и продукта. Для понимая можно использовать матрицу:

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

________________________________
Если остались вопросы по определению параметров Серьезность и Приоритет, то задавайте их в комментариях к статье.
________________________________

Предыдущие статьи по оформлению баг-репорта:
Назначение отчета https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-naznachenie/
Шаблон отчета об ошибке https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-shablon-otcheta-ob-oshibke/