Тестирование ПО

Все темы QA

Опишите основные фазы STLC? Дайте определение Entry и Exit Criteria.

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

1. Планирование тестирования: определение стратегии тестирования, создание плана тестирования, определение ресурсов.

2. Анализ требований: изучение требований к программному продукту для создания тестовых случаев.

3. Написание тестовых случаев: разработка набора тестовых сценариев и их документирование.

4. Выполнение тестирования: запуск тестов, сбор результатов и регистрация найденных дефектов.

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

Entry и Exit Criteria (Критерии входа и выхода):

• Критерии входа (Entry Criteria): условия, которые должны быть выполнены для начала выполнения конкретной фазы STLC. Например, для перехода к фазе написания тестовых случаев может потребоваться завершение анализа требований.

• Критерии выхода (Exit Criteria): условия, которые должны быть выполнены для завершения конкретной фазы STLC и перехода к следующей. Например, для завершения фазы написания тестовых случаев может потребоваться написание и утверждение определённого количества тестовых кейсов.

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

Что такое Bug, Error, Failure, Fault?

В контексте тестирования программного обеспечения:

1. Bug (Ошибка): Это дефект или несоответствие, найденное в программном коде или функциональности. Ошибка возникает в результате ошибки разработки или неправильного функционирования программы.

2. Error: действие человека, которое приводит к неправильному результату, например неверное понимание требования или ошибка в коде.

3. Failure (Отказ): Это некорректное поведение программы или системы, которое происходит в результате ошибки или дефекта. Отказ проявляется как недостаток в функциональности или как неспособность приложения выполнить ожидаемые задачи.

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

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

Какие есть атрибуты баг-репорта? Какие основные поля для заполнения?

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

1. Заголовок: Краткое описание проблемы или дефекта.

2. Описание: Подробное описание того, что происходит или что ожидается.

3. Шаги воспроизведения: Последовательность действий, необходимых для воспроизведения проблемы.

4. Ожидаемое поведение: Четкое описание ожидаемого поведения приложения или системы.

5. Фактическое поведение: Описание того, что происходит на самом деле, включая ошибки или некорректное поведение.

6. Приоритет и серьезность: Оценка важности и влияния дефекта на работу системы.

7. Среда и версия: Информация о среде, в которой возникает проблема (например, операционная система, браузер, версия ПО).

8. Приложенные файлы и скриншоты: Дополнительные материалы, такие как скриншоты или логи, помогающие воспроизвести и понять проблему.

9. Ответственный разработчик: Информация о том, кому назначен баг-репорт для исправления.

10. Статус и обновления: Текущее состояние и последние обновления по проблеме.

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

Какова разница между приоритетом и серьезностью?

В контексте управления дефектами:

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

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

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

Приведите примеры серьезного, но не приоритетного бага.

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

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

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

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

В чем разница между валидацией и верификацией?

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

1. Верификация: Это процесс проверки того, что продукт разрабатывается согласно заданным спецификациям и требованиям. Верификация отвечает на вопрос “Мы делаем правильно?”.

2. Валидация: Это процесс проверки того, что разрабатываемый продукт соответствует потребностям и ожиданиям пользователя или заказчика. Валидация отвечает на вопрос “Мы делаем правильный продукт?”.

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

Какие доказательства приложить к багу backend?

К багу backend прикладывают точное время с часовым поясом, среду и версию, минимальный запрос: метод, URL, безопасные заголовки и тело. Нужны статус, ответ, latency, trace или correlation ID и релевантный фрагмент серверного лога. Если важны данные, показывают до и после через запрос или SQL-снимок и указывают транзакцию. Секреты, токены и персональные данные удаляют либо маскируют одинаковым способом. Полезны частота и условие воспроизведения. Большой архив всех логов хуже короткой связанной цепочки, по которой разработчик найдёт запрос во всех сервисах.

Каким должно быть поведение системы в негативном сценарии?

Отказ должен быть предсказуемым: система возвращает документированную ошибку без stack trace, секретов и лишних сведений о чужих объектах. Невалидная операция не должна частично менять данные; если часть работы уже выполнена, контракт обязан описывать компенсацию или статус для восстановления. Сервис остаётся доступным для следующих запросов, не создаёт дубли при безопасном retry и пишет достаточно данных для диагностики. Пользователь получает понятный следующий шаг, если восстановление возможно. Проверяют не только код ответа, но и состояние БД, события, файлы и внешние эффекты после ошибки.