Ujilia

"Регрессионное тестирование" - это плохо. Смотри статью "Идеальный тестовый набор".

 

Не все так однозначно. :) Смотрите комментарий выше.

А вот это ОЧЕНЬ плохо. Это вариации. О которых Деминг писал, что их надо всячески избегать. Ну, или если хотите бытовую аналогию: "Замыленный взгляд".

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

 

Должны либо быть очень подробные тест-кейсы, либо очень опытный специалист, который находит проблемы налету. Иначе будет куча вопросов, как и что должно работать, что важно проверять. Если времени очень мало, то нормально протестировать сможет, скорее всего, только хорошо знакомый с фичей/продуктом тестировщик, потому что он знает, как все устроено и где есть слабые места, где часто все «отваливается». Эксперименты хороши, когда есть время, а не когда «Надо срочно релизить, проверьте все».

Отошлю к блогу Влада Балина. Статьи про неуловимого Джо.

 

И ссылка бы тут не помешала.

И через час после продакшена ваша компания разорилась. Реальные истории знаю.

В целом: иногда да, иногда нет. Зависит от проекта. Правильнее будет: "В зависимости от проекта выбираем позитивные или негативные".

 

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

Промолчу. Тут не на комментарий, не на статью, а на книгу. Или цикл книг.

 

Книги в студию. :)

И многие компании для выживания специально урезают время на тестирование. Потому что от этого выигрывают все. В том числе и пользователи.

 

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

Вне зависимости от качества, релиз все равно завтра.

 

Увы, да, так часто бывает. 

Хорошая статья. Впечатлило. Без шуток. Это очень хорошая статья человека, который в теме. Очень приличного уровня специалиста. Если по нашему рынку, то эксперт. Если по моей шкале - маг 3-4 уровня. И, да, это очень высокая оценка.

Спасибо за комментарий и такой «живой» интерес. :)

Если по моей шкале - маг 3-4 уровня.

 

А сколько на вашей шкале уровней, если не секрет?)

Приоритизация делается всегда. Есть время, нет времени - это абсолютно все равно. "Если вы не управляете событиями, они управляют вами."

Я с этим абсолютно согласна. :) В моих тестах всегда стоят приоритеты, я по-другому их просто не составляю. Но я очень часто встречаю обратную ситуацию, к сожалению.

Да сдчаз. Часто (не всегда) выбираются те, где более вероятна ошибка. И есть еще куча вариантов. Наиболее же востребованный для хорошей карьеры: "То, что может обнаружить HiPPO". Эту стратегию я еще на SQADays-18 рассказывал.

 

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