Какие виды ошибок включены в отчет об ошибках

3.2. Подготовка отчетов об ошибках

Отчеты об ошибках (на англ. «Bug Report»)– это основной материальный продукт тестирования, надежная техническая документация, которая описывает вид ошибки в тестируемой системе.

Для упрощения организации взаимодействия групп и общего централизованного хранения отчетов об ошибках следует использовать системы отслеживания ошибок (на англ. «bug tracking»). Это позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость и эффективность исправления ошибок, видеть наиболее нестабильные компоненты системы, а также поддерживать связь между группой разработчиков и группой тестирования (уведомления об изменениях по почте и т.п.). Чем больше проект, тем сильнее потребность в централизованном хранилище дефектов.

Пример одной из свободных систем отслеживания ошибок с веб-интерфейсом. является Bugzilla (разработка компании Mozilla). Данная система очень проста и популярна в использовании [10].

Подобная система обеспечивает следующие функции:

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

система уведомления о появлении новых ошибок, об изменении статуса известных в системе ошибок (как правило, это уведомления по электронной почте);

отчеты об актуальных ошибках по компонентам системы, по интервалам времени, по группам разработчиков и разработчикам;

информация об истории ошибки (в том числе отслеживание похожих ошибок, отслеживание повторного возникновения ошибки);

правила доступа к ошибкам тех или иных категорий;

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

Существуют основные виды продвижения ошибки (на англ. «bug») по системе (на англ. «Defect flow»)(см. рисунок 6).

Рисунок 6 — Defect flow

При поступление ошибки в систему, из любого источника (заказчик, разработчик, тестировщик), баг принимает статус new (пер. с англ. «новый»). Затем рассматривается программистом его описание и: или ошибка решается (на англ. «resolve») или ей ставится статус duplicated (пер. с англ. «дубль»), что означает, что данная ошибка уже была и на данном этапе решается, или же ей ставится статус invalid (пер. с англ. «необоснованный»)- неверное описание, такой ошибки не существует. После всего этого командой тестировщиков данная ошибка перепроверяется и закрывается (на англ. «verify») в случае, если она больше не повторяется, или переоткрывается (на англ. «reopen»), если изменения все равно приводят к ошибке.

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

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

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

— технические — неправильное заполнение отдельных реквизитов и арифметические ошибки, возникающие при заполнении форм отчетности;

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

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

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

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

При составлении первой бухгалтерской отчетности, вновь созданным организациям, необходимо учитывать положения п. 2 ст. 14 Закона о бухгалтерском учете, устанавливающие, что для организаций, созданных после 1 октября, первым отчетным годом считается период с даты их государственной регистрации по 31 декабря следующего года.

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

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

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

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

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

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

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

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

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

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

1. Отчетная дата бухгалтерской отчетности — для годовой отчетности это 31 декабря отчетного года, а для промежуточной — последняя дата отчетного периода.

2. Дата утверждения бухгалтерской отчетности — это дата проведения общего годового собрания собственников организации, на котором рассмотрены итоги ее деятельности за отчетный год. Обычно это дата протокола общего собрания или решения собственника об утверждении финансовых итогов деятельности организации. В соответствии с законодательством РФ для АО дата утверждения годовой бухгалтерской отчетности должна быть в пределах с 1 февраля до 30 июня года, следующего за отчетным, а для ООО — с 1 февраля до 30 апреля года, следующего за отчетным. Если отчетность предоставляется внешним пользователям до проведения общего собрания собственников, реквизит «Дата утверждения» не заполняется. Не заполняется он и в промежуточной отчетности.

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

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

3 Методологические ошибки. Достаточно часто при составлении бухгалтерского баланса бухгалтеры нарушают п. 34 ПБУ 4/99, согласно которому не допускается зачет между статьями активов и пассивов. На практике же бухгалтерии ошибочно производят зачет между различными статьями дебиторской и кредиторской задолженности. В результате имущественное положение организации, отраженное в отчетности, оказывается недостоверным. Особенно часто организации отражают в балансе сальдированный остаток по счету 68 «Расчеты по налогам и сборам» и счету 76 «»Расчеты с разными дебиторами и кредиторами».

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

Например, когда организация в отчетном периоде перечислила аванс, отраженный по дебету счета 60 «Расчеты с поставщиками и подрядчиками», субсчет «Авансы выданные», и уже получила до отчетной даты в счет этого аванса товары (работы, услуги), отраженные по кредиту счета 60, субсчет «Расчеты по полученным товарам (работам, услугам)». Если организация своевременно не провела зачет между различными субсчетами счета 60, валюта бухгалтерского баланса оказывается завышенной.

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

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

Еще одна методологическая ошибка — отражение выданных организацией безвозмездных займов (займов с нулевой процентной ставкой) в составе финансовых вложений. В соответствии с п. 2 ПБУ 19/02 одним из условий принятия к бухгалтерскому учету активов в качестве финансовых вложений является способность приносить организации экономические выгоды (доход). Очевидно, что предоставление беспроцентных займов дохода не приносит, а следовательно, отражать данные активы в бухгалтерской отчетности необходимо как прочие или зачислять их в состав прочей дебиторской задолженности.

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

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

Данный подход противоречит нормам Закона об ООО, согласно которым чистые активы необходимы для оценки значительного количества показателей. Например, показатель чистых активов используется в ст. 29 указанного Закона для оценки возможности выплаты дивидендов организацией, а в п. 3 ст. 20 — для оценки возможности функционирования организации в будущем. Ссылка на то, что в настоящее время не утвержден федеральный закон, определяющий порядок расчета чистых активов для обществ с ограниченной ответственностью, предусмотренный ст. 20 Закона об ООО, не может являться оправданием.

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

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

Однако в соответствии с п. 29 ПБУ 4/99 отчет о движении денежных средств должен характеризовать изменения в финансовом положении организации в разрезе текущей, инвестиционной и финансовой деятельности. Определение этим видам деятельности дано в п. 15 Указаний о порядке составления отчетности:

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

— инвестиционная — деятельность, связанная с приобретением земельных участков, зданий и иной недвижимости, оборудования, нематериальных активов и других внеоборотных активов, а также их продажей; с осуществлением собственного строительства, расходов на НИОКР, финансовых вложений (приобретение ценных бумаг других организаций, в том числе долговых, вклады в уставные (складочные) капиталы других организаций, предоставление займов и т.п.);

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

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

Типичные ошибки в составлении отчетности

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

Ошибки в отчетности могут появляться вследствие следующих ситуаций:

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

в случае арифметических (счетных) ошибок;

неправильным применением учетной политики;

неправильным использование информации, имеющейся на момент подписания отчетности;

в результате недобросовестных действий должностных лиц.

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

Стоимость составления отчетности

Нулевая отчетность на УСН — 4 000 руб.
Нулевая отчетность на ОСНО — 5 000 руб.
Отчетность на УСН от 5 000 руб.
Отчетность на ОСНО от 8 000 руб.

Виды ошибок при составлении отчетности

Все виды ошибок можно разделить на три основных типа:

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

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

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

Выявление и исправление ошибок в отчетности

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

проведение инвентаризации раз в год, а также сверка расчетов по актам сверки с контрагентами;

проведение сопоставимости показателей данных отчетности (арифметически-логический контроль).

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

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

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

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

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

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

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

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

Использование коэффициента отклоненных дефектов для улучшения отчета об ошибках

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

Существует множество показателей по которым можно измерить эффективность работы команды тестировщиков. Одним из них является коэффициент отклоненных дефектов/ошибок (Rejected Defect Ratio), или же количество отклоненных отчетов об ошибках деленное на общее количество принятых отчетов. Должно быть, вы думаете, что если количество отклоненных отчетов равно нулю, то это хорошо, но здесь не все так просто. Давайте разберемся в типах отклоненных ошибок, посмотрим, как они влияют на коэффициент отклоненных ошибок, и вычислим правильный коэффициент для вашей команды.

Есть три категории отклонённых ошибок:

Невоспроизводимые ошибки;
Некорректные ошибки;
Повторяющиеся ошибки.

Невоспроизводимые ошибки

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

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

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

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

Оба этих типа ошибок обычно помечаются в системах отчетов об ошибках как » отклонено – нельзя воспроизвести.”

Некорректные ошибки

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

Такие ошибки обычно помечаются в системах отчетов об ошибках как «отклонено — не ошибка” или» отклонено—по архитектуре » (то есть поведение соответствует архитектуре).

Повторяющиеся ошибки

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

Эти ошибки обычно помечаются в системах отчетов об ошибках как «отклонено — дубликат/повторение.”

Как отклоненные ошибки влияют на команду

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

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

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

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

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

Мнение против полного отсутствия отклоненных ошибок

Команда тестировщиков должна контролировать и стремиться к снижению уровня RDR. Вопрос лишь в том, какой показатель RDR считать хорошим?

На первый взгляд кажется, что 0% — это оптимальный результат, но я с этим категорически не согласен. Я считаю, что когда RDR держится на каком-то здоровом уровне – это нормально, поскольку если он близок к нулю, команда тестировщиков очевидно страдает от не менее серьезных проблем, чем, допустим, слишком высокий RDR.

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

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

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

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

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

Нахождение оптимального коэффициента отклоненных дефектов

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

Я не думаю, что есть какое-либо оправдание этому значению, кроме моего внутреннего чувства. Это определенно не научно. Я не буду спорить с командой, которая нацелена на 10 или 20 процентов, но я думаю, что терпеть 30 процентов или ставить цель в 5 процентов – это уже проблема.

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

По устоявшейся традиции ждем ваши комментарии и приглашаем на бесплатный вебинар, который состоится уже 14 июня. До встречи!