- Понимание и декомпозиция всех этапов: Мы разбиваем весь процесс тестирования на отдельные задачи, такие как работа с требованиями, первичное тестирование, создание баг-репортов, ретесты после исправлений и т.д.
- Оценка времени на каждый этап: Для каждой задачи мы оцениваем, сколько времени потребуется на её выполнение. Например, для первичного тестирования одной фичи может понадобиться 5 часов, а на ретест после исправления багов — 2 часа. Здесь важно отметить, что сложно дать точную оценку времени на ретест, так как это зависит от времени, необходимого разработчикам чтобы пофиксить баги. Мы проводим синки с командой для обсуждения оценок и их корректировки при необходимости, те же самые дэйли встречи, где обсуждаем проблемные ситуации.
- Учёт непредвиденных задержек: Закладываем дополнительное время (например, 10-20% от общей оценки) на случай непредвиденных проблем и задержек в момент ретеста. В определённых случаях мы округляем оценки в большую сторону. Например, если ретест какого-то бага может занять буквально 2-3 минуты, мы добавляем буфер и округляем до 0.5 часа. Но этим не стоит злоупотреблять, всё зависит от условий.
- Адаптация плана в процессе: Если возникают новые баги, или требуется больше времени на исправление, мы корректируем наш план и перераспределяем ресурсы для ускорения и улучшения процесса стабилизации.
- Анализ ситуации: Регулярно анализируем производительность команды и корректируем оценки на основе текущих данных. Если определённые задачи ранее потребовали больше/меньше времени на ретест и стабилизацию, мы сохраняем эту информацию для истории и используем её для корректировки оценок на текущие и будущие подобные задачи в процессе планирования.
- Коммуникация с командой: Периодически сообщаем всем заинтересованным сторонам о текущем состоянии тестирования и исправления багов, поддерживаем обратную связь и при необходимости корректируем оценки.
Мой личный совет: всегда держите команду в курсе ваших затруднений, если вы не успеваете по оцененному времени. Таким образом, можно совместно корректировать ситуацию.
Мы как раз когда декомпозируем, закладываем часть времени на стабилизацию и ретесты после исправления багов. В итоге да, это наверно сложный пункт, чтобы оценить точно, но его тоже стараемся под какой-то цифрой в часах давать, опять же чтобы понимать свое планирование!
К сожалению, если не оценивать, то и результаты не получить объективные, с которыми можно работать. Здесь важны цифры, с которыми уже можно в какой-то степени работать, анализировать, что могло пойти не так и наоборот. Оценка и нужна для понимания своих действий, мониторинга и коммуникации. Точных оценок не получить всегда, согласен, есть свои трудности. Опять же, если у вас есть конкретный пример, возможно следует его анализировать и попробовать в след. раз как раз подойти к оценке более адекватно, затрагивая все зависимости, сложности, почему у вас не получилось попасть в рамки.
Если говорить о заказной разработке, то клиент не любит платить за максимальные оценки, которые зачастую подразумевают под собой увеличение времени на разработку, соответственно бюджет на все активности вырастет. Все же бизнесу хотелось бы побыстрее и подешевле. Да и максимальные оценки могут создать у клиента ожидания, что проект будет завершен позже, чем это реально возможно. Если команда завершит проект раньше, это может вызвать вопросы о завышенных оценках, что тоже может выстрелить неудачно такой случай.
Конечно, в некоторых ситуациях можно использовать максимальные оценки и работать в рамках бюджетов, но это подход тоже имеет свои риски и недостатки. Более точные оценки помогают лучше управлять проектом и достигать баланса между качеством, стоимостью и сроками.
Но опять же, если у вас есть конкретные случаи или задачи, в качестве примера, было бы интересно посмотреть, обсудить :)
Даниил, правильно ли я понимаю, что у вас тестирование тут по большей части завязано на проверке каких-то определенных юз-кейсов? Мне любопытно, насколько у вас много вообще тест-кейсов, или остальной тестовой документации, когда идет специфика ботов в диалоговых системах. Как вы с тестовыми артефактами тут работаете? :)
Согласен! В любом случае, результаты оценки помогают команде лучше планировать свою работу и более эффективно достигать целей проекта/спринта. Поэтому выбор методики должен соответствовать потребностям и команде.
Да, использование только одного числа не дает полного представления о возможных вариациях в оценке времени или ресурсов. И ваше предложение использовать три числа для планирования задач тоже вполне адекватно, для более гибкого планирования. Но сводя в одно просто помогает упростить коммуникацию (легче воспринимать оценку через одну цифру, чем через 3) и проще проводить анализ результатов (для сравнения и создания трендов).
Проблема с расчетом среднего значения:
И да, расчет среднего значения может быть трудным, особенно когда оптимистичная и пессимистичная оценки сильно различаются. Однако, трехточечная оценка обычно включает в себя взвешенное среднее, где наиболее вероятное значение учитывается с большим весом, то есть этот метод как раз помогает сгладить влияние крайних значений. Эти средние значения действительно могут вводить в заблуждение. Однако, трехточечная оценка не предполагает использование только среднего значения, а позволяет видеть диапазон и распределение вероятностей.
Опять же, это одна из техник, которая может подходить под контекст задачи, а может действительно сделать оценку труднее.
Каждая задача требует тщательного анализа перед оценкой. Мне зачастую сложно бывает оценить простейший баг-фикс, просто потому что могут какие-то непредвиденные обстоятельства вылезти. В целом, этот процесс только улучшается с опытом, поэтому чем чаще мы оцениваем, тем лучше и точнее получается на мой взгляд. Но тут да, стоит придерживаться советов, как избегать трудности, которые я упомянул в статье.
Нет, не обязательно. На самом деле, эксперт тут, это просто человек, который мог работать раньше с подобной задачей (или такой же). Или например, у вас есть задача на интеграцию, где есть человек, который знает, как работает эта интеграция. Можете привлечь его для дополнительных советов.
Сам не раз сталкивался с ситуацией, когда оценил задачу в 2 часа, а потребовалось 8… Но это тоже опыт и это тоже исторические данные, которые в итоге помогут нам в оценках далее. Согласен, что по приоритетам тоже можно и стоит давать оценку, но опять же, если видеть конкретный результат в цифрах, можно оценить, достигли мы успеха или это провал. Опять же на основе результата, делаем дальнейшее планирование.
Естественно мы не просто "встречаем" баги, в этом как раз и суть адекватного отслеживания контроля качества и использования инструментов, которые я перечислил в статье. У нас ведь как раз есть конкретная цель поиска отклонений в зависимости от модели и ОС. В данном случае, ни один из багов не будет абстрактным.
Оставить по одному девайсу у тестировщика можно, но например если у всех тестеров будет одни и те же девайсы с неизменной ОС, это менее продуктивно для нас. Даже в таком случае, оставьте у тестера по одному девайсу, но сделайте это максимально эффективно, опираясь то, как широко можно покрыть наше тестирование в зависимости от моделей и ос.
Мы все же используем и предлагаем возможности комбинации, так как определенный пул девайсов (как реальных, так и симуляторов) позволяет покрывать конкретные проверки и ничем нам конкретно не замедляет тестирование. Наоборот кое-где заранее ускоряет выявлять определенные сценарии и эдж-кейсы. Опять же, все зависит от специфики проекта. Но спасибо за совет :)
Баги в любом случае встречаем да, в соответствии с комбинациями. Что касается оценки разных версий ОС и моделей, то саму запись данных не ведём, но изменения видим. В большинстве своем это те самые вырезы на экранах, динамичная верстка, определенные краши и прочее. И да, эту встряску девайсов мы дополнительно стараемся покрыть симуляторами, чтобы не раздувать бюджет на реальные устройства, тут вы правы, что нет смысла увеличивать в разы стоимость тестирования, если учитывать статистику и продуктовую аналитику.
В нашем случае, мы стараемся на старте проекта покрыть статистику по девайсам, но потом уже приходим к продуктовой аналитике и стараемся работать с устройствами, которые реально используют пользователи.
Ох, давайте попробуем собрать мысли :)
- Понимание и декомпозиция всех этапов: Мы разбиваем весь процесс тестирования на отдельные задачи, такие как работа с требованиями, первичное тестирование, создание баг-репортов, ретесты после исправлений и т.д.
- Оценка времени на каждый этап: Для каждой задачи мы оцениваем, сколько времени потребуется на её выполнение. Например, для первичного тестирования одной фичи может понадобиться 5 часов, а на ретест после исправления багов — 2 часа. Здесь важно отметить, что сложно дать точную оценку времени на ретест, так как это зависит от времени, необходимого разработчикам чтобы пофиксить баги. Мы проводим синки с командой для обсуждения оценок и их корректировки при необходимости, те же самые дэйли встречи, где обсуждаем проблемные ситуации.
- Учёт непредвиденных задержек: Закладываем дополнительное время (например, 10-20% от общей оценки) на случай непредвиденных проблем и задержек в момент ретеста. В определённых случаях мы округляем оценки в большую сторону. Например, если ретест какого-то бага может занять буквально 2-3 минуты, мы добавляем буфер и округляем до 0.5 часа. Но этим не стоит злоупотреблять, всё зависит от условий.
- Адаптация плана в процессе: Если возникают новые баги, или требуется больше времени на исправление, мы корректируем наш план и перераспределяем ресурсы для ускорения и улучшения процесса стабилизации.
- Анализ ситуации: Регулярно анализируем производительность команды и корректируем оценки на основе текущих данных. Если определённые задачи ранее потребовали больше/меньше времени на ретест и стабилизацию, мы сохраняем эту информацию для истории и используем её для корректировки оценок на текущие и будущие подобные задачи в процессе планирования.
- Коммуникация с командой: Периодически сообщаем всем заинтересованным сторонам о текущем состоянии тестирования и исправления багов, поддерживаем обратную связь и при необходимости корректируем оценки.
Мой личный совет: всегда держите команду в курсе ваших затруднений, если вы не успеваете по оцененному времени. Таким образом, можно совместно корректировать ситуацию.
Мы как раз когда декомпозируем, закладываем часть времени на стабилизацию и ретесты после исправления багов. В итоге да, это наверно сложный пункт, чтобы оценить точно, но его тоже стараемся под какой-то цифрой в часах давать, опять же чтобы понимать свое планирование!
К сожалению, если не оценивать, то и результаты не получить объективные, с которыми можно работать. Здесь важны цифры, с которыми уже можно в какой-то степени работать, анализировать, что могло пойти не так и наоборот. Оценка и нужна для понимания своих действий, мониторинга и коммуникации. Точных оценок не получить всегда, согласен, есть свои трудности. Опять же, если у вас есть конкретный пример, возможно следует его анализировать и попробовать в след. раз как раз подойти к оценке более адекватно, затрагивая все зависимости, сложности, почему у вас не получилось попасть в рамки.
Если говорить о заказной разработке, то клиент не любит платить за максимальные оценки, которые зачастую подразумевают под собой увеличение времени на разработку, соответственно бюджет на все активности вырастет. Все же бизнесу хотелось бы побыстрее и подешевле. Да и максимальные оценки могут создать у клиента ожидания, что проект будет завершен позже, чем это реально возможно. Если команда завершит проект раньше, это может вызвать вопросы о завышенных оценках, что тоже может выстрелить неудачно такой случай.
Конечно, в некоторых ситуациях можно использовать максимальные оценки и работать в рамках бюджетов, но это подход тоже имеет свои риски и недостатки. Более точные оценки помогают лучше управлять проектом и достигать баланса между качеством, стоимостью и сроками.
Но опять же, если у вас есть конкретные случаи или задачи, в качестве примера, было бы интересно посмотреть, обсудить :)
Даниил, правильно ли я понимаю, что у вас тестирование тут по большей части завязано на проверке каких-то определенных юз-кейсов? Мне любопытно, насколько у вас много вообще тест-кейсов, или остальной тестовой документации, когда идет специфика ботов в диалоговых системах. Как вы с тестовыми артефактами тут работаете? :)
Да, у нас тоже бывало оценишь в 3 часа, выйдет 3 дня. К сожалению, без ошибок тоже никак, потом просто на заметку берём :)
Но такие ситуации действительно нервишки дёргают.
Замкнутый круг :)
Согласен!
В любом случае, результаты оценки помогают команде лучше планировать свою работу и более эффективно достигать целей проекта/спринта. Поэтому выбор методики должен соответствовать потребностям и команде.
Сил тебе <3
О да, такие случаи тоже бывают! Техника в целом не самая моя любимая именно поэтому, тут надо осторожно привлекать экспертов :)
Почему не использовать три числа вместо одного?
Да, использование только одного числа не дает полного представления о возможных вариациях в оценке времени или ресурсов. И ваше предложение использовать три числа для планирования задач тоже вполне адекватно, для более гибкого планирования. Но сводя в одно просто помогает упростить коммуникацию (легче воспринимать оценку через одну цифру, чем через 3) и проще проводить анализ результатов (для сравнения и создания трендов).
Проблема с расчетом среднего значения:
И да, расчет среднего значения может быть трудным, особенно когда оптимистичная и пессимистичная оценки сильно различаются. Однако, трехточечная оценка обычно включает в себя взвешенное среднее, где наиболее вероятное значение учитывается с большим весом, то есть этот метод как раз помогает сгладить влияние крайних значений.
Эти средние значения действительно могут вводить в заблуждение. Однако, трехточечная оценка не предполагает использование только среднего значения, а позволяет видеть диапазон и распределение вероятностей.
Опять же, это одна из техник, которая может подходить под контекст задачи, а может действительно сделать оценку труднее.
Каждая задача требует тщательного анализа перед оценкой. Мне зачастую сложно бывает оценить простейший баг-фикс, просто потому что могут какие-то непредвиденные обстоятельства вылезти. В целом, этот процесс только улучшается с опытом, поэтому чем чаще мы оцениваем, тем лучше и точнее получается на мой взгляд. Но тут да, стоит придерживаться советов, как избегать трудности, которые я упомянул в статье.
Нет, не обязательно. На самом деле, эксперт тут, это просто человек, который мог работать раньше с подобной задачей (или такой же). Или например, у вас есть задача на интеграцию, где есть человек, который знает, как работает эта интеграция. Можете привлечь его для дополнительных советов.
Сам не раз сталкивался с ситуацией, когда оценил задачу в 2 часа, а потребовалось 8… Но это тоже опыт и это тоже исторические данные, которые в итоге помогут нам в оценках далее. Согласен, что по приоритетам тоже можно и стоит давать оценку, но опять же, если видеть конкретный результат в цифрах, можно оценить, достигли мы успеха или это провал. Опять же на основе результата, делаем дальнейшее планирование.
Да, это тоже очень хороший метод оценки, в частности на старте проекта. Спасибо :)
Да это просто шутка, я понимаю суть SNES порта :)
Ну чтож, где только Doom не запускали уже. Раз такие новости, жду запуска Doom на салфетке :)
Естественно мы не просто "встречаем" баги, в этом как раз и суть адекватного отслеживания контроля качества и использования инструментов, которые я перечислил в статье. У нас ведь как раз есть конкретная цель поиска отклонений в зависимости от модели и ОС. В данном случае, ни один из багов не будет абстрактным.
Оставить по одному девайсу у тестировщика можно, но например если у всех тестеров будет одни и те же девайсы с неизменной ОС, это менее продуктивно для нас. Даже в таком случае, оставьте у тестера по одному девайсу, но сделайте это максимально эффективно, опираясь то, как широко можно покрыть наше тестирование в зависимости от моделей и ос.
Мы все же используем и предлагаем возможности комбинации, так как определенный пул девайсов (как реальных, так и симуляторов) позволяет покрывать конкретные проверки и ничем нам конкретно не замедляет тестирование. Наоборот кое-где заранее ускоряет выявлять определенные сценарии и эдж-кейсы. Опять же, все зависит от специфики проекта. Но спасибо за совет :)
Баги в любом случае встречаем да, в соответствии с комбинациями. Что касается оценки разных версий ОС и моделей, то саму запись данных не ведём, но изменения видим. В большинстве своем это те самые вырезы на экранах, динамичная верстка, определенные краши и прочее. И да, эту встряску девайсов мы дополнительно стараемся покрыть симуляторами, чтобы не раздувать бюджет на реальные устройства, тут вы правы, что нет смысла увеличивать в разы стоимость тестирования, если учитывать статистику и продуктовую аналитику.
В нашем случае, мы стараемся на старте проекта покрыть статистику по девайсам, но потом уже приходим к продуктовой аналитике и стараемся работать с устройствами, которые реально используют пользователи.
Про продуктовую аналитику тоже полностью поддерживаю. У нас этот кейс также работает, обновляем наши данные:
https://habr.com/ru/articles/821209/comments/#comment_26925863