Как персонал QA должен точно производить оценки?

Question

В моей последней работе я работал с компанией, которая собиралась из методологии NO, использовать метод Scrum/Agile. Было встречено много проблем, в том числе тот факт, что эксперт Scrum действительно не знал, как эффективно реализовать Scrum.

План, который они использовали, был относительно прост:
1. Начать Спринт Планирование совещаний, где оценка времени ОК и Дева была одной оценкой - не одна для времени ОК и одна для времени Dev.
2. Когда оценка времени достигла общего значения для Sprint, в этот спринт не было добавлено больше функций.

Основная проблема заключалась в том, что QA вообще не знает, КАК разработчик собирается писать код ... ведь они не кодеры! Таким образом, команды QA действительно не имели оснований для формирования достойной оценки времени. И наоборот, 99,9% разработчиков не знают разницы между проверкой работоспособности, тестированием функциональности, регрессионным тестированием и тестированием UAT .... поэтому они не могли точно оценить, какое время QA необходимо для определенных функций.

В конечном счете я взял пулю для своей команды QA и принял это решение для руководства, где меня немедленно уволили за то, что я не мог работать в среде Scrum, но это действительно ни здесь, ни там.

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

Answer 1

Я полагаю, вы разговариваете друг с другом и разрабатываете бюджет времени между двумя командами, которые затем отправляете в mgmt.

Answer 2

Это не отвечает на ваш вопрос, но, на мой взгляд, персонал QA должен иметь возможность делать все с помощью кода, который может быть выполнен без разработки IDE. Понимание дизайна, бизнес-логики, как закрыть петли, проектные тесты и т. Д. - может быть выполнено людьми с QA.

Answer 3

То, что я нашел, чтобы хорошо работать, - это смещение циклов dev/test. Таким образом, вы кодируете одну итерацию, а затем QA в следующем. Это дает команде QA время, чтобы должным образом охватить работу, а не основывать их оценку на оценке разработчиков.

Answer 4

Я был в обоих QA и Dev. Этот процесс на самом деле не так уж и отличается в любом мире, потому что он сводится к простой вещи: все оценки - догадки. Они основаны на опыте, суждениях и оценке сложности и риска определенного набора проблем, но в лучшем случае это хорошие догадки.

Вы можете сделать их более полезными, проанализировав множество известных задач вокруг определенных областей функций. В QA это означает, что вы рассматриваете проблему по имеющимся у вас углам: анализируете вариации в любой возможной истории пользователя, анализируете возможные входы, если у вас есть макет экрана и т. Д. Сделайте некоторую базовую арифметику, основанную на лучших предположениях о том, сколько времени требуется для ручного или автоматического запуска этих вариантов. Сделайте небольшую 2-мерную матрицу, которая отображает некоторые ключевые сценарии, основанные на грубых классах эквивалентности, выясните, сколько времени было бы: а) писать тесты автоматизации для каждого элемента на основе предыдущего опыта и б) запускать ручные тесты дыма, если это необходимо ,

Укажите, как часто вам нужно будет выполнять эти тесты в течение запланированной временной шкалы. Запустите множитель на основе вероятности ошибки (1.5x, 2.0x, иногда 3.0x) в вашем суждении и относительной важности правильной работы. Если действительно важно, чтобы одна из функций была хорошо протестирована и менее важна, чтобы другая функция была хорошо протестирована, соответствующим образом скорректируйте свои оценки, но определите это предположение в своей оценке.

Планирование - это управление риском, а не устранение его. Это должно дать вам представление о том, что нужно сделать. Детали никогда не совсем правильные, и все в порядке. Я не могу придумать один раз в проекте, над которым я работал, что все идет по плану, особенно на стороне разработчиков.

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

Интересно, если в вашем случае команда разработчиков делала оценки времени отклика от вашего имени? Как правило, это не очень хорошая идея, чтобы позволить кому-то еще позвонить. Люди с самой кожей в игре должны иметь самое взвешенное мнение. Но многие разработчики могут очень хорошо оценивать риски, поэтому их, безусловно, стоит слушать. В Agile-циклах разработки исключительная роль должна быть в идеале меньше, чем в командах Waterfall, но я уверен, что некоторые люди просто лучше справляются с задачами QA, и они, естественно, отберут большую часть этой работы, даже в команде, которая пытается идеология Agile. Если ваша проблема заключалась в том, что вы не хотели делать оценки, не зная деталей реализации, я могу сказать, что это то, что вам нужно будет преодолеть; даже в методологиях старой школы, я редко имел роскошь полных знаний.

Я бы добавил следующее: Люди с талантом QA должны быть в тех же командах, что и их партнеры по развитию. Это нормально, если их профессиональное развитие управляется другим менеджером, но не в порядке, если они являются частью различных команд спринта. Поэтому, если у вас есть «спринт с тестовой командой» и «спринт команды разработчиков», по моему скромному мнению, вы наносите ущерб сотрудничеству и обмену данными между ресурсами Dev и QA.