Методы оценки объема тестирования в программном тестировании
Томас Гамильтон
⚡ Умное резюме
Методы оценки сроков тестирования программного обеспечения позволяют приблизительно определить, сколько времени займет тестирование и сколько оно будет стоить. Четырехэтапный процесс — разбивка задач, назначение ответственных, оценка трудозатрат и согласование с заинтересованными сторонами — превращает расплывчатые сроки в обоснованный план, который может быть утвержден руководством.
Что такое оценка тестирования программного обеспечения?
Оценка эффективности тестирования программного обеспечения Это управленческая деятельность, которая позволяет приблизительно оценить продолжительность и стоимость задачи тестирования. Составление достоверной оценки затрат на тестирование является одной из важнейших обязанностей. управление тестированием Потому что это влияет на сроки, бюджет и решения, касающиеся распределения ресурсов.
Почему важна оценка результатов тестирования
Перед подписанием договора на проведение тестового проекта клиенты всегда задают два вопроса:
Для небольших проектов ответить на эти вопросы легко. Для более крупного проекта — например, тестирования — это несложно. GuruВеб-сайт 99 Bank — вам нужна структурированная методика для обоснования ответа.
Что оценить?
- Ресурсы: люди, оборудование, помещения, финансирование и все остальное, что необходимо для выполнения работы.
- Время: Самый ценный ресурс в любом проекте — у каждого релиза есть крайний срок.
- Навыки межличностного общения: Знания и опыт команды. Более опытные тестировщики справляются с задачей быстрее, чем менее опытная команда.
- Стоимость: Бюджет проекта — сколько денег потребуется для проведения запланированных испытаний.
Как оценить
К распространенным методам оценки эффективности тестирования программного обеспечения относятся:
- Структура декомпозиции работ (WBS).
- Оценка по трем точкам.
- Широкополосный Delphi.
- Анализ функциональных точек или точек тестирования.
- Метод, основанный на анализе конкретных сценариев использования.
- Процентное распределение.
- Специальный метод.
Описанный ниже четырехэтапный процесс сочетает в себе несколько методов для получения обоснованной оценки. В примере используется GuruПример из практики банка № 99.
Шаг 1) Разделите весь проект на подзадачи.
Использовать Иерархическая структура работы Метод разделения сложного проекта на модули, подмодули и, в конечном итоге, на мельчайшие значимые задачи. Оценки на уровне конечных элементов гораздо надежнее, чем при сравнении с расплывчатыми первоначальными проектами.
Примените эту технику для разрыва GuruПроект «99 Банк» разбит на пять более мелких задач:
Затем каждая задача разбивается на подзадачи, пока каждая строка не станет достаточно подробной для оценки.
| Сложность задачи | Подзадача |
|---|---|
| Анализ спецификации требований к программному обеспечению | Изучите технические требования. |
| Проведите интервью с разработчиками и другими заинтересованными сторонами, чтобы узнать больше о веб-сайте. | |
| Создайте спецификацию теста | Разрабатывайте тестовые сценарии. |
| Создайте тестовые примеры. | |
| RevПросмотрите и пересмотрите тестовые примеры. | |
| Выполнить тестовые примеры | Создайте тестовую среду. |
| Выполните тестовые примеры. | |
| RevРезультаты выполнения теста. | |
| Сообщите о дефектах | Создайте дефект отчеты. |
| Сообщите о выявленных недостатках. |
Шаг 2) Распределите каждую задачу между членами команды.
Назначьте каждому подзадачному сотруднику наиболее подходящего исполнителя.
| Сложность задачи | Владелец |
|---|---|
| Анализ спецификации требований к программному обеспечению | Все члены команды |
| Создайте спецификацию теста | Тестировщик / Аналитик по тестированию |
| Создайте тестовую среду. | Администратор тестирования |
| Выполнить тестовые примеры | Тестировщик, администратор тестирования |
| Сообщить о дефектах | тестер |
Шаг 3) Оценка трудозатрат для каждой задачи
На этом этапе хорошо работают две взаимодополняющие методики:
- Метод функциональных точек.
- Трехточечная оценка.
Метод 1) Метод функциональных точек
Менеджер по тестированию оценивает размер, продолжительность и стоимость каждой задачи.
Шаг А) Оцените масштаб задачи.
Рассмотрим задачу «Создать спецификацию тестирования». Ее размер зависит от функционального размера тестируемой системы — чем больше функций, тем сложнее система. Функциональные точки обычно классифицируются на три группы: сложные, средние и простые.
В зависимости от сложности, менеджер по тестированию присваивает вес каждой функциональной точке:
| В группе | утяжеление |
|---|---|
| Комплекс | 5 |
| Средний | 3 |
| Простой | 1 |
GuruВеб-сайт 99 Bank разделен на 12 функциональных разделов. Их сложность кратко описана ниже.
| # | Модули | Применимые роли | Описание | утяжеление |
|---|---|---|---|---|
| 1 | Баланс Запрос | Менеджер по работе с клиентами | Клиент: Просматривайте только баланс своих счетов. Менеджер: Просматривайте баланс каждого клиента под наблюдением. |
3 |
| 2 | Перевод денежных средств | Менеджер по работе с клиентами | Клиент: переводить средства со своего счета в любое место назначения. Менеджер: Перевод средств из любого источника в любое место назначения. |
5 |
| 3 | Мини Заявление | Менеджер по работе с клиентами | Последние пять транзакций по счету. Клиент: Просматривайте только свои собственные учетные записи. Менеджер: Просмотреть любую учетную запись. |
3 |
| 4 | Индивидуальное заявление | Менеджер по работе с клиентами | Отфильтрованные транзакции по дате или сумме. Клиент: Только собственные аккаунты. Менеджер: любой аккаунт. |
5 |
| 5 | Пароль | Менеджер по работе с клиентами | Клиент: Сменить собственный пароль. Менеджер: Изменить собственный пароль (а не пароль клиента). |
1 |
| 6 | Новый клиент | Менеджер | Добавляйте и редактируйте данные клиента (адрес, электронная почта, телефон). | 3 |
| 7 | Новый аккаунт | Менеджер | Сберегательные и текущие счета; клиент может иметь несколько счетов каждого типа. Менеджер добавляет новые счета для существующих клиентов. | 5 |
| 8 | Изменить учетную запись | Менеджер | Редактировать данные существующей учетной записи. | 1 |
| 9 | Удалить аккаунт | Менеджер | Удалить существующую учетную запись клиента. | 1 |
| 10 | Удалить клиента | Менеджер | Удалять клиента следует только тогда, когда нет активных учетных записей. | 1 |
| 11 | Залог | Менеджер | Внесите наличные на любой счет в отделении банка. | 3 |
| 12 | Запросить выплату | Менеджер | Снять наличные с любого счета можно в отделении банка. | 3 |
Шаг B) Оцените продолжительность выполнения задачи.
После определения уровня сложности оцените продолжительность тестирования каждой группы.
- Общие усилия: Были приложены все усилия для тестирования каждой функции веб-сайта.
- Общее количество функциональных баллов: общее количество модулей веб-сайта.
- Оценка стоимости на одну функциональную точку: Среднее усилие на одно очко; зависит от производительности команды.
Предположим, что оценка команды для каждой функциональной точки составляет 5 часов/точкаОбщие усилия для GuruПример банка 99:
| В группе | утяжеление | Функциональные точки | Всего |
|---|---|---|---|
| Комплекс | 5 | 3 | 15 |
| Средний | 3 | 5 | 15 |
| Простой | 1 | 4 | 4 |
| Функция Общее количество баллов | 34 | ||
| Оценка за пункт | 5 | ||
| Общие расчетные трудозатраты (человеко-часы) | 170 | ||
Общие трудозатраты на выполнение задачи «Создание спецификации тестирования» составляют приблизительно 170 человеко-часовПосле определения трудозатрат можно распределить ресурсы, чтобы определить продолжительность и стоимость.
Шаг C) Оцените стоимость выполнения задач.
На этом этапе дается ответ на второй вопрос клиента — «Сколько это стоит?». Предположим, средняя стоимость услуги команды составляет... $ 5 / часВыполнение вышеуказанной задачи занимает 170 часов, поэтому стоимость составляет 170 × $5 = $850Примените тот же расчет ко всем задачам структуры разбиения работ (WBS), чтобы получить бюджет проекта.
Чем точнее будет оценка, тем лучше вы сможете управлять бюджетом проекта и гарантировать, что каждый потраченный доллар принесет прибыль.
Метод 2) Трехточечная оценка
Трехточечная оценка — это структурированная методика, при которой менеджер по тестированию предоставляет три значения для каждой задачи. оптимистический, скорее всего и пессимистический прилагаемые усилия — основанные на предыдущем опыте или на предположениях.
Для параметра «Создать спецификацию теста» могут быть указаны три значения:
- Лучший пример: 120 человеко-часов (~15 дней) с сильной, опытной командой.
- Скорее всего: 170 человеко-часов (примерно 21 день) при типичной численности команды и имеющихся ресурсах.
- Худший случай: 200 человеко-часов (~25 дней) с менее опытной командой и дополнительной переделкой.
Вычислите средневзвешенное значение, используя формулу в стиле PERT:
Значение E это средневзвешенное — предварительная оценка для раздела «Создание спецификации тестирования».
Чтобы выразить уверенность вокруг EВычислите стандартное отклонение:
Для того, чтобы получить GuruВ примере с банком 99 расчетная сумма составляет... 166.6 ± 13.33 человеко-часов — диапазон от 153.33 до 179.99 человеко-часов.
Шаг 4) Подтвердите оценку
Сведите воедино все оценки задач из структуры разбиения работ и представьте план на рассмотрение и утверждение совету директоров (генеральному директору, руководителю проекта, ключевым заинтересованным сторонам).
Пошагово объясните составителя сметы, чтобы они поняли исходные предположения, выбранные методы и предусмотренный вами резерв.
Тестовая оценка лучших практик
Добавить буферное время
Планы редко выдерживают проверку реальностью — члены команды уходят, тестирование занимает больше времени, чем ожидалось, зависимости нарушаются. Закладывайте в каждую оценку разумный запас времени, чтобы график учитывал мелкие неожиданности.
План обеспечения доступности ресурсов
Учитывайте запланированные отпуска, обучение и дежурства по вызову. Оценки, игнорирующие доступность персонала, отлично смотрятся на бумаге, но рушатся на практике.
Используйте прошлый опыт в качестве ориентира.
Исторические данные по аналогичным проектам бесценны. Если вы тестировали аналогичный веб-сайт в прошлом году, извлеките уроки из его реальных результатов, возникших проблем и того, что помогло избежать ошибок.
Придерживайтесь сметы, но пересмотрите её.
Оценки не являются конечными.tracЭто лишь предположения. RevПересматривайте их на известных этапах и вносите корректировки только тогда, когда требования существенно меняются или новая информация меняет ситуацию. Обсуждайте любые изменения с клиентом прозрачно.
Шаблон оценки тестирования программного обеспечения
Скачайте файл Excel (.xlsx) для оценки результатов тестирования программного обеспечения.
Другие методы оценки
Помимо методов WBS, Function Point и Three-Point estimation, широко используются и другие методики:
- Широкополосный Дельфи: итеративная оценка консенсуса группой экспертов.
- Метод анализа конкретных сценариев использования: Усилия определяются количеством и сложностью вариантов использования.
- Процентное распределение: выделяет фиксированный процент от общего объема работ по проекту на тестирование.
- Специальный метод: Экспертная оценка в случае отсутствия исторических данных.
Оценка «снизу вверх» против оценки «сверху вниз»
Практический подход к оценке также сводится к двум взаимодополняющим стратегиям:
- Оценка «снизу вверх»: Основано на задачах самого низкого уровня структуры разбиения работ (WBS). Многочисленные заинтересованные стороны, опытные сотрудники и участники объединяют свои данные для получения точной итоговой суммы. Идеально подходит, когда работа хорошо понятна.
- Оценка сверху вниз: Классифицирует проект по размеру и сложности и сравнивает его с завершенными проектами аналогичной формы. Также использует средний трудозатраты на одного участника. прецедент и масштабируется в зависимости от прогнозируемого числа случаев. Полезно на ранних этапах проекта, когда деталей мало.
Большинство команд сочетают оба подхода — нисходящий для получения основного показателя, восходящий для оценки уверенности — и накладывают на результат сложные модели, когда бюджет оправдывает затраченные усилия.
