Теория тестирования
Ошибка, дефект, сбой и отказ: в чём разница
Ошибку (error, mistake) совершает человек, и из-за неё в требованиях или коде появляется дефект (defect, bug, fault). Когда код с дефектом выполняется, система может дать отказ (failure), то есть повести себя не так, как ожидалось, а сбой – это кратковременный отказ, который проходит сам или после небольшого вмешательства. Улучшения (improvement, enhancement) и запросы на изменение (change request) к дефектам не относятся: они описывают, как сделать лучше то, что работает правильно, или добавить то, чего пока нет.
- Ошибка → дефект → отказ
- цепочка из программы ISTQB Foundation Level
- Сбой
- отказ, который проходит сам или после небольшого вмешательства
- Бесплатно
- урок с заданиями в моём базовом курсе
Ошибка, дефект и отказ по ISTQB
В программе ISTQB Foundation Level эти понятия связаны в цепочку. Человек совершает ошибку, ошибка вносит дефект в код или в другой рабочий продукт, например в требования, а выполнение кода с дефектом может привести к отказу. Отказ при этом случается не всегда: некоторым дефектам нужны особые входные данные или редкие условия, и проявляются они редко или никогда.
В русском переводе программы 2018 года понятия называются так: ошибка (просчёт), дефект (недочёт, помеха) и отказ. В английском у первых двух есть синонимы, error и mistake, defect, bug и fault, а отказ по-английски failure. В программе 2023 года цепочка осталась прежней.
Ошибка (error, mistake)
Действие человека, которое даёт неверный результат. Пример: с заказчиком договорились, что кнопка будет красной, а аналитик написал в требованиях, что она зелёная.
Дефект (defect, bug, fault)
Изъян в компоненте или системе, из-за которого она может не выполнить свою функцию. Тестировщик не заметил неточность, когда проверял требования, разработчик не сверился с дизайном, и зелёная кнопка попала в код. Фактический результат теперь расходится с ожидаемым.
Отказ (failure)
Отклонение компонента или системы от ожидаемого поведения или результата во время работы. Это то, что видит пользователь: кнопку не того цвета, неверную сумму платежа, страницу с ошибкой.
Откуда берутся ошибки и отказы
Ошибка почти всегда появляется раньше дефекта. Причин несколько: неопытность человека, который недавно пришёл на проект, сложность проекта или задачи, загруженность на работе и обычный человеческий фактор. Программа ISTQB добавляет нехватку времени, недопонимание между участниками проекта, в том числе в требованиях, непонимание интерфейсов между частями системы и новые незнакомые технологии.
Одна ошибка тянет за собой следующую. В примере ISTQB ошибка при сборе требований даёт дефект в требованиях, по ним разработчик ошибается в коде, и дефект появляется уже в программе. Поэтому тестирование начинают с требований: исправить строку в документе дешевле, чем переделывать готовую функцию.
Отказ может случиться и без дефекта в коде. Отключение электричества, радиация, электромагнитные поля и загрязнения меняют условия работы оборудования, и система отказывает, хотя код в порядке.
Не каждый упавший тест означает отказ. Тест может упасть из-за ошибки в самом тесте, в тестовых данных или в окружении, и такой результат называют ложноположительным. Обратный случай, когда тест пропустил настоящий дефект, называют ложноотрицательным.
Пример: ночью упал автотест оформления заказа в интернет-магазине. Прежде чем заводить баг, тестировщик смотрит причину и видит, что на тестовом стенде закончился остаток товара, которым пользуется тест. Дефекта в продукте нет, поэтому правят тестовые данные, а код оставляют как есть.
Сбой и отказ: в чём разница
Отдельного термина "сбой" в ISTQB нет. В глоссарии есть только failure, и русский перевод программы передаёт его словом "отказ", хотя местами пишет и "сбой". Определения, которые я привожу, совпадают с ГОСТ 27.002-89 "Надёжность в технике". Отказ там назван событием, при котором объект перестаёт быть работоспособным. Сбой – это самоустраняющийся отказ или однократный отказ, который устраняется незначительным вмешательством оператора.
Сбой не так страшен. Пример: в системе перестала открываться страница, разработчик быстро это заметил и поправил. Или пропал свет, после включения система сбоила, но заработала, как только вернули настройки.
Отказ серьёзнее: работоспособность нарушена, и последствия существенны. Если в здании выбило распределительный щит и система осталась без питания, это отказ, и восстанавливать её придётся всерьёз. Причиной бывает и дефект в коде, и окружающая среда.
В баг-трекере вроде Jira из всех этих понятий заводят только дефекты. Ошибки, сбои и отказы отдельными записями не оформляют: тестировщик видит отказ, находит за ним дефект и пишет баг-репорт.
Improvement, enhancement, feature и change request
Кроме дефектов, в трекере бывают записи о том, что работает правильно, но может стать лучше. Записи в Jira и похожих системах называют сущностями, или issue. Issue здесь означает любой элемент системы, будь то баг, задача или история, и дословный перевод "проблема" сбивает с толку.
Отдельных типов для улучшений на проекте может и не быть. Тестировщик вправе попросить их завести: проекту это на пользу, потому что улучшения делают продукт удобнее, а удобный продукт приводит больше пользователей и денег.
Improvement (улучшение)
Функция уже есть, но её можно сделать удобнее. Например, на странице слишком много элементов и часть стоит убрать, кнопку лучше перенести или поменять цвета. Цель в том, чтобы пользователю было удобнее (UX).
Enhancement (новая возможность)
Функции пока нет, но с ней система станет лучше. В этом главное отличие от improvement, которое улучшает уже существующее.
Feature (фича)
Запрос на новую функцию или на расширение существующей. По нему пишут новое требование, пользовательскую историю или раздел спецификации и делят работу на задачи. Обычная иерархия такая: эпик, например аутентификация и авторизация пользователя, делится на фичи, фичи на пользовательские истории (user story), истории на задачи (task) для тестировщика, разработчика, аналитика или дизайнера.
Change request (запрос на изменение)
Изменение функции, у которой уже есть требования. Обычно его заводят аналитики или владелец продукта, и в системе сохраняется история того, что поменяли. Изменить существующее можно и фичей, это зависит от правил компании, но в идеале для этого служит change request.
Как оформить улучшение
Improvement и enhancement оформляют как баг-репорт с теми же полями, только заголовок нейтральный, без слов о том, что что-то сломано, например "Было бы неплохо улучшить такую-то функцию". В шагах показывают, где находится функция. В фактическом результате описывают, как она работает сейчас, а в ожидаемом – как могла бы работать. Если можете набросать прототип будущего дизайна, хотя бы от руки, приложите его.
Пример для интернет-магазина. Заголовок: "Checkout: было бы удобно сохранять адрес доставки для следующих заказов". Фактический результат: при каждом заказе покупатель вводит адрес заново. Ожидаемый: адрес из прошлого заказа подставляется в форму, и его можно сменить одним нажатием. Такой функции пока нет, поэтому это enhancement.
Запись назначают на тех, кто решает: менеджера проекта или продукта, владельца продукта, аналитика. Её можно и просто добавить в бэклог, чтобы обсудить на груминге (backlog refinement). Улучшение могут взять в спринт, а могут отклонить. У других людей бывает своё видение продукта, а функцию могут скоро убрать, и тогда усилия команды пропадут зря.
Предлагать улучшения может любой участник команды, от тестировщика до разработчика и дизайнера. Мой совет: подкрепляйте идею деньгами и цифрами. Улучшение, после которого пользователям удобнее, а бизнес получает больше клиентов или выручки, принимают охотнее, и любой отчёт убедительнее с числами, лучше в динамике.
Об этом стоит рассказать на собеседовании, если спросят, как тестировщик может повлиять на качество продукта, кроме поиска багов.
Видеоурок, шпаргалки и задания
Я разбираю ошибки, сбои, отказы и улучшения в уроке курса "Тестировщик с нуля" на YouTube. В бесплатном базовом курсе по тестированию тема идёт уроком "Ошибки, сбои, отказы, улучшения", и после теории в нём есть задания. Для самостоятельной практики советую написать несколько improvement и enhancement для любого сайта.
Шпаргалка по жизненному циклу бага ведёт дефект от обнаружения до закрытия и объясняет каждый статус. Шпаргалка по баг-репорту разбирает поля отчёта, в которых оформляют и улучшения, а в тренажёре нужно найти ошибки в чужих баг-репортах.
Курсы по теме
Вопросы и ответы
Чем ошибка отличается от дефекта?
Ошибку совершает человек, например аналитик неверно записал требование. Дефект появляется как результат ошибки в коде, требованиях или другом рабочем продукте. Ошибка предшествует дефекту.
Чем дефект отличается от отказа?
Дефект сидит в коде или документе, а отказ виден во время работы: система ведёт себя не так, как ожидалось. Отказ случается, когда выполняется код с дефектом, но не каждый дефект до него доходит. Отказ могут вызвать и внешние условия, например пропавшее электропитание.
Чем сбой отличается от отказа?
Сбой – это кратковременный отказ, который проходит сам или после небольшого вмешательства, например перезапуска или возврата настроек. При отказе работоспособность системы нарушена, и её приходится восстанавливать. В ISTQB отдельного термина для сбоя нет, есть только отказ (failure).
Bug, defect и fault – это одно и то же?
Да, в глоссарии ISTQB bug и fault указаны синонимами defect. Error и mistake тоже синонимы и означают ошибку человека, а failure переводится как отказ.
Чем improvement отличается от enhancement?
Improvement улучшает функцию, которая уже есть, например упрощает перегруженную страницу. Enhancement предлагает функцию, которой пока нет. Оба оформляют как баг-репорт с нейтральным заголовком и передают на решение менеджеру, владельцу продукта или аналитику.
Что такое change request?
Запрос на изменение существующей функции, у которой уже есть требования. Обычно его создают аналитики или владелец продукта, чтобы в системе сохранилась история изменений.
Посмотреть программы курсов
Программа каждого курса открыта целиком: видны все модули, уроки и число шагов.