Я был в QA и Dev. Процесс на самом деле не сильно отличается в любом мире, потому что он сводится к простой вещи: все оценки являются догадками. Они основаны на опыте, догадках и оценке сложности и риска определенного набора проблем, но в лучшем случае они являются хорошими догадками.
Вы можете сделать их более полезными, проанализировав набор известных задач вокруг определенных функциональных областей. В QA это означает рассмотрение проблемы с имеющихся у вас углов: проанализируйте изменения в любой возможной пользовательской истории, проанализируйте возможные входные данные, если у вас есть макет экрана, и так далее. Сделайте некоторую основную арифметику, основанную на лучших предположениях о том, сколько времени потребуется, чтобы вручную или автоматически запустить эти варианты. Создайте небольшую двумерную матрицу, которая показывает некоторые из ключевых сценариев на основе классов грубой эквивалентности, выясните, сколько времени уйдет на а) написание тестов автоматизации для каждого элемента на основе предыдущего опыта и б) при необходимости проведение ручных дымовых тестов .
Выясните, как часто вам нужно запускать эти тесты в запланированные сроки. Запустите множитель, основываясь на вероятности ошибки (1,5х, 2,0х, иногда 3,0х) на вашем суждении и относительной важности правильного определения. Если действительно важно, чтобы одна функция была хорошо протестирована, и менее важно, чтобы другая функция была хорошо протестирована, скорректируйте свои оценки соответствующим образом, но определите это предположение в своей оценке.
Планирование - это управление риском, а не его устранение. Он призван дать вам общее представление о том, что необходимо сделать. Детали никогда не бывают правильными, и это нормально. Я не могу вспомнить один раз в проекте, над которым я работал, все шло по плану, особенно на стороне разработчика.
Agile не сильно меняет уравнение; это немного меняет график времени. Хорошая идея - убедиться, что есть небольшой запас для тестирования в конце цикла, несмотря на догму против него, потому что вам также нужно время для решения проблем, которые неизбежно возникнут. Но вам не нужно превращать это в «мини-водопад»; Разработчики могут продолжать работать в том маловероятном случае, когда все функции работают, потому что они всегда могут начинать выбирать задачи, которые имеют более низкий приоритет в итерации.
Интересно, а в вашем случае, команда разработчиков делала оценки времени QA от вашего имени? Обычно не очень хорошая идея позволять кому-то другому звонить по этому вопросу. Люди с наибольшим количеством скинов в игре должны иметь наиболее взвешенное мнение. Но многие разработчики могут сделать довольно хорошие оценки рисков, поэтому, безусловно, стоит их послушать. В Agile циклах разработки исключительная роль в идеале должна быть меньше, чем в командах Waterfall, но я совершенно уверен, что некоторые люди просто лучше справляются с задачами QA, и они, естественно, отбирают большую часть этой работы, даже в команде, которая пытается ходить по идеологии Agile. Если ваша проблема заключалась в том, что вы не хотели делать оценки, не зная деталей реализации, я могу сказать, что это то, что вам нужно преодолеть; даже в методологиях старой школы я редко мог позволить себе роскошь полного знания.
Я хотел бы добавить следующее: люди с талантом QA должны быть в тех же командах, что и их коллеги по разработке. Это нормально, если их профессиональное развитие управляется другим менеджером, но не хорошо, если они являются частью разных спринтерских команд. Так что, если у вас есть «спринт команды тестирования» и «спринт команды разработчиков», по моему скромному мнению, вы наносите ущерб потенциалу для сотрудничества и общения между ресурсами Dev и QA.