Оценка тестирования: как высчитать точное время на тестирование системы или «Когда тесты будут готовы?!»

    image

    Доброго времени суток всем! Меня зовут Денис, я руководитель службы тестирования в «БАРС Груп». Это мой первый пост на Хабре.

    Прочитав очень много интересных статей и почерпнув оттуда много полезной информации, захотелось что-то дать взамен. Тогда я начал анализировать темы: одни были уже озвучены, другие слишком просты («как войти в IT?»). P.S. ничьи чувства задеть не хотелось :)

    Как высчитать время на тесты – проблема и решение


    Как руководитель службы, я постоянно сталкиваюсь с вопросом от менеджеров: «Когда будет готово?» или «Сколько времени надо на тестирование?». Казалось бы что тут сложного, бери оценку по предыдущему проекту и плюс-минус тоже самое… но нет. Я понял, что задача не тривиальна и требует детальной проработки. И хочу поделиться ее решением.

    В нашей компании много бизнес-центров и в каждом свой подход к разработке — преимущественно это Kanban и Scrum. Поэтому выделены команды автоматизаторов-тестировщиков, которые синхронизированы с командой разработчиков с их методологией.

    Из-за разных подходов по управлению разработкой возникают сложности в единообразии формирования задач и планирования. Применение Kanban и Scrum в чистом виде не давало ответа, сколько времени уйдет на тестирование. В проектных решениях приходится каждый раз проводить оценку новому функционалу и покрытию его тестами. У меня на это уходило много времени на расчеты. Поэтому я решил взять методы оценки временных затрат по разработке ПО (на автоматизацию тестирования) за основу и модифицировать под свои реалии. В основу лег принцип средневзвешенной оценки и подсчет на основе типизирования. В качестве оценок будут выступать временные показатели по автоматизации типовых элементов системы, а в качестве весов — уровень подготовки специалистов. При формировании значений весов я выбрал точность оценки при выполнении задачи, т. е., чем опытнее специалист, тем меньше погрешность оценки. Получились следующие значения:

    • «Senior» – 95% точность, коэффициент 1,05
    • «Middle+» – 80% точность, коэффициент 1,2
    • «Middle» – 70% точность, коэффициент 1,3
    • «Junior+» – 60% точность, коэффициент 1,4
    • «Junior» – 50% точность, коэффициент 1,5

    Далее нам нужно будет перемножить временную оценку tn на соответствующий коэффициент Wn. Наш метод вычисления производится по формуле, где сумма весов не равно 1 (100%).

    image

    Wavg = (w1*t1 + w2*t2 … + wn*tn) / (w1+w2+ … + wn)

    Для подсчета взял два тестирования – функциональное и UI тестирование, потому что они суммарно составляют около 85%.

    Для получения итогового результата нам нужно собрать средневзвешенную оценку по каждому элементу в более крупный объект для расчетов — категорию.

    UI тестирование


    При тестировании UI требуется эмулировать работу пользователя через framework Selenium.Webdriver. При использовании такого подхода существуют сложно конструируемые элементы на формах: вкладки, документы с онлайн редактированием, огромные гриды со строками, древовидная структура и т. д. Помимо этих элементов есть еще факторы, которые влияют на время разработки тестов:

    • Структура форм (типовая-конструктор или кастомная)
    • AJAX запросы (их количество)

    Исходя из этого было выделено 3 категории UI форм по их сложности реализации тестами:

    1 категория



    2 категория



    3 категория



    В итоге я получил следующие результаты, которые представил в таблице:



    Функциональное тестирование


    Для функциональных тестов ситуация аналогична UI — выделены категории для систематизации кейсов. Помимо REST сервисов стоит сказать и о SOAP, он будет аналогичен 3 категории REST.

    Интеграционное тестирование подразумевает тестирование нескольких методов в одном сервисе, для примерной оценки мы взяли наличие 5 методов из расчета на 1 сервис.

    1 категория



    2 категория



    3 категория



    Аналогично UI таблице:



    При интеграционном тестировании происходит проверка работы сервисов, построенных как на REST, так и на SOAP. При проектировании сервиса количество используемых методов внутри может разным. Для расчетов мы взяли среднее значение в 5 методов.



    При таком подсчете временных затрат на проект процент попадания в эту оценку составил 81.

    Вместо заключения


    Чтобы провести подсчет первый раз, понадобилась неделя плотной работы. Поэтому оценку делал уже после проведения тестирования и затем сравнил результаты с реальными временными затратами.

    Основную работу достаточно проделать один раз и в дальнейшем считать уже по готовой «формуле». Но нужно учитывать факт, что уровень сотрудников растет, поэтому необходимо понимать вес каждого работника, чтобы знать, нужно ли пересчитывать показатели.
    Все выше описанное является моим опытом и не претендует на истину.
    БАРС Груп
    Создаем технологии. Меняем жизнь.

    Комментарии 4

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

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

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

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

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

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

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое