Жизненный цикл дефекта

Дефекты и ошибки (error/defect(bug)/failure)

Дефект/Баг (Bug)

Несовершенство или недостаток рабочего продукта, проявляющееся в несоответствии требованиям или спецификациям. [Глоссарий ISTQB]

Ошибка (Error)

Действие человека, которое приводит к неправильному результату. [Глоссарий ISTQB]
Пример: пользователь вводит буквы в поля, где требуется вводить цифры (возраст, количество товара и т.п.).

Отказ (Failure)

Событие, при котором компонент или система не выполняют требуемую функцию в соответствии со спецификацией. [Глоссарий ISTQB]
Примет: аппаратный сбой, который не связан с работой самого продукта но приводящий к его не корректной работе.

Так что же такое баг на практике? Когда мы имеем ситуацию “1 требование = 1 тест-кейс”, то вопрос отпадает сам собой - тест-кейс не прошёл, значит требование реализовано не правильно, значит баг. Но обычно вариантов куда больше:

• работало, но вдруг перестало;
• работает, но неправильно;
• реализация не соответствует описанию и в задаче в явном виде не зафиксированы корректировки;
• нужно изменить название кнопки/страницы/раздела, потому что в них есть опечатка или “Отменить отмену” (классика!);
• опечатки в принципе (легко может иметь разный приоритет в зависимости от целей и задач проекта);
• после сохранения информация не появляется на странице, даже если в консоли 200 ОК;
• не все указанные при сохранении поля отображаются на странице, но поля неизменно показываются при редактировании;
• при нажатии на кнопку “УДАЛИТЬ ВООБЩЕ ВСЕ ДАННЫЕ КЛИЕНТА” нет модального окна с подтверждением Да/Нет, да и сделать это может любой пользователь без авторизации, который нашел ссылку;
• по переходу по прямой ссылке на услугу не проверяется какой пользователь сейчас авторизован и таким образом можно посмотреть чужие профили или детали услуг, если подобран валидный id;
• можно cURL’ом заказать услугу другому клиенту или в Elements через DevTools изменить стоимость в корзине (не проворачивайте такие сценарии не на своих рабочих проектах);
• информация торчит за границами своего блока или “наслаивается” на другой (ж-ж-ж-жуть, но на некоторых проектах этим можно легко пренебречь);
• страница очень долго открывается, ну о-о-очень долго - секунд 30 на стабильном интернете (взбешенный клиент гарантирован);
• система делает что-то, что она не должна делать согласно изначальной задумке. Например, закрытие аккаунта не только переводит его в статус “Закрыто”, но и возвращает клиенту все деньги, которые он принес проекту за всё время сотрудничества за уже оказанные услуги (о-о-ой!);
• неудобно пользоваться. Например, чтобы посмотреть детали услуги клиента, нужно зайти на три вкладки вглубь аккаунта, а смотреть нужно 2-3 раза в день. Или неудобно копировать информацию со страницы, а по рабочим вопросам это нужно делать несколько раз в день - это баг интерфейса и он должен быть исправлен.

При этом часто может возникнуть извечный вопрос “баг или фича?”, когда баг-репорт заводить не нужно. Это фича-реквест, если:

• нужно изменить название кнопки/страницы/раздела, потому что есть ощущение, что оно не отражает действительности;
• фичу сделали, но после использования видно, что есть простор для существенных улучшений. Например, по услуге не хватает мониторинга или статистических данных по использованию, а за перерасход может взиматься дополнительная плата - клиент точно будет несчастлив в неведении;
• знаете как улучшить ту или иную часть системы, чтобы было удобней. Например, меню необоснованно занимает 30% ширины экрана, а полезная информация ютится на оставшихся 70%;
• пользователь регулярно делает рутинные монотонные действия, которые можно автоматизировать. Например, копировать однотипную информацию с 12 страниц пагинации, когда простая выгрузка бы решила проблему;
• изобретаете велосипед из действующих фич продукта, чтобы добиться желаемого результата;
• на странице не хватает какой-то информации или возможности её добавить;
• на странице не хватает фильтров и пагинации, когда информации много и трудно найти нужное или отображение 1000+ элементов существенно сказывается на скорости загрузки страницы;
• пользователь ведет дополнительную отчетность в блокноте/экселе, когда проблему можно решить выводом ID на странице и несколькими фильтрами.

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

Классификация дефектов

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

Дефекты требований и спецификаций (Requirements and Specifications Defects)

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

• Двусмысленными;
• Противоречивыми;
• Непонятными;
• Избыточными;
• Неточными.

Некоторые специфические дефекты требований / спецификаций:

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

Дефекты дизайна

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

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

Дефекты кода

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

• Алгоритмические дефекты и дефекты обработки:
  • Непроверенные условия overflow and underflow;
  • Сравнение несоответствующих типов данных;
  • Преобразование одного типа данных в другой;
  • Неправильный порядок арифметических операторов;
  • Неправильное использование или пропуск круглых скобок;
  • Потеря точности (Precision loss);
  • Неправильное использование знаков.
• Дефекты управления, логики и последовательности: этот тип дефектов включает неправильное выражение операторов case, неправильное повторение циклов и пропущенные пути;
• Типографические дефекты: в основном это синтаксические ошибки, например неправильное написание имени переменной, которые обычно обнаруживаются компилятором, self-reviews, or peer reviews;
• Дефекты инициализации: этот тип дефектов возникает, когда операторы инициализации пропущены или неверны. Это может произойти из-за недопонимания или отсутствия связи между программистами или программиста и дизайнера, небрежности или непонимания среды программирования;
• Дефекты потока данных: дефекты потока данных возникают, когда код не следует необходимым условиям потока данных;
• Дефекты данных: на это указывает неправильная реализация структур данных;
• Дефекты интерфейса модуля: возникают из-за использования неправильных или несовместимых типов параметров, неправильного количества параметров или неправильного порядка параметров;
• Дефекты документации кода: когда документация по коду не описывает, что программа на самом деле делает, либо является неполной или двусмысленной;
• Внешнее оборудование, дефекты программных интерфейсов: эти дефекты возникают из-за проблем, связанных с Системными вызовами, Ссылками на базы данных, Последовательностью ввода / вывода, Использованием памяти, Использованием ресурсов, Обработкой прерываний и исключений, Обменом данными с оборудованием, Протоколами, Форматами, Интерфейсами с файлами сборки, Временными последовательностями.

Дефекты тестирования

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

• Дефекты тестовой обвязки: Для тестирования программного обеспечения на уровне модулей и интеграции необходимо разработать вспомогательный код. Это называется Test Harness или scaffolding code. Test Harness должен быть тщательно спроектирован, реализован и протестирован, поскольку это рабочий продукт, и этот код можно повторно использовать при разработке новых версий программного обеспечения;
• Дизайн тестового случая и дефекты процедуры тестирования: сюда входят неправильные, неполные, отсутствующие, несоответствующие тестовые примеры и процедуры тестирования.

Жизненный цикл дефекта (Defect/Bug Life Cycle)

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

Статусы дефекта

• Новый (New): когда новый дефект регистрируется и публикуется впервые;
• Назначен (Assigned): после публикации бага тестировщиком руководитель тестировщика утверждает ошибку и передает ее команде разработчиков;
• Открыт (Open): разработчик начинает анализ и работает над исправлением бага;
• Исправлен (Fixed): разработчик внес необходимое изменение в код и проверил его;
• Ожидает повторного тестирования (Pending retest): как только дефект будет исправлен, разработчик предоставляет тестировщику конкретный код для повторного тестирования кода. Поскольку тестирование программного обеспечения остается незавершенным со стороны тестировщиков, ему присваивается статус «ожидает повторного тестирования»;
• Повторное тестирование (Retest): на этом этапе тестировщик выполняет повторное тестирование кода, чтобы проверить, исправлен ли дефект разработчиком;
• Проверен (Verified): тестировщик повторно тестирует баг после его исправления разработчиком. Если баг исправлен, то присваивается статус «проверено»;
• Переоткрыт (Reopen): если баг сохраняется даже после того, как разработчик исправил баг, тестировщик меняет статус на «повторно открыт». И снова баг проходит жизненный цикл.
• Закрыт (Closed): если баг больше не существует, тестировщик присваивает статус «Закрыто».
• Дубль (Duplicate): если дефект повторяется дважды или дефект соответствует той же концепции ошибки, статус изменяется на «дублировать».
• Отклонен (Rejected): если разработчик считает, что дефект не является таковым, он меняет статус на «отклонен»;
• Отложен (Deferred): если текущий баг не является приоритетным и ожидается, что он будет исправлен ​​в следующем выпуске, таким багам присваивается статус «Отложено»;
• Не является багом (Not a bug): если это не влияет на функциональность приложения, то багу присваивается статус «Не является багом».

Утечка дефектов и релиз бага (Bug Leakage & Bug Release)

Утечка бага (Bug Leakage): возникает когда пропускается баг в билде, который вышел в Production. Если баг был обнаружен конечным пользователем или заказчиком, мы называем это утечкой ошибок.

Выпуск бага (Bug release): выпуск программного обеспечения в Production с некоторыми известными багами. Эти известные баги следует включить в примечания к выпуску (release notes). Другой вариант - передача программного обеспечения группе тестирования с некоторыми известными багами, серьезность и приоритет которых невысоки. Эти ошибки можно исправить перед выпуском в Production.

Основное отличие отладки от тестирования (Debugging) Vs. Testing

После того, как разработчик получил баг-репорт, он приступает к исправлению бага. Но, прежде чем ошибку исправить, нужно ее воспроизвести, понять, как она происходит и где ее найти в коде. Дебаг, буквально “de”+”bug” - это и есть процесс поиска и устранения ошибок в коде. Специальная debug-версия билда приложения может иметь расширенный вывод для более информативных логов или любые другие модификации для упрощения понимания проблемы. Тактика отладки может включать интерактивную отладку, анализ потока управления, модульное тестирование, интеграционное тестирование, анализ логов, мониторинг на уровне приложения или системы, дампы памяти и профилирование. Многие языки программирования и инструменты разработки программного обеспечения также предлагают программы для помощи в отладке, известные как отладчики/дебаггеры.

❗ see video

Маскировка дефектов (Defect masking)

Маскирование дефектов (defect masking): Случай, когда один дефект препятствует нахождению другого. (IEEE 610)

Скрытый дефект (Latent defect)

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

Сортировка дефектов (Bug triage)

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

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

Подсев недочетов (fault seeding)

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

Валидация vs верификация

Верификация (Verification)

Доказанное объективными результатами исследования подтверждение того, что определенные требования (спецификации, формальные требования) были выполнены. [Глоссарий ISTQB]

Валидация (Validation)

Доказанное объективными результатами исследования подтверждение того, что требования для ожидаемого конкретного использования приложения (соответствие ожиданиям и требованиям пользователей) были выполнены. [Глоссарий ISTQB]

Пример

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

Priority vs Severity

Приоритет (Priority)

Степень важности, присваеваемая объекту. Например, дефекту или задаче. [Глоссарий ISTQB]
Указывает на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект. Выставляется менеджером, тимлидом или заказчиком.

Градация Приоритета дефекта (Priority):

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

Критичность/Серьезность (Severity)

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

Градация Критичности дефекта (Severity)

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

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

• S3 Значительная (Major)
  Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.

• S4 Незначительная (Minor)
  Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.

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

Сочетания Severity и Priority

• High Priority and High Severity
  Любой Critical/major сбой бизнес-модели, критическая проблема, при которой полностью не работает большая часть функциональности или основной компонент системы:

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

• High Priority and Low Severity
  Любые minor severity дефекты, которые влияют на взаимодействие с пользователями / репутацию:

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

• Low Priority and High Severity
  Проблема, которая пока не повлияет на бизнес, но имеет большое влияние с точки зрения функциональности:

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

• Low Priority and Low Severity
  Любые орфографические ошибки / начертание / несовпадение шрифта в абзаце 3-й или 4-й страницы заявки, а не на главной или титульной странице / заголовке. Эти дефекты возникают, когда это не влияет на функциональность, но все же в небольшой степени не соответствует стандартам. Обычно сюда классифицируются косметические ошибки или, скажем, размеры ячейки в таблице пользовательского интерфейса:

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