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

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

Прочитав очень много интересных статей и почерпнув оттуда много полезной информации, захотелось что-то дать взамен. Тогда я начал анализировать темы: одни были уже озвучены, другие слишком просты («как войти в 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

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

W_avg = (w₁*t₁ + w₂*t₂ … + w_n*t_n) / (w₁+w₂+ … + w_n)

Для подсчета взял два тестирования – функциональное и 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.

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

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

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