Дефекты и ошибки
Прежде всего, стоит разобраться с терминологией. В определениях Error/Mistake/Defect/Bug/Failure/Fault три из них переводятся на русский язык как ошибка. Определения из ISTQB:
Просчет (mistake): См. ошибка;
Помеха (bug): См. дефект;
Недочет (fault): См. дефект;
Ошибка (error): Действие человека, которое приводит к неправильному результату;
Дефект (defect): Изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию, например неверный оператор или определение данных. Дефект, обнаруженный во время выполнения, может привести к отказам компонента или системы;
Отказ (failure): Отклонение компонента или системы от ожидаемого выполнения, эксплуатации или результата.
Неофициальные же источники показывают более широкую картину:
Ошибка (Error) возникает из-за просчета (Mistake) в написании кода разработчиком;
Дефект (Defect) это скрытый недостаток в ПО, возникший из-за ошибки в написании кода;
Когда дефект (Defect) обнаруживается тестировщиком, он называется багом (Bug);
Если тестировщики упустили дефект и его нашел пользователь, то это сбой (Failure);
Если программа в итоге не выполняет свою функцию, то это отказ (Fault).
Так что же такое баг на практике? Когда мы имеем ситуацию “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 должен быть тщательно спроектирован, реализован и протестирован, поскольку это рабочий продукт, и этот код можно повторно использовать при разработке новых версий программного обеспечения;
Дизайн тестового случая и дефекты процедуры тестирования: сюда входят неправильные, неполные, отсутствующие, несоответствующие тестовые примеры и процедуры тестирования.
В англоязычной Wikipedia описано плюс-минус то же самое.
Жизненный цикл дефекта (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-версия билда приложения может иметь расширенный вывод для более информативных логов или любые другие модификации для упрощения понимания проблемы. Тактика отладки может включать интерактивную отладку, анализ потока управления, модульное тестирование, интеграционное тестирование, анализ логов, мониторинг на уровне приложения или системы, дампы памяти и профилирование. Многие языки программирования и инструменты разработки программного обеспечения также предлагают программы для помощи в отладке, известные как отладчики/дебаггеры.
Маскировка дефектов (Defect masking)
Маскирование дефектов (defect masking): Случай, когда один дефект препятствует нахождению другого. (IEEE 610)
Скрытый дефект (Latent defect)
Дефект, который является существующим дефектом в системе, но еще не вызывал сбоев, поскольку подходящий набор входных данных для его проявления не был введен или его проявлению мешает другой дефект (Defect masking).
Сортировка дефектов (Bug triage)
Это формальный процесс определения серьезности и приоритета дефектов в зависимости от их severity, риска, повторяемости и т. д. во время Defect Triage Meeting. Такая встреча полезна в условиях ограниченных ресурсов, когда нужно разобраться с множеством ошибок и тем, какие из них приоритетные.
Понятие сортировки пришло из медицины, где это процесс быстрого обследования пациентов, доставленных в больницу, чтобы решить, какие из них наиболее серьезно больны и нуждаются в лечении в первую очередь. В тестировании мы используем ту же концепцию к ошибкам, обнаруженным на этапе тестирования.
Подсев недочетов (fault seeding)
Процесс намеренного внесения дефектов в дополнение к тем, что уже существуют в компоненте или в системе, для целей отслеживания уровня обнаружения и устранения, а также оценивания количества оставшихся в системе дефектов. Подсев недочетов обычно является частью процесса тестирования разработки и может применяться на любом уровне тестирования (компонентном, интеграционном или системном). (IEEE 610)
Источники:
Доп. материал:
Last updated
