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

Тестирование может оценить степень соответствия ожиданиям/требованиям к качеству/етк.
Повысить качество или уменьшить количество дефектов тестирование не может.

А мне как раз "минимально допустимых" и нравится. А тебе почему нет?)

То есть качественным будет считаться то, что не имеет критических/блокирующих багов на продакшене?

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

Потому что качество - не бинарная величина.
Типа перевалили за минимально допустимое - стали качественными, не дотянули - не качественные.
Это метрическая величина с довольно большой шкалой (и отрезком «минимального»/«необходимого»/«ожидаемого».

А можно подробнее? Я не много не могу понять:
Что мы путаем информацию и последствия? Или как?

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

Когда мы говорим "тестировщики влияют на качество", мы считаем, что и информация, и последствия - вотчина тестировщика. Хотя на самом деле он отвечает только за информацию.

Во-первых, у вас странное определение качества. Соответствие фактического результата ожидаемому вряд ли можно однозначно назвать качеством. И уж точно не стоит завязываться на документацию, потому что документация (сюрприз) тоже может иметь баги.
Мне в этом плане очень нравится определение качества из вики:
"Качество — совокупность минимально допустимых требований к продукции, обусловливающих её пригодность удовлетворять определённые потребности в соответствии с её назначением."

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

Ему даны права предупредить что здесь что-то не так, а что там мешает/не работает/критично/требует ли правки - это не его задача?

Ему даны права предупредить что здесь что-то не так, а что там мешает/не работает/критично/требует ли правки - это не его задача?

Его задача: предоставить информацию. О соответствии критериям качества, о проблемах, о рисках, о способах сделать лучше (если есть такие идеи) или снять боль с команды/пользователей.
Но ключевое слово: предоставить информацию.

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

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

Соответствие критериям качества != качеству ?

Очень понравилось про датчик дыма.  Надо запомнить)

Определение интересное, но я не уверен, что подходит для общего определения качества. Хотя, в рамках софта чего бы и нет :)

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

Соответствие критериям качества != качеству ?

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

Соответствие критериям качества = те показатели метрик, которые вы собрали считаются достаточными для выпуска релиза.