Как оценить критичность ошибки

Классификация ошибок с точки зрения тестировщика

В Главе 5 книги [5] приводится форма отчета
о тестировании, в котором предлагается
типизация выявленных проблем, которая
может служить классификацией ошибок с
точки зрения тестировщика.

Предлагается различать.

  1. Ошибки
    кодирования.

  2. Ошибки
    проектирования.

  3. Предложения
    тестировщика по улучшению программы.

  4. Расхождение
    с документацией.

  5. Взаимодействие
    с аппаратурой.

  6. Поведение
    программы, вызывающее вопросы
    тестировщика.

Как бы не привлекала такая классификация
своей простотой, приведенный выше
перечень возможных ошибок, говорит о
том, что воспользоваться ею можно только
в очень простых и частных случаях. В
общем случае у тестировщика нет
убедительных оснований отнести ошибку
к тому или иному разделу данной
классификации, так как обычно проблема
носит комплексный характер. Вероятность
ошибки такого отнесения также высока.
Следствием подобных ошибок в классификации
будет увеличение время отладки программы,
так как программные ошибки будут
направляться на исправление не тем
сотрудникам или подразделениям, которые
на самом деле должны ими заниматься.
Для предотвращения подобных ситуаций
могут применяться системы автоматизированной
классификации ошибок, позволяющие
быстро оценивать серьезность ошибок,
информировать об их возникновении
нужных специалистов и т.д. Вопросы
построения такого рода систем, в основу
работы которых положен анализ сообщений
об ошибках, рассмотрены в работе [8]. Их
функционирование должно опираться на
использование методов и моделей
искусственного интеллекта (в частности
методов классификации текстов).

Классификация ошибок по степени их критичности

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

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

Классификация может быть следующей.

Разрушение системы (Causes crash) — Под ним
объединяют все те ошибки в программе,
которые могут вызвать крах или зависание
всей системы, нарушить стабильность ее
работы.

Косметические (Cosmetic) — под этим понятием
объединяют ошибки дизайна (например,
не тот цвет линии или шрифт), пользовательского
интерфейса и т.п., которые не мешают
работать программе, но портят ее «товарный
вид».

Критические (Critical) – ошибки, которые
приводят к «зависанию» или «падению»
самой программы, не затрагивая операционной
системы в целом.

Error Handling — ошибки при обработке ошибок.

Functional — ошибки функциональности, не
относящиеся к критическим.

Setup — ошибки инсталляции.

Minor — малозначимые.

Suggestion – предложения по улучшению
программы (так называемые «фичи»
(feature).

Во многих отраслевых и корпоративных
стандартах для ответственных систем
принят подобный принцип классификации
ошибок, который является главным. Так
стандарт DO-178B, предназначенный для
сертификации ПО авиационного электронного
оборудования, выделяет следующие
категории аварийных ситуаций (сбоев,
ошибок) по степени их негативного
воздействия на самолет, экипаж и
пассажиров. Оставлено без перевода, так
как нам гораздо важнее принцип
классификации, нежели перевод терминов
конкретной предметной области.

Catastrophic — Failure may cause a crash.

Hazardous — Failure has a large negative impact on safety or
performance, or reduces the ability of the crew to operate the plane
due to physical distress or a higher workload, or causes serious or
fatal injuries among the passengers.

Major — Failure is significant, but has a lesser impact than a
Hazardous failure (for example, leads to passenger discomfort rather
than injuries).

Minor — Failure is noticeable, but has a lesser impact than a Major
failure (for example, causing passenger inconvenience or a routine
flight plan change)

No Effect — Failure has no impact on safety, aircraft operation, or
crew workload.

В зависимости от того, какого рода ошибки
могут встретиться в конкретной программе,
определяется ее уровень. От этого уровня
зависят требования, которые предъявляются
к ее тестированию и верификации.

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • Авторы
  • Файлы

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

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

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

В общем случае отказ программного обеспечения можно определить как:

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

Из данного определения программной ошибки следует, что ошибки могут по разному влиять на надежность программного обеспечения и можно определить тяжесть ошибки, как количественную или качественную оценку последствий этой ошибки. При этом категорией тяжести последствий ошибки будет являться классификационная группа ошибок по тяжести их последствий. Ниже представлены возможные категории тяжести ошибок в программном обеспечении общего применения в соответствии с ГОСТ 51901.12 — 2007 «Менеджмент риска. Метод анализа видов и последствий отказов».

Таблица 1. Категории тяжести ошибки в программном обеспечении, нарушение работоспособности которого не приводят к катастрофическим последствиям

Номер
категории
ошибки

Наименование
категории тяжести ошибки

Описание последствий проявления ошибки

III

Критическая

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

II

Существенная

проявление ошибки влечет за собой снижение эффективности функционирования программного обеспечения и может вызвать прекращение функционирования программного обеспечения (его отказ)

I

Несущественная

проявление ошибки может повлечь за собой снижение эффективности функционирования программного обеспечения и практически не приводит к возникновению отказа в нем (вероятность возникновения отказа очень низкая)

В качестве показателя степени тяжести ошибки, позволяющего дать количественную оценку тяжести проявления последствий ошибки можно использовать условную вероятность отказа программного обеспечения при проявлении ошибки. Оценку степени тяжести ошибки как условной вероятности возникновения отказа, можно производить согласно ГОСТ 28195 — 89 «Оценка качества программных средств. Общие положения», используя метрики и оценочные элементы, характеризующие устойчивость программного обеспечения. При этом оценку необходимо производить для каждой ошибки в отдельности, а не для всего программного обеспечения.


Библиографическая ссылка

Дроботун Е.Б. КРИТИЧНОСТЬ ОШИБОК В ПРОГРАММНОМ ОБЕСПЕЧЕНИИ И АНАЛИЗ ИХ ПОСЛЕДСТВИЙ // Фундаментальные исследования. – 2009. – № 4.
– С. 73-74;

URL: https://fundamental-research.ru/ru/article/view?id=4467 (дата обращения: 29.01.2023).


Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»

(Высокий импакт-фактор РИНЦ, тематика журналов охватывает все научные направления)

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

EPAK.059

Оценка эффективности взаимодействия

В процессе создания методики были проанализированы эвристики и руководства, предлагаемые всемирно известными экспертами в области юзабилити (Usability) и взаимодействия между человеком и компьютером (Human-Computer Interaction), материалы из области когнитивной психологии, связанные с особенностями человеческого восприятия и поведения. При этом мы обнаружили, что до настоящего момента не существовало как таковой исчерпывающей классификации правил проектирования пользовательских интерфейсов (либо ошибок проектирования). Каждый специалист предлагал свои перечни требований, носящие субъективный авторский характер и не поддающиеся систематизации и классификации.

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

Система классификации ошибок

Ошибки классифицируются по четырем основным категориям:

  • Элемент пользовательского интерфейса веб-сайта: (текст, графика, навигация, форма ввода или элемент управления);
  • Правило проектирования: (информационная ясность, визуальная ясность, корректность, единообразие, минимализм и обоснованность);
  • Аспект взаимодействия пользователей с веб-сайтом, на который влияет ошибка: (поддержка задач пользователя, ощущение контроля и свободы действий, обратная связь, предотвращение и обработка ошибок);
  • Уровень критичности выявленной ошибки (высокий, средний, низкий).

Элементы пользовательского интерфейса

Элементы интерфейса Описание
Тексты Любые словесные заголовки, пояснения, описания, контекстная справка.
Графика Картинки, флэш-ролики, видео-ролики, фон и другие элементы дизайна.
Навигация Меню навигации, навигационная панель, ссылки, “хлебные крошки”*, карта сайта и другие элементы навигации.
Формы Поля для текстового ввода, списки выбора (раскрывающиеся списки, радиогруппы, флажки), кнопки и другие элементы управления.

Правила проектирования

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

Аспекты взаимодействия пользователей с веб-сайтом

Аспекты взаимодействия Описание
Поддержка задач пользователя Фокусируйтесь на пользователях и их задачах.
Рассматривайте решение задач с точки зрения пользователей.
Обеспечьте решение наиболее важных задач в первую очередь.
Контроль и свобода Создайте и поддерживайте у пользователя ощущение контроля за ситуацией и свободы выбора способа решения задач
Обратная связь Обеспечьте своевременную информативную обратную связь.
Обработка ошибок Максимально содействуйте предотвращению и исправлению ошибок пользователя

Уровни критичности ошибок

Уровни Описание
Высокий С обнаруженной проблемой столкнутся все пользователи веб-сайта;
Эта проблема мешает выполнению основных задач пользователей;
В результате этой ошибки высок риск потерять клиента – пользователь уйдет с веб-сайта.
Средний С этой проблемой столкнутся многие пользователи;
Есть риск потерять часть клиентов.
Низкий Выявленная проблема возникает редко и/или не у всех пользователей,
Эта проблема не блокирует выполнение задач пользователей, но ухудшает потребительские качества веб-сайта.

Об экспертной оценке

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

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

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

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

Кроме того в подробном отчёте эсперт приводит описание каждой ошибки, восприятие ее пользователем, классификацию ошибки по 4 категориям.

По ходу выполнения сценария эксперт также обращает внимание на следующие вопросы: 

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

Примечания

*«Хлебные крошки» (англ. Breadcrumbs) — элемент навигации по сайту, представляющий собой путь по сайту от его «корня» до текущей страницы, на которой находится пользователь.

Обычно представляет собой полосу в верхней части страницы примерно такого вида: “Главная страница → Раздел → Подраздел → Текущая страница” Все элементы, кроме последнего, обычно являются внутренними гиперссылками.
 

Ошибки и контроль в бухгалтерском учете банка

«Налогообложение, учет и отчетность в коммерческом банке», 2014, N 1

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

Необходимость осуществления контроля за ведением бухгалтерского учета установлена Федеральным законом от 06.12.2011 N 402-ФЗ «О бухгалтерском учете», Положением Банка России от 16.07.2012 N 385-П «О правилах ведения бухгалтерского учета в кредитных организациях, расположенных на территории Российской Федерации» (далее — Положение N 385-П), Положением Банка России от 16.12.2003 N 242-П «Об организации внутреннего контроля в кредитных организациях и банковских группах», стандартами аудиторской деятельности (Федеральным законом от 30.12.2008 N 307-ФЗ «Об аудиторской деятельности», Постановлением Правительства РФ от 23.09.2002 N 696 «Об утверждении федеральных правил (стандартов) аудиторской деятельности»), другими нормативными актами.

Усиление мер по контролю за ведением бухгалтерского учета является составной частью мировой тенденции по укреплению банковской системы. В частности, Базельский комитет по банковскому надзору уделяет большое внимание такому контролю как инструменту повышения прозрачности банков и снижения их операционного риска <1>.

<1> Письмо Банка России от 13.05.2002 N 59-Т «О рекомендациях Базельского комитета по банковскому надзору», Письмо Банка России от 16.05.2012 N 69-Т «О рекомендациях Базельского комитета по банковскому надзору «Принципы надлежащего управления операционным риском».

Характер ошибок и их классификация

Под контролем бухгалтерского учета мы понимаем комплекс мер, направленных на:

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

Факторы, влияющие на качество бухгалтерского учета, указаны в разд. 3 ч. III Положения N 385-П и ПБУ 22/2010 «Исправление ошибок в бухгалтерском учете» <1>, в соответствии с которым «неправильное отражение (неотражение) фактов хозяйственной деятельности в бухгалтерском учете и (или) бухгалтерской отчетности организации (далее — ошибка) может быть обусловлено, в частности:

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

<1> Утверждено Приказом Минфина России от 28.06.2010 N 63н, предписано к использованию кредитными организациями Указанием Банка России от 08.10.2008 N 2089-У «О порядке составления кредитными организациями годового отчета».

Сами ошибки учета можно классифицировать следующим образом (рис. 1).

Классификация ошибок в бухгалтерском учете

-----------------------------------------------------------------------------------¬
¦ Ошибки в бухгалтерском учете ¦
L--------T------------------T----------------T---------------T-------------T--------
¦ ¦ ¦ ¦ ¦
¦/ ¦/ ¦/ ¦/ ¦/
-------------------¬---------------¬-----------------¬-------------¬---------------¬
¦ Характе𠦦 Регулярность ¦¦ Существенность ¦¦ Критичность¦¦ Кем выявлены ¦
+-------------------+---------------+-----------------+-------------+---------------
¦ -----------------¬¦ -------------¬¦ ---------------¬¦ -----------¬¦ -------------¬
+>¦ Преднамеренные ¦¦ ¦ Частые, ¦+>¦ Существенные ¦+>¦ Критичны妦 ¦ Посредством¦
¦ L-----------------+>¦ регулярные ¦¦ L---------------¦ L-----------+>¦самопроверки¦
¦ -----------------¬¦ L-------------¦ ---------------¬¦ -----------¬¦ L-------------
+>¦Непреднамеренны妦 -------------¬L>¦Несущественные¦L>¦Некртичны妦 -------------¬
¦ L-----------------¦ ¦ Редкие, ¦ L--------------- L-----------¦ ¦ Внутренними¦
¦ -----------------¬L>¦ случайные ¦ +>¦контролерами¦
¦ ¦ Ошибки ¦ L------------- ¦ L-------------
+>¦ по содержанию ¦ ¦ -------------¬
¦ L----------------- ¦ ¦ Внешними ¦
¦ -----------------¬ L>¦контролерами¦
+>¦ Технические ¦ L-------------
¦ L-----------------
¦ -----------------¬
L>¦ Специфические ¦
L-----------------

Рисунок 1

  1. Преднамеренные ошибки — это сознательное искажение или утаивание работником (работниками) банка фактов хозяйственной деятельности и (или) порядка их бухгалтерского учета. Преднамеренные ошибки связаны либо с фактами мошенничества (хищения, злоупотребления) работников банка, либо с попыткой скрыть ранее совершенные ошибки. Основными методами минимизации преднамеренных ошибок являются:
  • назначение в банке работников, ответственных за оформление первичных документов, сохранность имущества, отражение в учете, и четкое разграничение их прав и обязанностей;
  • установление внутренних лимитов на совершение тех или иных действий для работников из категорий, уполномоченных заключать сделки, осуществлять платежи, хранить имущество и даже вести учет;
  • эффективная система последующего контроля;
  • установление в банке процедуры по дисциплинарному, административному и уголовному преследованию лиц, совершивших умышленные нарушения.
  1. Непреднамеренные ошибки — это ошибки, совершенные работниками без умысла вследствие большой загруженности, недостаточной квалификации, отсутствия четкого разделения должностных обязанностей по учету. Основными методами минимизации непреднамеренных ошибок являются:
  • разработка подробной и понятной методологии;
  • повышение профессионального уровня работников;
  • определение должностных обязанностей бухгалтерских работников (главный бухгалтер всегда должен помнить, что отвечает за ошибки лично, если не распределил обязанности по учету);
  • оптимизация рабочей нагрузки;
  • автоматизация банковского процесса.
  1. Ошибки по содержанию — ошибки, связанные с неправильной классификацией и оценкой фактов хозяйственной жизни банка, а также с неправильным порядком учета. Основные методы минимизации ошибок по содержанию:
  • разработка подробной и понятной методологии;
  • повышение профессионального уровня работников;
  • внедрение процедур текущего контроля (проверка работником-контролером правильности учета непосредственно перед отражением на счетах);
  • автоматизация банковского процесса, обеспечивающая жесткое закрепление схемы учета с параметрами банковского продукта.
  1. Технические ошибки — ошибки, связанные с неточностью вычислений (например, неверно рассчитана сумма процентов), ошибочным внесением данных в первичные учетные документы и АБС или сбоями в программном обеспечении. Основными методами минимизации технических ошибок являются:
  • минимизация ручных вычислительных действий;
  • внедрение процедур текущего контроля и повторного ввода;
  • тщательная проверка автоматизации банковского процесса на этапе опытной эксплуатации и регулярная проверка надежности программного обеспечения в период промышленного использования путем сверки с результатами ручной обработки фактов хозяйственной деятельности.
  1. Специфические ошибки — прочие ошибки, связанные со спецификой совершаемых операций. Например, ошибки, на факторы возникновения которых банк не оказывает прямого влияния: ошибочный отчет дилера, поступление первичных учетных документов от контрагентов с опозданием, неполучение выписки от банка-корреспондента и т.д.

Регулярность, существенность и критичность ошибок

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

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

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

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

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

Организация контроля

В соответствии с вышеприведенной классификацией ошибок логичной видится структура контроля, представленная на рис. 2.

Структура контроля в кредитной организации

        ----------------------------------------------------¬
--------+-------¬ ---------------¬ -----------+----------¬
¦Предварительный+--------+Обратная связь+--------+ Последующий ¦
+---------------- L--------------- L----------T-----------
¦ --------------------------+-¬
¦ ----------------¬ -------+-------¬ ------------+---------¬
+-+ Методология ¦ ¦ Внутренний ¦ ¦ Внешний ¦
¦ L---------------- +--------------- +----------------------
¦ ----------------¬ ¦ ---------------¬ ¦ ----------------------¬
¦ ¦ Кадры и ¦ +-+Инвентаризация¦ +-+ Аудит ¦
+-+ обязанности ¦ ¦ L--------------- ¦ L----------------------
¦ L---------------- ¦ ---------------¬ ¦ ----------------------¬
¦ ----------------¬ ¦ ¦ Последующий ¦ ¦ ¦ Контроль материнской¦
¦ ¦Предварительная¦ +-+ контроль ¦ +-+компании (ревизионная¦
+-+ проверка ¦ ¦ L--------------- ¦ ¦ комиссия) ¦
¦ L---------------- ¦ ---------------¬ ¦ L----------------------
¦ ----------------¬ ¦ ¦ Проверки СВК ¦ ¦ ----------------------¬
L-+ Автоматизация ¦ L-+ и внутреннего¦ L-+ Надзор ¦
L---------------- ¦ аудита ¦ L----------------------
L---------------

Рисунок 2

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

Методология учета

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

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

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

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

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

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

Кадры и обязанности

Перед началом работы по учету операции необходимо убедиться в том, что:

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

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

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

Вопрос о нагрузке всегда является дискуссионным, так как, с одной стороны, это связано с личными деловыми качествами конкретного бухгалтера, а с другой — сделать обоснованный анализ нагрузки (с фотографией рабочего дня и нормированием) достаточно непросто и затратно. Поэтому чаще всего главный бухгалтер (руководитель бухгалтерского подразделения или опытный квалифицированный бухгалтер) основывается на собственном опыте и собственной квалификации по учету операции. Обычно он думает так: «Если я обрабатывал 120 таких сделок в день, это и есть норма». Такой подход вполне годится в качестве базового, однако у него есть недостатки: а) опыт руководителя может отличаться от современного процесса;) руководитель может не обладать необходимым опытом; в) ориентируясь на себя, руководитель устанавливает завышенную планку.

Еще чаще вопрос решается таким образом: «Будем увеличивать нагрузку на бухгалтера, пока он справляется; если появятся ошибки или «завал», заменим «лодыря» более активным или дадим ему в помощь другого работника». В таком случае у главбуха возникают следующие сложности: а) сложность в планировании и обосновании численности бухгалтерии; б) отсутствие объективности в понимании загруженности работника; в) и самое главное — в целях контроля информация об ошибках появится с опозданием (только на этапах последующего контроля) и только после этого станет понятно, что надо перепроверять всю работу бухгалтера. В связи со сказанным целесообразно применять обоснованный подход к определению нагрузки.

Часто появление ошибок обусловлено нечетким распределением ответственности бухгалтеров за каждый этап обработки и учета операции. «Отфутболивание» обязанностей работниками друг другу недопустимо и должно решительно пресекаться руководителем бухгалтерского подразделения. Закрепление обязанностей является существенной частью методологии.

Предварительная проверка

Предварительная проверка представляет собой мероприятия по контролю бухгалтерских операций, осуществляемых работниками банка до момента закрытия операционного дня. Положением N 385-П (Приложение 5) Банк России предписывает кредитным организациям осуществлять такой контроль по отдельным операциям. По мнению автора, в целях минимизации ошибок целесообразно расширить перечень Банка России, добавив по крайней мере операции по счетам клиентов, операции кредитования (балансовые счета 441 — 455) и прочие требования и обязательства (балансовые счета 47422 и 47423).

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

Автоматизация учета

Не будем повторять очевидные вещи о важности автоматизации в деле повышения качества учета. Однако напомним, что:

  1. перед вводом в промышленную эксплуатацию программное обеспечение должно быть тщательно протестировано, в том числе на нестандартных операциях и на больших объемах;
  2. автоматизация должна обеспечивать доступ только уполномоченным работникам;
  3. автоматизация должна обеспечивать запрет изменения данных задним числом без санкции ответственного работника;
  4. автоматизация должна содержать различные средства самопроверки (например, сверку сведений, содержащихся в регистрах бухгалтерского учета, с проводками по лицевым счетам и т.п.).

Последующий и внутренний контроль

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

Требования по осуществлению последующего контроля и формы его проведения установлены Положением N 385-П. Этот тип контроля осуществляется бухгалтерскими работниками во главе с главным бухгалтером.

Ранее опытные бухгалтеры осуществляли ежедневную полистную проверку документов дня. Сейчас же, учитывая огромный объем операций и высокий уровень автоматизации, такой контроль вряд ли возможен. Регулярную сверку условий операций с отражением в учете целесообразно осуществлять программным способом, а последующий контроль сконцентрировать на цепочке «анализ содержания сделки — оформление сделки ПУД — классификация сделки для целей учета — правильность внесения информации о сделках в АБС — сравнение ручного учета сделки с данными в АБС (если ведется неавтоматизированный учет)». Проверка нескольких операций даст репрезентативную выборку по целому направлению учета.

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

Инвентаризация

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

Проверки службы внутреннего контроля (внутреннего аудитора)

Ценность проверок СВК заключается в возможности оценить ситуацию как бы со стороны, проанализировав ее.

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

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

Внешний контроль. Обратная связь

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

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

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

В.Б.Потехин

Главный бухгалтер

ОАО «МСП Банк»,

руководитель

комитета по налогообложению,

бухгалтерскому учету и отчетности

Ассоциации российских банков

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

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

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

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

а) будет правильным

б) совпадёт у разных людей.

По этим причинам создается регламент определения критичности и приоритетности дефектов. Пример такого регламента приведен ниже.

Регламент определения критичности и приоритетности дефектов

1 Цель документа

«Регламент определения критичности и приоритетности дефектов» вводится для упорядочивания работы над задачами и ошибками, унификации и упрощения таких задач, как определение очерёдности, в которой должны выполняться задания, простановка критичности тестировщиками, предотвращения споров о важности и приоритетности дефектов и задач.

2 Правила определения критичности

Severity. Критичность ошибки. Определяется тестировщиком при регистрации ошибки. Указывает на серьёзность её последствий для работы системы, удовлетворённость пользователей, финансовые показатели.

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

Для определения критичности используется следующий перечень функционала системы:

Базовый функционал

Функция

Пояснение

Реклама

Показ внешних баннеров и тизеров

Добавление контента в общем случае

Backend сайта. Ошибкой затрагивается большинство типов контента.

Чтение контента в общем случае

Frontend сайта. Все браузеры и настройки. Ошибкой затрагивается не менее 25% страниц или любая из 10 самых посещаемых

Продажи

Совершение покупки в интернет-магазине

Дополнительный функционал

Функция

Пояснение

Добавление контента в частном случае

Backend сайта. Ошибкой затрагиваются отдельные типы контента

Чтение контента в частном случае

Frontend сайта. Для конкретных браузеров и настроек. Ошибкой затрагивается не менее 25% страниц или любая из 10 самых посещаемых

Прочие функции backend сайта

Любые другие функции

Прочие функции frontend сайта

Любые другие функции

Для дефектов поле «severity» является обязательным, для задач – опциональным. По умолчанию всем новым записям присваивается значение «Minor».

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

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

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

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

3 Правила определения приоритета

Priority. Приоритет ошибки или задачи определяется менеджером проекта при передаче в разработку. Указывает на то, в каком порядке должны делаться задачи, какие должны быть сделаны в первую очередь, а какие позже.

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

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

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

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

High. Высокий приоритет. Присваивается ошибкам и задачам, которые должны быть исправлены в первую очередь. В каждом проекте в любой момент времени может быть не более 10 открытых ошибок или задач высокого приоритета. В случае, если появляется более приоритетная задача, менеджер проекта может присвоить ей приоритет “High” только после того, как понизит приоритет другой задач.

Normal. Обычный приоритет. Присваивается ошибкам и задачам, которые следует исправить во вторую очередь, в рабочем порядке. Этот приоритет выбран по умолчанию. Большинство ошибок и задач должны получать именно такой приоритет.

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

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

Определение

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

Баги обнаруживаются чаще всего в момент отладки или бета-тестирования. Реже – после итогового релиза готовой программы. Вот несколько вариантов багов:

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

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

История происхождения термина

Баг – слово, которое используется разработчиками в качестве сленга. Оно произошло от слова «bug» – «жук». Точно неизвестно, откуда в программировании и IT возник соответствующий термин. Существуют две теории:

  1. 9 сентября 1945 года ученые из Гарварда тестировали очередную вычислительную машину. Она называлась Mark II Aiken Relay Calculator. Устройство начало работать с ошибками. Когда его разобрали, то ученые заметили мотылька, застрявшего между реле. Тогда некая Грейс Хоппер назвала произошедший сбой упомянутым термином.
  2. Слово «баг» появилось задолго до появления Mark II. Термин использовался Томасом Эдисоном и указывал на мелкие недочеты и трудности. Во время Второй Мировой войны «bugs» называли проблемы с радарной электроникой.

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

Как классифицируют

Ошибки работы программ разделяются по разным факторам. Классификация у рядовых пользователей и разработчиков различается. То, что для первых – «просто программа вылетела» или «глючит», для вторых – огромная головная боль. Но существует и общепринятая классификация ошибок. Пример – по критичности:

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

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

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

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

Виды

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

Разработчики выделяют следующие типы ошибок по уровню сложности:

  1. «Борбаг» – «стабильная» неполадка. Она легко обнаруживается на этапе разработки и компилирования. Иногда – во время тестирования наработкой исходной программы.
  2. «Гейзенбаг» – баги с поддержкой изменения свойств, включая зависимость от среды, в которой было запущено приложение. Сюда относят периодические неполадки в программах. Они могут исчезать на некоторое время, но через какой-то промежуток вновь дают о себе знать.
  3. «Мандельбаг» – непредвиденные ошибки. Обладают энтропийным поведением. Предсказать, к чему они приведут, практически невозможно.
  4. «Шрединбаг» – критические неполадки. Приводят к тому, что злоумышленники могут взломать программу. Данный тип ошибок обнаружить достаточно трудно, потому что они никак себя не проявляют.

Также есть классификация «по критичности». Тут всего два варианта – warning («варнинги») и критические весомые сбои. Первые сопровождаются характерными сообщениями и отчетами для разработчиков. Они не представляют серьезной опасности для работоспособности приложения. При компилировании такие сбои легко исправляются. В отдельных случаях компилятор справляется с этой задачей самостоятельно. А вот критические весомые сбои говорят сами за себя. Они приводят к серьезным нарушениям ПО. Исправляются обычно путем проработки логики и значительных изменений программного кода.

Типы багов

Ошибки в программах бывают:

  • логическими;
  • синтаксическими;
  • взаимодействия;
  • компиляционные;
  • ресурсные;
  • арифметические;
  • среды выполнения.

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

Ошибки синтаксиса

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

Синтаксические ошибки – ошибки синтаксиса, правил языка. Вот пример в Паскале:

Код написан неверно. Согласно действующим синтаксическим нормам, в Pascal в первой строчке нужно в конце поставить точку с запятой.

Логические

Тут стоит выделить обычные и арифметические типы. Вторые возникают, когда программе при работе необходимо вычислить много переменных, но на каком-то этапе расчетов возникают неполадки или нечто непредвиденное. Пример – получение в результатах «бесконечности».

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

Выше – пример логической ошибки в программе. Тут:

  1. Происходит сравнение значения i с 15.
  2. На экран выводится сообщение, если I = 15.
  3. В заданном цикле i не будет равно 15. Связано это с диапазоном значений – от 1 до 10.

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

Время выполнения

Run-time сбои – это ошибка времени выполнения программы. Встречается даже когда исходный код лишен логических и синтаксических ошибок. Связаны такие неполадки с ходом выполнения программного продукта. Пример – в процессе функционирования ПО был удален файл, считываемый программой. Если игнорировать подобные неполадки, можно столкнуться с аварийным завершением работы контента.

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

Компиляционный тип

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

Наличие подобных неполадок делает бета-тестирование невозможным. Компиляционные ошибки устраняются при разработке-отладке.

Ресурсные

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

Исправить ситуацию помогают основательные работы над исходным кодом. А именно – полное переписывание программы или «проблемного» фрагмента.

Взаимодействие

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

Исключения и как избежать багов

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

Исключения бывают:

  1. Программными. Они генерируются приложением или ОС.
  2. Аппаратными. Создаются процессором. Пример – обращение к невыделенной памяти.

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

P. S. Большой выбор курсов по тестированию есть и в Otus. Присутствуют варианты как для продвинутых, так и для начинающих пользователей.

  • Авторы
  • Файлы

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

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

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

В общем случае отказ программного обеспечения можно определить как:

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

Из данного определения программной ошибки следует, что ошибки могут по разному влиять на надежность программного обеспечения и можно определить тяжесть ошибки, как количественную или качественную оценку последствий этой ошибки. При этом категорией тяжести последствий ошибки будет являться классификационная группа ошибок по тяжести их последствий. Ниже представлены возможные категории тяжести ошибок в программном обеспечении общего применения в соответствии с ГОСТ 51901.12 — 2007 «Менеджмент риска. Метод анализа видов и последствий отказов».

Таблица 1. Категории тяжести ошибки в программном обеспечении, нарушение работоспособности которого не приводят к катастрофическим последствиям

Номер
категории
ошибки

Наименование
категории тяжести ошибки

Описание последствий проявления ошибки

III

Критическая

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

II

Существенная

проявление ошибки влечет за собой снижение эффективности функционирования программного обеспечения и может вызвать прекращение функционирования программного обеспечения (его отказ)

I

Несущественная

проявление ошибки может повлечь за собой снижение эффективности функционирования программного обеспечения и практически не приводит к возникновению отказа в нем (вероятность возникновения отказа очень низкая)

В качестве показателя степени тяжести ошибки, позволяющего дать количественную оценку тяжести проявления последствий ошибки можно использовать условную вероятность отказа программного обеспечения при проявлении ошибки. Оценку степени тяжести ошибки как условной вероятности возникновения отказа, можно производить согласно ГОСТ 28195 — 89 «Оценка качества программных средств. Общие положения», используя метрики и оценочные элементы, характеризующие устойчивость программного обеспечения. При этом оценку необходимо производить для каждой ошибки в отдельности, а не для всего программного обеспечения.


Библиографическая ссылка

Дроботун Е.Б. КРИТИЧНОСТЬ ОШИБОК В ПРОГРАММНОМ ОБЕСПЕЧЕНИИ И АНАЛИЗ ИХ ПОСЛЕДСТВИЙ // Фундаментальные исследования. – 2009. – № 4.
– С. 73-74;

URL: https://fundamental-research.ru/ru/article/view?id=4467 (дата обращения: 23.06.2023).


Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»

(Высокий импакт-фактор РИНЦ, тематика журналов охватывает все научные направления)

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

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

Как это помогает при разработке

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

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

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

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

Критичность и приоритет не константы

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

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

Наивысшая срочность — ASAP (as soon as possible) — указывает на необходимость устранить дефект настолько быстро, насколько это возможно. В зависимости от контекста, этот термин может означать исправление дефекта в ближайшем билде или даже в течение нескольких минут после его обнаружения. Такая срочность наиболее критична и требует немедленного внимания.

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

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

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

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

Критичность и приоритет дефектов

Критичность и приоритет дефектов

Критичность и приоритет дефектов комбинации

Классификация ошибок в тестировании программного обеспечения на Severity и Priority помогает разработчикам и тестировщикам определять приоритеты исправления ошибок. Классификация включает четыре комбинации: High Priority and High Severity, High Priority and Low Severity, Low Priority and High Severity, Low Priority and Low Severity.

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

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

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

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

Классификация Severity и Priority помогает разработчикам и тестировщикам определить приоритеты исправления ошибок и улучшить качество программного обеспечения.

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

EPAK.059

Оценка эффективности взаимодействия

В процессе создания методики были проанализированы эвристики и руководства, предлагаемые всемирно известными экспертами в области юзабилити (Usability) и взаимодействия между человеком и компьютером (Human-Computer Interaction), материалы из области когнитивной психологии, связанные с особенностями человеческого восприятия и поведения. При этом мы обнаружили, что до настоящего момента не существовало как таковой исчерпывающей классификации правил проектирования пользовательских интерфейсов (либо ошибок проектирования). Каждый специалист предлагал свои перечни требований, носящие субъективный авторский характер и не поддающиеся систематизации и классификации.

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

Система классификации ошибок

Ошибки классифицируются по четырем основным категориям:

  • Элемент пользовательского интерфейса веб-сайта: (текст, графика, навигация, форма ввода или элемент управления);
  • Правило проектирования: (информационная ясность, визуальная ясность, корректность, единообразие, минимализм и обоснованность);
  • Аспект взаимодействия пользователей с веб-сайтом, на который влияет ошибка: (поддержка задач пользователя, ощущение контроля и свободы действий, обратная связь, предотвращение и обработка ошибок);
  • Уровень критичности выявленной ошибки (высокий, средний, низкий).

Элементы пользовательского интерфейса

Элементы интерфейса Описание
Тексты Любые словесные заголовки, пояснения, описания, контекстная справка.
Графика Картинки, флэш-ролики, видео-ролики, фон и другие элементы дизайна.
Навигация Меню навигации, навигационная панель, ссылки, “хлебные крошки”*, карта сайта и другие элементы навигации.
Формы Поля для текстового ввода, списки выбора (раскрывающиеся списки, радиогруппы, флажки), кнопки и другие элементы управления.

Правила проектирования

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

Аспекты взаимодействия пользователей с веб-сайтом

Аспекты взаимодействия Описание
Поддержка задач пользователя Фокусируйтесь на пользователях и их задачах.
Рассматривайте решение задач с точки зрения пользователей.
Обеспечьте решение наиболее важных задач в первую очередь.
Контроль и свобода Создайте и поддерживайте у пользователя ощущение контроля за ситуацией и свободы выбора способа решения задач
Обратная связь Обеспечьте своевременную информативную обратную связь.
Обработка ошибок Максимально содействуйте предотвращению и исправлению ошибок пользователя

Уровни критичности ошибок

Уровни Описание
Высокий С обнаруженной проблемой столкнутся все пользователи веб-сайта;
Эта проблема мешает выполнению основных задач пользователей;
В результате этой ошибки высок риск потерять клиента – пользователь уйдет с веб-сайта.
Средний С этой проблемой столкнутся многие пользователи;
Есть риск потерять часть клиентов.
Низкий Выявленная проблема возникает редко и/или не у всех пользователей,
Эта проблема не блокирует выполнение задач пользователей, но ухудшает потребительские качества веб-сайта.

Об экспертной оценке

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

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

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

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

Кроме того в подробном отчёте эсперт приводит описание каждой ошибки, восприятие ее пользователем, классификацию ошибки по 4 категориям.

По ходу выполнения сценария эксперт также обращает внимание на следующие вопросы: 

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

Примечания

*«Хлебные крошки» (англ. Breadcrumbs) — элемент навигации по сайту, представляющий собой путь по сайту от его «корня» до текущей страницы, на которой находится пользователь.

Обычно представляет собой полосу в верхней части страницы примерно такого вида: “Главная страница → Раздел → Подраздел → Текущая страница” Все элементы, кроме последнего, обычно являются внутренними гиперссылками.
 

CTO компании LeanTech рассказывает про ошибки в ПО и нюансы работы специалистов технической поддержки по SLA Техническая поддержка ПО по SLA: виды ошибок, кто устраняет и как

Поддержка и сопровождение ПО — неотъемлемая часть жизненного цикла программного обеспечения. 

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

Цель данной статьи — объяснить информацию по ошибкам в ПО, чтобы у компаний было понимание процессов технической поддержки по SLA.

В этой статье:

  • Виды ошибок в ПО.
  • Степень критичности ошибок в ПО.
  • Какие специалисты обрабатывают ошибки в ПО?
  • Как выглядит процесс обработки багов ПО?

Начнем с того, какие баги встречаются в программах.

Виды ошибок в ПО

Ошибки в программном обеспечении (ПО) могут быть разных типов и иметь разные причины. Рассмотрим основные из них.

1. Синтаксические ошибки — это ошибки, которые появляются из-за нарушения правил языка программирования. Такие ошибки возникают при написании кода и могут привести к тому, что программа не будет компилироваться или будет работать некорректно.

2. Логические ошибки связаны с неправильной логикой работы программы.

3. Функциональные ошибки — это результат неправильной работой отдельных функций или модулей программы. 

Логические и функциональные ошибки могут привести к неправильному результату работы программы или к ее некорректному поведению.

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

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

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

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

Теперь поговорим про степень их критичности.

Степень критичности ошибок в ПО

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

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

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

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

Критичность багов может зависеть от того, насколько широко используется программа и насколько она важна для бизнес-процессов компании. Например, если программа используется для обработки платежей, то даже небольшая ошибка может привести к серьезным финансовым потерям.

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

Далее — об IT-специалистах, которые занимаются исправлением рассмотренных выше багов.

Какие специалисты обрабатывают ошибки в ПО?

Обработка багов является важной частью процесса разработки программного обеспечения. Различные специалисты играют свои роли в обработке ошибок, чтобы обеспечить качество и надежность программы.

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

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

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

Аналитики — это специалисты, которые отвечают за анализ данных о багах и их влиянии на работу программы и бизнес-процессы компании. Они помогают определить критичность багов и разрабатывают стратегии для их устранения.

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

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

Теперь — более подробно о процессе работы специалистов с возникающими ошибками и сбоями.

Как выглядит процесс обработки багов ПО?

Процесс обработки багов включает несколько шагов, которые выполняются для корректной обработки ошибок:

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

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

3. Проверка бага — после регистрации бага, его проверяют на других устройствах и/или с другими настройками, чтобы подтвердить его существование.

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

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

6. Исправление бага — ответственный за исправление бага разрабатывает исправление и тестирует его, чтобы убедиться, что баг исправлен успешно.

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

8. Закрытие бага — после проверки исправления, баг закрывают в системе управления ошибками.

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

  • Как оформить пушкинскую карту если выдает ошибку
  • Как оформить перерасчет отпускных при счетной ошибке
  • Как оформить ошибку 404 на сайте
  • Как оформить бухгалтерскую справку на исправление ошибок
  • Как отформатировать флешку ошибка форматирования