Тестируя требования (документацию) и анализируя первопричины багов (Root Cause Analysis).

С помощью код-ревью (Code Review) и ретроспективных встреч (Retrospective meetings).

Обрадуюсь, какой я молодец!

Оформлю баг-репорт.

Выжду удобный момент, чтоб не расстраивать разработчиков и потом сообщу о баге.

Жизненный цикл ошибки включает следующие этапы: new (новый), assigned/in progress (назначен/в процессе), fixed (исправлен), tested (протестирован), resolved (завершен), closed (закрыт).

Жизненный цикл ошибки состоит из трех основных этапов: new (выявлен), fixed (исправлен) и closed (закрыт).

Жизненный цикл ошибки включает new (выявлен) и closed (закрыт). Не нужно усложнять.

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

Проверю документацию с требованиями к приложению.

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

Для создания тест кейсов.

Для подробного описания бага.

Окружение для воспроизведения бага не указано.

Не указаны данные, которые вводились для отправки формы.

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

Я пишу тест-кейсы на основе кода команды разработчиков. Это самый надежный источник.

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

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

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

Да.

Нет.

Тест-кейсы нужно написать один раз, а затем корректировать в зависимости от результатов первого теста.

Smoke testing - это широкий набор тестов, охватывающих самые критически важные функции приложения, которые обычно выполняются после получения новой сборки, чтобы убедиться, что функции работают. Sanity testing - это узкий набор тестов, направленных на проверку конкретных функций или исправленных ошибок в приложении, чтобы убедиться, что они работают должным образом после незначительных изменений.

Smoke testing фокусируется на проверке базовых и критических функций приложения, чтобы убедиться, что сборка достаточно стабильна для дальнейшего тестирования. Sanity testing проводится для проверки правильности недавно добавленных или измененных функций без углубленного тестирования.

Smoke testing - это комплексное тестирование, охватывающее все функции приложения, в то время как sanity testing - это быстрая проверка, выполняемая для

Тестирование с помощью таблицы решений (Decision Table Testing).

Разбиение на эквивалентные классы (Equivalence Partitioning).

Анализ граничных значений (Boundary Value Analysis).

Создам отчет об ошибке (bug report), указав как можно больше деталей, (включая предпринятые шаги, окружение и любую другую релевантную информацию). Попрошу сотрудничества у разработчиков и других членов команды для дальнейшего исследования.

Отложу исследование бага, если он воспроизводится от случая к случаю, значит не является срочной проблемой.

Буду тестировать приложение до тех пор, пока не найду шаги стабильного воспроизведения, (прежде чем регистрировать его в системе).

Немедленно сообщу об ошибке командам разработки и управления продуктом, предоставив баг репорт.

Релиз уже завершен, подожду следующего релиз, чтобы инициировать его исправление.

Попробую исправить баг самостоятельно, прежде чем уведомить команду.

Отмечу тест-кейс как пройденный, так как приложение работает как ожидается.

Я исследую и обновлю тест-кейс, если необходимо, и повторю его выполнение.

Проигнорирую неудачный тест-кейс, в данном случае он не влияет на общий процесс тестирования.

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

Проведу исследование, попытаюсь повторить шаги пользователя в той же среде, что и у него.

Функция тщательно протестирована, значит пользователь неправильно ее использует, нужно вежливо отправить его читать руководство пользователя.

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

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

Задокументирую проблему, сообщать о ней дополнительно нет необходимости. Регрессионные баги просто помещаются в баг-трекинговую систему, Product Manager потом сам ее посмотрит и выберет время для фикса.

Немедленно прекрачу свое тестирование и приоритизирую проверку исправления бага.

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

Работа разработчика не была запланирована, значит я сосредоточусь только на

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

Задокументирую текущие проблемы, вызванные недоступностью стороннего сервиса, сообщу об этом своей команде и продолжу тестирование других независимых функций.

Сбои, связанные со сторонним сервисом, - это независящие от меня обстоятельства, помечу мои тесты как пройденные. Работа выполнена настолько на сколько это возможно.

Ситуация, в которой дефект проявляется периодически и трудно воспроизводится.

Дефект был обнаружен и исправлен во время фазы тестирования.

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

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

Я буду использовать автотесты для покрытия всех сценариев, поскольку они стабильны и надежны.

Я буду стараться создавать и выполнять как можно больше разнообразных тестовых сценариев, чтобы обеспечить максимальное покрытие тестами.

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

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

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