"Регрессионное тестирование" - это плохо. Смотри статью "Идеальный тестовый набор".
Не все так однозначно. :) Смотрите комментарий выше.
А вот это ОЧЕНЬ плохо. Это вариации. О которых Деминг писал, что их надо всячески избегать. Ну, или если хотите бытовую аналогию: "Замыленный взгляд".
Если сборка готова во второй половине дня и к вечеру надо понять, есть ли блокеры, то тестировщик, который не знаком с фичей/продуктом, вряд ли принесет много пользы.
Должны либо быть очень подробные тест-кейсы, либо очень опытный специалист, который находит проблемы налету. Иначе будет куча вопросов, как и что должно работать, что важно проверять. Если времени очень мало, то нормально протестировать сможет, скорее всего, только хорошо знакомый с фичей/продуктом тестировщик, потому что он знает, как все устроено и где есть слабые места, где часто все «отваливается». Эксперименты хороши, когда есть время, а не когда «Надо срочно релизить, проверьте все».
Отошлю к блогу Влада Балина. Статьи про неуловимого Джо.
И ссылка бы тут не помешала.
И через час после продакшена ваша компания разорилась. Реальные истории знаю.
В целом: иногда да, иногда нет. Зависит от проекта. Правильнее будет: "В зависимости от проекта выбираем позитивные или негативные".
Тут согласна. Все зависит от проекта и продукта, который тестируется. Только часто вижу ситуацию, когда тестируется все подряд; особенно новички грешат тем, что сначала пытаются сломать, а о самых базовых и простых кейсах забывают.
Промолчу. Тут не на комментарий, не на статью, а на книгу. Или цикл книг.
Книги в студию. :)
И многие компании для выживания специально урезают время на тестирование. Потому что от этого выигрывают все. В том числе и пользователи.
Я думаю, если в команде специалисты не очень опытные и не находят баги одним взглядом на продукт или требования, то в спешке однозначно будет что-то критичное упущено. Чудес не бывает.
Вне зависимости от качества, релиз все равно завтра.
Увы, да, так часто бывает.