Сейчас у нас куа подключают на этапе, когда все уже обо всем договорились и есть однозначная аналитика. Типа вот вам все, разрабатывайте и пишите кейсы. Но есть ощущение, что надо бы включаться пораньше, когда идет обсуждение системной аналитики хотя бы, чтобы к моменту выхода в разработку уже иметь представление о том что имеем и об узких местах.
-- Завели даже термин "тестирование требований" -- какие есть вопросы, чего может не хватать
-- Была пара команд где аналитика не было, а команда "оценивала" предложение на разработку. Просматривал это я, находя проблемные места, в результате команда могла вообще отказаться от проекта. Иногда в том "чего хотят" можно сразу увидеть проблемы.
-- Если аналитик или ПМ или кто пишет спецификацию на проекте недавно, или пишет под участок который не очень хорошо знает, "нужен глаз да глаз" чтобы вовремя сказать "это так не работает". Один новый продакт менеджер смотрел на меня с недоверием когда я говорил что на спецификацию в конфлюэнсе я могу написать ~40 замечаний, но он понял как это когда на его "первый блин" я написал ~30.
-- Иногда проблемы могут появиться по поводу разработки, а ты знаешь как этого избежать, -- если включился пораньше, а не на собранное ближе к концу. Пример: разработчик решил что он "знает как надо" и стал пилить графику сам. Но графика у разработчика получается грубая и некрасивая. Чтобы такой проблемы не возникло надо свести разработчика с дизайнерами и договориться (как бы это должен делать ПМ, но не всегда сделает). От подобных вещей (в том числе) зависит зарелизится ли фича вовремя, или, от количества и качества найденных проблем, займёт ещё спринт.
-- Я не раз сталкивался с тем что аналитики и тестировщики видят требования несколько по-разному.
Аналитик: зашёл на страницу сущности, что-то изменил, появилась кнопка сохранения. Всё просто.
Тестировщик: зайти на страницу сущности можно четырьмя способами, изменить можно A, B, C и D. Ооооо, это подольше тестировать.
И что ещё будет если я изменил а потом опять поставил как было?
-- Бывают ситуации когда тестировщик а) работал по разным командам или задачам, б) общался-общается с другими тестировщиками, и знает больше чем команда: 1) какой может быть импакт (что новый функционал может зацепить) 2) какие фичи разрабатывает другая команда, и как они могут пересекаться с новыми для этой команды (соответственно тестирование может занять больше времени). 3) или наоборот, чего "мы от другой команды не получим"
