---
title: Тестирование ПО
seo:
  title: Тестирование ПО — QA
  description: "Тема «Тестирование ПО» для собеседования QA. Опишите основные фазы STLC? Дайте определение Entry и Exit Criteria. Что такое Bug, Error, Failure, Fault?"
---

[Все темы QA](/qa)

## <strong>Опишите основные фазы</strong> <code>STLC</code><strong>? Дайте определение</strong> <code>Entry</code> <strong>и</strong> <code>Exit Criteria</code><strong>.</strong> [#q-14bee738d69b812381e4d489a2b404d5]

Фазы <code>STLC</code> (Software Testing Life Cycle) представляют собой последовательность этапов, через которые проходит процесс тестирования программного обеспечения. Основные фазы <code>STLC</code> обычно включают&#58;

1. <strong>Планирование тестирования</strong>&#58; определение стратегии
   тестирования, создание плана тестирования, определение ресурсов.

1. <strong>Анализ требований</strong>&#58; изучение требований к программному
   продукту для создания тестовых случаев.

1. <strong>Написание тестовых случаев</strong>&#58; разработка набора тестовых
   сценариев и их документирование.

1. <strong>Выполнение тестирования</strong>&#58; запуск тестов, сбор результатов
   и регистрация найденных дефектов.

1. <strong>Отчётность и анализ</strong>&#58; подготовка отчётов о результатах
   тестирования, анализ их эффективности и обсуждение выявленных проблем.

<strong>Entry и Exit Criteria (Критерии входа и выхода)</strong>&#58;

- <strong>Критерии входа (Entry Criteria)</strong>&#58; условия, которые должны
  быть выполнены для начала выполнения конкретной фазы STLC. Например, для
  перехода к фазе написания тестовых случаев может потребоваться завершение
  анализа требований.

- <strong>Критерии выхода (Exit Criteria)</strong>&#58; условия, которые должны
  быть выполнены для завершения конкретной фазы STLC и перехода к следующей.
  Например, для завершения фазы написания тестовых случаев может потребоваться
  написание и утверждение определённого количества тестовых кейсов.

Эти критерии помогают управлять процессом тестирования и обеспечивать его структурированность и последовательность действий.

:::note[Ссылки для изучения]

1. [SLTC - Жизненный цикл тестирования приложения](https://testengineer.ru/zhiznennyj-cikl-testirovaniya-prilozhenij/)
   :::

---

## <strong>Что такое</strong> <code>Bug</code><strong>,</strong> <code>Error</code><strong>,</strong> <code>Failure</code><strong>,</strong> <code>Fault</code><strong>?</strong> [#q-14bee738d69b81f0b39fe0756c249d73]

В контексте тестирования программного обеспечения&#58;

1. <code>Bug</code> <strong>(Ошибка)</strong>&#58; Это дефект или
   несоответствие, найденное в программном коде или функциональности. Ошибка
   возникает в результате ошибки разработки или неправильного функционирования
   программы.

1. Error&#58; действие человека, которое приводит к неправильному результату, например неверное понимание требования или ошибка в коде.

1. <code>Failure</code> <strong>(Отказ)</strong>&#58; Это некорректное поведение
   программы или системы, которое происходит в результате ошибки или дефекта.
   Отказ проявляется как недостаток в функциональности или как неспособность
   приложения выполнить ожидаемые задачи.

1. Fault, defect и bug обозначают дефект рабочего продукта, например кода или требования. При определённых условиях дефект может проявиться как failure, наблюдаемый отказ системы.

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

:::note[Ссылки для изучения]

1. [Разница между Bug, Error, Failure, Fault](https://www.360logica.com/blog/difference-between-defect-error-bug-failure-and-fault/)
   :::

---

## <strong>Какие есть атрибуты баг-репорта? Какие основные поля для заполнения?</strong> [#q-14bee738d69b81109bddd85a4e550e68]

Атрибуты баг-репорта обычно включают следующие основные поля для заполнения&#58;

1. <strong>Заголовок</strong>&#58; Краткое описание проблемы или дефекта.

1. <strong>Описание</strong>&#58; Подробное описание того, что происходит или
   что ожидается.

1. <strong>Шаги воспроизведения</strong>&#58; Последовательность действий,
   необходимых для воспроизведения проблемы.

1. <strong>Ожидаемое поведение</strong>&#58; Четкое описание ожидаемого
   поведения приложения или системы.

1. <strong>Фактическое поведение</strong>&#58; Описание того, что происходит на
   самом деле, включая ошибки или некорректное поведение.

1. <strong>Приоритет и серьезность</strong>&#58; Оценка важности и влияния
   дефекта на работу системы.

1. <strong>Среда и версия</strong>&#58; Информация о среде, в которой возникает
   проблема (например, операционная система, браузер, версия ПО).

1. <strong>Приложенные файлы и скриншоты</strong>&#58; Дополнительные материалы,
   такие как скриншоты или логи, помогающие воспроизвести и понять проблему.

1. <strong>Ответственный разработчик</strong>&#58; Информация о том, кому
   назначен баг-репорт для исправления.

1. <strong>Статус и обновления</strong>&#58; Текущее состояние и последние
   обновления по проблеме.

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

:::note[Ссылки для изучения]

1. [Структура и атрибуты баг-репорта](https://sky.pro/media/struktura-i-atributy-bag-reporta-detalnyj-razbor/)
   :::

---

## <strong>Какова разница между приоритетом и серьезностью?</strong> [#q-14bee738d69b81e3a528cb66257753f8]

В контексте управления дефектами&#58;

1. <strong>Приоритет</strong> определяет, насколько быстро нужно устранить
   дефект или проблему. Он отражает важность исправления относительно других
   задач разработки или тестирования. Высокий приоритет означает, что дефект
   требует немедленного внимания.

1. <strong>Серьезность</strong> указывает на воздействие дефекта на
   работоспособность или безопасность системы. Это оценка влияния проблемы на
   пользователя или бизнес-процессы. Высокая серьезность означает, что дефект
   имеет значительное влияние и потенциально наносит ущерб.

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

:::note[Ссылки для изучения]

1. [Ключевая разница между приоритетом и серьёзностью](https://ru.css-code.org/8222616-severity-and-priority-in-testing-differences-and-example#:~:text=%D0%9A%D0%BB%D1%8E%D1%87%D0%B5%D0%B2%D0%B0%D1%8F%20%D1%80%D0%B0%D0%B7%D0%BD%D0%B8%D1%86%D0%B0.%20%D0%9F%D1%80%D0%B8%D0%BE%D1%80%D0%B8%D1%82%D0%B5%D1%82%20-%20%D1%8D%D1%82%D0%BE,-%20%D1%81%20%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C%D1%8E%20%D0%B8%D0%BB%D0%B8%20%D1%81%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82%D0%B0%D0%BC%D0%B8)
   :::

---

## <strong>Приведите примеры серьезного, но не приоритетного бага.</strong> [#q-14bee738d69b81d4be0ad168e51d4023]

Пример серьезного, но не высокоприоритетного бага может быть следующим&#58;

Описание&#58; редко используемый модуль экспорта аварийно завершает приложение при открытии. Модуль отключён в текущем релизе и недоступен пользователям.

Серьёзность&#58; высокая, поскольку при воспроизведении приложение аварийно завершается.

Приоритет&#58; может быть низким, пока модуль недоступен и не входит в ближайший релиз. Перед его включением дефект нужно пересмотреть. Узкий охват сам по себе не оправдывает низкий приоритет.

:::note[Ссылки для изучения]

1. [Что такое баг-репорт и как его составить](https://practicum.yandex.ru/blog/chto-takoe-bug-report-kak-ego-sostavit/)
   :::

---

## <strong>В чем разница между валидацией и верификацией?</strong> [#q-14bee738d69b81a0a179fc03ace47268]

Разница между валидацией и верификацией заключается в следующем&#58;

1. <strong>Верификация</strong>&#58; Это процесс проверки того, что продукт
   разрабатывается согласно заданным спецификациям и требованиям. Верификация
   отвечает на вопрос "Мы делаем правильно?".

1. <strong>Валидация</strong>&#58; Это процесс проверки того, что
   разрабатываемый продукт соответствует потребностям и ожиданиям пользователя
   или заказчика. Валидация отвечает на вопрос "Мы делаем правильный продукт?".

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

:::note[Ссылки для изучения]

1. [Что такое валидация и какие у неё этапы](https://secrets.tinkoff.ru/glossarij/validaciya/)
   :::
