1️⃣Почему сначала проводится позитивное тестирование, а не негативное?
Мы должны убедится, что ПО выполняет все задуманные функции корректно, и дать добро, что сервис полностью исправен. После того как мы убедились в работе ПО, мы можем «сломать» его.2️⃣Чем отличается модульное тестирование от компонентного?
Это одно и тоже, только разный перевод) Это первый уровень тестирования.Подробнее
3️⃣Был ли опыт, когда ты не разрешал выпускать фичу из-за выявленных провалов в аналитике?
Да, в команде я не только сравнивал ОР и ФР, я еще и влиял на продукт и на его удобство использования. Я могу уведомить об ошибках на этапе аналитики, анализа спецификаций или уже на этапе тестирования.4️⃣Работал ли при отсутствии требований, как ты минимизировал данную проблему?
Я
знаю как запустить процесс восстановления спецификаций. Знаю какие роли в команде пишут доку и осталось просто наладить процессы в команде. Владелец продукта отвечает за бизнес цели продукта и является связующим звеном между заказчиком и ИТ командой, аналитик пишет технические требования для команды разработки.Статья как работать без требований
5️⃣Работал в команде
единственным тестировщиком, назови
плюсы и минусы?
Да я работал, и выполнял не только тестирование, но и контроль качества (QC) и обеспечение качества продукта (QA)Плюсы и минусы читаем тут
6️⃣Как ты развиваешь технику тест-дизайна «Предугадывание ошибок»?
Предугадывание ошибок это навык, который развивается с опытом. Развиваю навык путем “перехвата” бага, до того как он попадет на PROD
7️⃣Тестировал ли удобство использования ПО? По каким требованиям тестируется удобство использования ПО?
Удобство использования формируется с практикой. Не всегда эти правила прописаны и продуманы на перед. Если правила не прописаны в требованиях, то мы опираемся на косвенные требования. Косвенные требования - это анализ ПО, которое сходится по функционалу с тестируемым. Проще говоря это анализ конкурента или приближенному к нему сервису для выявления лучшей практики.