Pull to refresh

Comments 4

Это вы рассчитываете трудозатраты на автоматизацию одного пользовательского/тестового сценария? Или на какую целевую величину? «Задача» это как бы немного размыто.

Вы говорили про Скрам и Канбан, значит вы работаете с пользовательскими сценариями, я так понимаю. А ведь проверочные сценарии сперва нужно продумать. Или вы их напрямую берете из приемочных критериев? Но не получится ли тогда так, что плохо прописали приемочные критерии — получили недостаточное покрытие в автоматизации? Задача выполнена на 100 процентов, баги прилетают все равно. Менеджеры негодуют.

И не приведет ли подобная методика точной оценки к тому, что написание автоматизации тестирования будет заканчивается, когда заканчивается выделенное на него время?

А как вы учитываете доработку тестовых скриптов? Ведь они начинают со временем сыпаться.

У меня такое «опасение», что по началу менеджеры будут в восторге, но со временем «неучтенка» станет накапливаться, и придется или ее сметать под коврик увеличивая давление на разработчиков/автоматизаторов, или идти «с повинной» к начальникам.
lxsmkv спасибо, за комментарий, отвечу по порядку:
1) Здесь идет речь о первичной оценке по новому проекту с ТЗ. Но для объемных кейсов на конкретные модули тоже думаю подойдет.
2) В качестве тестовых сценариев мы используем описание из ПМИ. В нем максимально подробно описаны все возможные действия, которые может выполнить пользователь с определенной ролью.
3) Про доработку и выделенное время: планирование работ идет из того, что у нас есть в ТЗ, соответственно, если у нас происходят изменения в ТЗ — меняем в оценке временных затрат. Так же стоит понимать, что во время различного цикла жизни ПО, разная интенсивность изменения в коде. Сами по себе тесты не падают :), они лишь характеризуют, что изменилось поведение в системе, а это значит и нам нужно изменить свой тест. По временным оценкам доработка теста в большинстве своем совпадает с оценкой «повторное использование», так что можно следовать пункту 2)
Ух ты, ну если у вас в проекте детальная спецификация пристутствует и даже ПМИ (Программа и методика испытаний) то это совсем другой калибр. При таких условиях, формальный метод должен быть вполне надежным.
P.S: Я сам с ПМИ не работал, интересно, она пишется вами по ТЗ в коопрерации с заказчиком или вам ее предоставляют извне, или как это происходит?

Она пишется по нашим рекомендациям :) да и за годы работы аналитики набили руку в этом деле и могут демонстрировать навыки тест-дизайна, прорабатывая документ с заказчиком

Sign up to leave a comment.