А как помогут  3 теста это выяснить?

код ревью, регрессионое тестирование, код анализ, tdd, выбор архитектуры и отказ от фреймворков (где не нужно) - это все QA.

Нет связи, причём тут регрессионное, любой юнит тест - регрессия

Какие 3 теста и почему 3?

А сколько надо, 50?

и на качество тестирование оказывает МЕНЬШЕЕ значение, чем например как ты разрабатываешь

Я и не отрицаю

по канонам тестирования черного ящика - 52 теста минимум

но эти каноны - ерунда)

Я же не в тестировании не разбираюсь, вот у знатоков спрашиваю

Есть требование - сделать 4 роли, а проггер сделал 3 - зачем тесты писать, посмотрел в код, навялял, подправили, забыли

а если заниматься парным tdd то такая ситуация переходит в разряд невозможных

Не надо писать тест: разраб должен имплеметировать метод так-то и так-то

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

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

Если фича - "сделать доступ по ролям, которые определяются в зависимости от" - то как выше.

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

Но ваш вопрос некорректен изначально. небывает достаточного тестирования. точка. Открываем ГОСТ, ISO, ISTQB и там об этом прямым текстом написано. Это научно обоснованный факт, могу скинуть ссылочки на научную базу.

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

в АБСОЛЮТНОМ большинстве случаев системные тесты черного ящика нецелесообразны экономически

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

Правило простое- любой программист, и не только автор должен точно знать что делает метод, без того чтобы смотреть внутрь кода метода. Если метод такой - он хороший, если чтобы узнать что метод делает, необходимо залезать внутрь и найти там именно role1,2,3 - то скорее всего метод неудачно назван или описан.

Вот требования - https://t.me/qa_automation/177788
Подходят под вариант "добавить эти самые три роли и чтобы только они могли”, не?

Ну только одну роль