Баг и фича. В чем разница? Классификация и жизненный цикл дефектов.

Это баг, если: - работало, но вдруг перестало;

- работает, но неправильно;

– реализация не соответствует описанию и в задаче в явном виде не зафиксированы корректировки;

– нужно изменить название кнопки/страницы/раздела, потому что в них есть опечатка или “Отменить отмену” (классика!);

– опечатки в принципе (легко может иметь разный приоритет в зависимости от целей и задач проекта);

– после сохранения информация не появляется на странице, даже если в консоли 🟢 200 ОК;

– не все указанные при сохранении поля отображаются на странице, но поля неизменно показываются при редактировании;

– при нажатии на кнопку “УДАЛИТЬ ВООБЩЕ ВСЕ ДАННЫЕ КЛИЕНТА” нет модального окна с подтверждением Да/Нет, да и сделать это может любой пользователь без авторизации, который нашел ссылку;

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

– можно c URL’ом заказать услугу другому клиенту или в Elements через DevTools изменить стоимость в корзине;

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

– страница очень долго открывается, ну о-о-очень долго — секунд 30 на стабильном интернете (взбешённый клиент гарантирован);

– система делает что-то, что она не должна делать согласно изначальной задумке. Например, закрытие аккаунта не только переводит его в статус “Закрыто”, но и возвращает клиенту все деньги, которые он принёс проекту за всё время сотрудничества за уже оказанные услуги (о-о-ой!);

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

Это фича-реквест, если:

– нужно изменить название кнопки/страницы/раздела, потому что есть ощущение, что оно не отражает действительности;

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

– знаете как улучшить ту или иную часть системы, чтобы было удобней. Например, меню необоснованно занимает 30% ширины экрана, а полезная информация ютится на оставшихся 70%;

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

– на странице не хватает какой-то информации или возможности её добавить;

– на странице не хватает фильтров и пагинации, когда информации много и трудно найти нужное или отображение 1000+ элементов существенно сказывается на скорости загрузки страницы;

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

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

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

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

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

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

Дефекты дизайна. Дефекты дизайна возникают когда неправильно спроектированы:

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

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

К дефектам дизайна относятся:

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

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

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

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

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