26 июня 2024
Как рассчитать сроки тестирования на проекте, чтобы не сорвать дедлайны: методики оценки объема тестирования
Сроки тестирования программного обеспечения — это важный фактор, от которого зависит успешность проекта. Если время на тестирование учтено неверно, то часто подобные ситуации приводят к срыву дедлайнов и увеличению стоимости проекта. Правильное планирование этапа тестирования позволяет избежать подобных проблем. Однако, как правильно рассчитать сроки для проведения полноценного тестирования?
Ревякина Яна
Ведущий инженер по тестированию ПО
Более 5 лет опыта в тестировании.
- тестирование back-end и front-end;
- выполнение задач по ручному функциональному тестированию программного продукта;
- локализация ошибок и регистрирование в баг-трекере всех выявленных отклонений от проектной документации и мониторинг исправлений (Jira, TestRail);
- написание тест-кейсов в ALM на основании требований FSD и BRD;
- составление чек-листов;
- проведение Smoke Testing, Regression Testing, Integration testing, re-test;
- актуализация существующих тест-кейсов;
- подготовка тестовых данных для проведения тестирования;
- написание SQL-запросов;
- ручное тестирование API (Soap UI);
- работа в Equation (банковская система);
- развертывание нового функционала на тестовый стенд (интеграционный и предпромышленный);
- мониторинг процесса установки функционала в промышленную среду;
- мониторинг и анализ промышленных багов;
- коммуникация с командой и отделом разработки;
- работа в Agile / Scrum среде;
- работа с DevTools: вкладка Network;
- составление state-transition testing для процесса РКО;
- работа в Swagger, Kibana;
- онбординг новых сотрудников на проектах.
Инструментарий:
SQL, MS Office, ALM Atlassian, Jira, SOAP UI, Rest API, Python, Тестирование web-сервисов, XML, HTML, CSS, JavaScript, Equation, Test Case, DevTools, Postman.Правильное планирование
Для начала необходимо определить общий объем работы и понять какой вид тестирования необходимо провести: функциональное, интеграционное или регрессионное. У каждого вида тестирования различные цели, что влияет на оценку времени на их проведение.
Функциональное тестирование направлено на проверку конкретных функций приложения. При расчете времени учитывается количество функций, сложность каждой из них и разнообразие сценариев использования.
Интеграционное тестирование направлено на проверку взаимодействия между различными модулями или компонентами системы. При расчете времени на интеграционное тестирование необходимо учесть количество взаимодействий между модулями, сложность этих интеграций и потребность в создании специальных средств для проведения такого тестирования (заглушек или эмуляторов). Важно отметить, что время на интеграционное тестирование может быть значительно больше, чем на функциональное. Причина в том, что при интеграционном тестировании проверяется не только работа каждого модуля по отдельности, но и корректность их взаимодействия. Например, сложные системы могут содержать скрытые зависимости или неочевидные взаимодействия между компонентами, которые выявляются только в процессе интеграционного тестирования. Это также может увеличить затраты времени.
Регрессионное тестирование направлено на проверку стабильности уже протестированных функций после внесения изменений в код или добавления новых функций. При оценке времени на регрессионное тестирование необходимо учесть объем предыдущего функционала, который нужно проверить, а также возможные зависимости между старыми и новыми частями системы.
В этом поможет разбиение проекта на отдельные модули или функциональные блоки. Каждый из них следует оценить по сложности и важности для бизнес-процессов заказчика. Этот подход позволяет выделить приоритетные задачи и уделить им больше времени при тестировании. Также не стоит забывать, что сроки тестирования зависят не только от количества функционала, но и от его качества: чем меньше ошибок в коде, тем быстрее пройдет процесс проверки.
Следующим шагом будет составление плана тестирования. В него входит подготовка тест-кейсов, определение техник тест-дизайна и инструментов для проверки, распределение задач между членами команды. Стоит также выделить запас времени на исправление обнаруженных ошибок и повторную проверку после внесения изменений.
Допустим, у вас есть проект с 10 модулями. После оценки сложности и важности каждого из них вы пришли к выводу, что на тестирование одного модуля должно уйти в среднем 3 дня. Таким образом, только на первичное тестирование всех модулей уйдет уже 30 дней. Если добавить время на регрессионное тестирование (проверка старого функционала после исправления ошибок), которое может занять еще около 10 дней, а также время на исправление ошибок и повторную проверку — еще около 10 дней, то общий срок тестирования составит примерно 50 рабочих дней. Это очень приблизительная оценка, которая может меняться в зависимости от многих факторов: качества кода, опытности команды и так далее.
Важно понимать, что точность прогнозирования сроков тестирования повышается с опытом. Поэтому важно не только аккуратно планировать работу, но и проводить анализ по завершении проекта. Оцените, насколько точно вы предсказали затраченное время, какие задачи оказались сложнее или проще ожидаемого. Используйте эту информацию для корректировки своих методик оценки в будущем. Ведь главная цель — не просто уложиться в сроки, а создать качественный продукт без ошибок и недоработок.
Факторы, влияющие на сроки тестирования
И последнее, что стоит упомянуть, — это факторы, которые могут повлиять на сроки тестирования. К ним относятся изменения в требованиях к проекту, непредвиденные проблемы в коде или инфраструктуре, заболевание членов команды и другие форс-мажорные обстоятельства. Планирование должно быть гибким и способным адаптироваться к изменяющимся условиям. Поэтому всегда оставляйте запас времени для таких ситуаций, чтобы не сорвать дедлайны и сохранить репутацию надежного исполнителя.
Методики оценки. Сравнительный анализ
Для того, чтобы ваша оценка была комплексной, могут использоваться различные методики оценки сроков тестирования на проекте. Ниже будет проведен сравнительный анализ наиболее часто используемых методик с выделением плюсов и минусов.
Для начала необходимо определить общий объем работы и понять какой вид тестирования необходимо провести: функциональное, интеграционное или регрессионное. У каждого вида тестирования различные цели, что влияет на оценку времени на их проведение.
Функциональное тестирование направлено на проверку конкретных функций приложения. При расчете времени учитывается количество функций, сложность каждой из них и разнообразие сценариев использования.
Интеграционное тестирование направлено на проверку взаимодействия между различными модулями или компонентами системы. При расчете времени на интеграционное тестирование необходимо учесть количество взаимодействий между модулями, сложность этих интеграций и потребность в создании специальных средств для проведения такого тестирования (заглушек или эмуляторов). Важно отметить, что время на интеграционное тестирование может быть значительно больше, чем на функциональное. Причина в том, что при интеграционном тестировании проверяется не только работа каждого модуля по отдельности, но и корректность их взаимодействия. Например, сложные системы могут содержать скрытые зависимости или неочевидные взаимодействия между компонентами, которые выявляются только в процессе интеграционного тестирования. Это также может увеличить затраты времени.
Регрессионное тестирование направлено на проверку стабильности уже протестированных функций после внесения изменений в код или добавления новых функций. При оценке времени на регрессионное тестирование необходимо учесть объем предыдущего функционала, который нужно проверить, а также возможные зависимости между старыми и новыми частями системы.
В этом поможет разбиение проекта на отдельные модули или функциональные блоки. Каждый из них следует оценить по сложности и важности для бизнес-процессов заказчика. Этот подход позволяет выделить приоритетные задачи и уделить им больше времени при тестировании. Также не стоит забывать, что сроки тестирования зависят не только от количества функционала, но и от его качества: чем меньше ошибок в коде, тем быстрее пройдет процесс проверки.
Следующим шагом будет составление плана тестирования. В него входит подготовка тест-кейсов, определение техник тест-дизайна и инструментов для проверки, распределение задач между членами команды. Стоит также выделить запас времени на исправление обнаруженных ошибок и повторную проверку после внесения изменений.
Допустим, у вас есть проект с 10 модулями. После оценки сложности и важности каждого из них вы пришли к выводу, что на тестирование одного модуля должно уйти в среднем 3 дня. Таким образом, только на первичное тестирование всех модулей уйдет уже 30 дней. Если добавить время на регрессионное тестирование (проверка старого функционала после исправления ошибок), которое может занять еще около 10 дней, а также время на исправление ошибок и повторную проверку — еще около 10 дней, то общий срок тестирования составит примерно 50 рабочих дней. Это очень приблизительная оценка, которая может меняться в зависимости от многих факторов: качества кода, опытности команды и так далее.
Важно понимать, что точность прогнозирования сроков тестирования повышается с опытом. Поэтому важно не только аккуратно планировать работу, но и проводить анализ по завершении проекта. Оцените, насколько точно вы предсказали затраченное время, какие задачи оказались сложнее или проще ожидаемого. Используйте эту информацию для корректировки своих методик оценки в будущем. Ведь главная цель — не просто уложиться в сроки, а создать качественный продукт без ошибок и недоработок.
Факторы, влияющие на сроки тестирования
И последнее, что стоит упомянуть, — это факторы, которые могут повлиять на сроки тестирования. К ним относятся изменения в требованиях к проекту, непредвиденные проблемы в коде или инфраструктуре, заболевание членов команды и другие форс-мажорные обстоятельства. Планирование должно быть гибким и способным адаптироваться к изменяющимся условиям. Поэтому всегда оставляйте запас времени для таких ситуаций, чтобы не сорвать дедлайны и сохранить репутацию надежного исполнителя.
Методики оценки. Сравнительный анализ
Для того, чтобы ваша оценка была комплексной, могут использоваться различные методики оценки сроков тестирования на проекте. Ниже будет проведен сравнительный анализ наиболее часто используемых методик с выделением плюсов и минусов.
Функциональные точки (Function Point Analysis, FPA)
Подход предполагает разбиение всего проекта на отдельные функциональные блоки и оценку каждого из них по определенным критериям. В подходе рассматриваются функции двух типов: функции данных и функции транзакций. Под функциями данных подразумеваются:
- Внутренние логические файлы
- Файлы внешнего интерфейса
Функции данных состоят из внутренних и внешних ресурсов, которые влияют на систему.
Транзакционные функции подразделяются на:
- Внешние входы
- Внешние выходы
- Внешние запросы
Функции транзакции состоят из процессов, которыми обмениваются пользователь, внешние приложения и измеряемое приложение.
Плюсы
Метод предполагает графическое отображение функций данных и функций транзакций посредством блок-схемы, в которой можно отметить также и интеграционное взаимодействие.
Минусы
Метод предполагает графическое отображение функций данных и функций транзакций посредством блок-схемы, в которой можно отметить также и интеграционное взаимодействие.
Разделение на подзадачи
Предполагает детальное разбиение всего проекта на маленькие задачи. Каждая из них оценивается отдельно, а затем суммируются все оценки для получения общего времени тестирования.
Плюсы
Декомпозиция задач позволяет разбить сложный процесс оценки функциональности на задачи меньшего размера для более качественной оценки.
Минусы
- Разделение на подзадачи процесс не из легких и может занять достаточно времени.
- Оценка является субъективной, не подкрепленной математической составляющей.
- Не используется, как самостоятельный метод, скорее будет хорошим помощником для других методов оценки.
Planning poker (Scrum poker)
Каждый член команды получает колоду карт с числами (обычно это числа Фибоначчи). Затем обсуждается каждая задача проекта по отдельности. Участники команды одновременно показывают карту с числом, которое, по их мнению, отражает сложность задачи. Если оценки сильно разнятся, проводится обсуждение для достижения консенсуса. В итоге получается оценка времени на тестирование всего проекта.
Плюсы
Предполагает участие всей команды, что позволяет составлять комплексную оценку по экспертным мнениям (разработчика, аналитика и тестировщика).
Минусы
- От всех участвующих в оценке требуется погружение в оцениваемый функционал, чтобы просчитать все интеграции, риски и узкие места. Без погружения даваемая оценка может быть поверхностной, и методика будет бесполезной.
- Оценка напрямую зависит от опытности оценивающего и знание функционального модуля.
- Нужно закладывать время на проведение оценки для всей команды.
Методика «PERT» (Program Evaluation and Review Technique)
Предполагает составление трех оценок для каждой задачи — оптимистической, пессимистической и реалистичной. Затем вычисляется средневзвешенное значение, которое используется как окончательная оценка.
Плюсы
Рассматриваются сроки в разрезе трех параметров — в наилучшем, наихудшем и наиболее вероятном, в этом случае можно наиболее точно определить срок выполнения тестирования по формуле — Pert = (Трудозатраты худшей ситуации + Трудозатраты лучшей ситуации + 4 * Трудозатраты правдивые) / 6.
Минусы
- Успешность использования метода зависит от корректности рассчитанных изначальных параметров, при неточности определения затраченного времени вся методика может быть бесполезной — важным критерием успешности является опыт тестировщика и знание модулей тестирования.
- Метод PERT предполагает, что одна задача должна завершиться, и только затем может начаться другая.
После выбора методики необходимо соотнести ее с факторами, также влияющими на корректную оценку затраченного времени на тестирование на проекте, которые могут корректироваться или дополняться в зависимости от команды и ее приоритетов- для упрощения, тип тестирования в таблице будет заменен на аббревиатуры ФТ (Функциональное тестирование), ИТ (Интеграционное тестирование) и РТ (Регрессионное тестирование) соответственно:
Одной из ключевых методик, которые я использую в рабочем процессе — это методика «PERT» и в дополнение — декомпозиция задач. Эти методики для моего проекта не раз подтверждали свою эффективность.
Эффективность используемой методики
С математической точки зрения эффективность используемой методики тестирования можно оценить, сравнивая запланированное и фактическое время выполнения работы. Для этого можно использовать следующую формулу:
Эффективность = ((Запланированное время — Фактическое время) / Запланированное время) * 100%
Если получившееся значение положительное, это значит, что работа была выполнена быстрее запланированного времени, и методика оказалась эффективной. Если значение отрицательное — работа заняла больше времени, чем планировалось, и возможно стоит пересмотреть выбранную методику.
Однако следует помнить, что данная формула дает лишь общую оценку эффективности и не учитывает многие важные аспекты проекта: качество выполненной работы, сложность задачи, непредвиденные обстоятельства и т. д. Поэтому для более точной оценки рекомендуется использовать комплексный подход и учитывать различные метрики проекта.
В дополнение к математическому расчету, можно использовать и другие методы оценки эффективности методики. Например, провести опрос среди участников команды: насколько они считают выбранную методику удобной, понятной и помогающей в работе.
Также можно проанализировать количество найденных и исправленных ошибок в ходе тестирования. Если их число минимально, а все ключевые баги были обнаружены и устранены — это также свидетельствует об эффективности выбранного подхода.
Важно помнить, что лучшей мерой эффективности является успешное завершение проекта в срок без потери качества продукта. Если выбранная методика способствует достижению этой цели — значит, она работает.
Используемая литература:
Эффективность используемой методики
С математической точки зрения эффективность используемой методики тестирования можно оценить, сравнивая запланированное и фактическое время выполнения работы. Для этого можно использовать следующую формулу:
Эффективность = ((Запланированное время — Фактическое время) / Запланированное время) * 100%
Если получившееся значение положительное, это значит, что работа была выполнена быстрее запланированного времени, и методика оказалась эффективной. Если значение отрицательное — работа заняла больше времени, чем планировалось, и возможно стоит пересмотреть выбранную методику.
Однако следует помнить, что данная формула дает лишь общую оценку эффективности и не учитывает многие важные аспекты проекта: качество выполненной работы, сложность задачи, непредвиденные обстоятельства и т. д. Поэтому для более точной оценки рекомендуется использовать комплексный подход и учитывать различные метрики проекта.
В дополнение к математическому расчету, можно использовать и другие методы оценки эффективности методики. Например, провести опрос среди участников команды: насколько они считают выбранную методику удобной, понятной и помогающей в работе.
Также можно проанализировать количество найденных и исправленных ошибок в ходе тестирования. Если их число минимально, а все ключевые баги были обнаружены и устранены — это также свидетельствует об эффективности выбранного подхода.
Важно помнить, что лучшей мерой эффективности является успешное завершение проекта в срок без потери качества продукта. Если выбранная методика способствует достижению этой цели — значит, она работает.
Используемая литература:
- http://citforum.ru/SE/project/arkhipenkov_lectures/12.shtml
- https://habr.com/ru/companies/mindbox/articles/321 270/
- https://www.it-academy.by/media/stati/pert-rabotaet-prosto-ne-vse-znayut-kak-ego-pravilno-primenyat/
- https://4brain.ru/blog/dekompoziciya-kak-instrument-dostizheniya-slozhnykh-celej/?ysclid=lxebi17p1v222496321
- https://skillbox.ru/media/management/planning_poker/?ysclid=lxeat22kpi659788701
- https://www.wrike.com/ru/blog/chto-takoe-pert-diagramma-v-sfere-upravleniya-proektami/?ysclid=lxe9vkllu802562528
- https://isolution.pro/ru/t/estimation-techniques/estimation-techniques-function-points/metody-ocenki-funkcional-nye-tocki
Вам также может быть интересно