Эффективная оценка времени для тестирования ПО

Оценка времени (англ. time estimation, отсюда – “‘эстимейты”) имеет большое значение при планировании тестирования ПО. От ее точности зависит, сумеет ли команда выпустить продукт в запланированные сроки. Правильно составленный график тестирования может значительно повлиять на общий успех и готовность продукта к релизу.

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

Иерархическая структура работ

Метод иерархической структуры работ (ИСР; англ. Work Breakdown Structure, WBS) предполагает разделение процесса тестирования на более мелкие и управляемые части. Это позволяет более эффективно распределять время и ресурсы, учитывать зависимости между задачами, а также улучшать взаимодействие между сотрудниками.

Давайте рассмотрим применение метода ИСР пошагово.

1. Определите основные цели или задачи тестирования, например, «Протестировать программу X перед релизом».

2. Разейте цель проекта на основные компоненты. Например:

• Планирование тестирования
• Разработка тест-кейсов
• Выполнение тестов
• Составление баг-репорта
• Завершение тестирования

3. Разбейте каждый компонент на более мелкие и конкретные задачи. Например:

• Планирование тестирования:
  1. Определить область тестирования
  2. Обозначить объекты тестирования
  3. Распределить ресурсы
• Разработка тест-кейсов:
  1. Разработать тест-кейсы для функционального тестирования
  2. Написать тест-кейсы для тестирования производительности

И так далее для каждого компонента.

4. Присвойте уникальный идентификатор каждому элементу. Это поможет в отслеживании и управлении работой. Например, 1.0 для планирования тестирования, 1.1 для определения области тестирования и т. д.

5. Определите порядок выполнения задач. Возможно, некоторые задачи необходимо завершить перед выполнением других.

6. Для каждой задачи определите ресурсы (инструменты, количество сотрудников и т. д.) и время, необходимое для её выполнения. Это поможет в планировании и составлении графика проекта.

7. Используйте диаграмму или график для визуального представления ИСР.

8. Обсудите ИСР с командой и заказчиками, чтобы убедиться, что все моменты учтены и соответствуют целям проекта. Если необходимо, внесите уточнения или исправления.

Иерархическая структура работ — это «живой» документ, который следует обновлять и уточнять по мере развития проекта или появления новых требований.

Трёхточечный метод

Трёхточечный метод рассматривает три потенциальных сценария:

• Наилучший сценарий (оптимистичная оценка)
• Наиболее вероятный сценарий (реалистичная оценка)
• Наихудший сценарий (пессимистичная оценка)

Вычислив среднее значение этих сценариев, вы сможете получить сбалансированную и реалистичную оценку времени проекта.

Оценка времени с учётом потребностей пользователя

Это очень полезная методология оценки времени, необходимого для тестирования ПО. Она фокусируется на том, как пользователь будет взаимодействовать с приложением в реальных условиях. Этот метод предполагает изучение различных сценариев использования продукта, тем самым обеспечивая тщательное тестирование ПО с точки зрения пользователя.

Этот подход помогает понять и оценить необходимые усилия для тестирования. Вот подробное объяснение того, как это помогает в оценке времени:

1. Каждый тест-кейс представляет собой функциональный сценарий, в котором пользователь взаимодействует с программным обеспечением. Определите эти сценарии, чтобы получить четкое представление о том, что нужно протестировать.
2. Тест-кейсы различаются по сложности. Проанализировав каждый тест-кейс, вы сможете определить, какие усилия потребуются для его тестирования. Сложные тест-кейсы, включающие множество взаимодействий с системой, как правило, требуют больше времени на тестирование.
3. Эта методология гарантирует, что будут охвачены все функциональные аспекты программного обеспечения.
4. Некоторые тест-кейсы могут представлять повышенный риск (например, те, которые связаны с критическими бизнес-функциями). Определите их, чтобы выделить дополнительное время на более тщательное тестирование этих функций.

Пример оценки

Представьте себе программное приложение для онлайн-банкинга. Вот некоторые тест-кейсы:

• Тест-кейс 1.  Пользователь входит в свою учетную запись.
• Тест-кейс 2. Пользователь переводит деньги на другой счет.
• Тест-кейс 3.  Пользователь просматривает историю своих транзакций.

Для оценки времени:

• Тест-кейс 1 может быть простым, требующим мало времени для тестирования базовой функциональности входа в систему.
• Тест-кейс 2 состоит из нескольких этапов (ввод данных учетной записи, верификация, обработка транзакции), а значит, требует больше времени на тестирование, в том числе на такие нестандартные случаи, как неправильные данные учетной записи или сбои в сети.
• Тест-кейс 3 включает в себя получение и отображение данных и требует проверки точности данных.

Оценив время, необходимое для каждого из этих тест-кейсов, исходя из их сложности и количества сценариев, вы сможете предоставить полную оценку времени для всего проекта. Например, тест-кейс 1 может занять 5 часов, тест-кейс 2 может занять 15 часов из-за своей сложности, а тест-кейс 3 может потребовать 10 часов. Таким образом, общее расчетное время тестирования этих основных функций составит 30 часов.

Метод оценки Ad-Hoc

Метод Ad-Hoc может быть особенно полезен в ситуациях, когда требуется быстрая и менее формальная оценка. Этот подход опирается на коллективный опыт и суждения команды тестировщиков, особенно если команда уже имела опыт работы в проектах подобного типа.

Вот шаги по проведению такой оценки:

1. Соберите вместе членов команды, которые будут участвовать в процессе тестирования.
2. Сделайте обзор проекта, включая его цели и ключевые особенности. Это поможет команде понять, что именно они будут оценивать.
3. Предложите членам команды применить свой прошлый опыт работы над аналогичными проектами. Можно вспомнить, сколько времени ушло на тестирование аналогичных функций или решение схожих задач в прошлом.
4. Проведите открытый мозговой штурм, в ходе которого члены команды обсудят различные аспекты проекта и поделятся своими мыслями о возможных сложностях и временных требованиях.
5. Попросите каждого члена команды предоставить свою собственную оценку для всего проекта или для его конкретных компонентов.
6. Если в оценках, предоставленных членами команды, есть существенные различия, обсудите их. Постарайтесь понять, чем обусловлены разные оценки.
7. По итогам обсуждения постарайтесь прийти к общему мнению.
8. Учитывайте все внешние факторы, которые могут повлиять на время тестирования, такие как доступность ресурсов, инструменты, внешние зависимости и потенциальные риски.

Методика Wideband Delphi 

Прим. перев. Название “Wideband Delphi” можно перевести как “Широкополосный Delphi”. Сам метод является производным от метода Delphi, который был назван в честь Дельфийского оракула.  

Метод Wideband Delphi позволяет команде прийти к общей оценке времени благодаря серии итеративных обсуждений. Для применения этого метода необходимо выполнить следующие шаги:

1. Выберите группу экспертов, обычно состоящую из членов проекта, обладающих различными знаниями и опытом.
2. Организуйте встречу, на которой будут определены масштабы и цели проекта.
3. Каждый член команды самостоятельно записывает свою оценку времени.
4. Первоначальная оценка проводится анонимно.
5. Группа обсуждает оценки, обращая внимание на разницу между ними.
6. После обсуждения все члены команды независимо друг от друга пересматривают свои оценки. Этот процесс повторяется несколько раз.
7. В ходе этих итеративно повторяющихся обсуждений оценки членов группы обычно сводятся к общей.
8. После выявления окончательной оценки она документируется и используется для планирования проекта.

Метод пропорционального распределения

Эта техника заключается в назначении процентного соотношения усилий на каждый этап цикла тестирования. Таким образом можно эффективно определить приоритеты задач и распределить ресурсы, гарантируя, что усилия сосредоточены на наиболее критических моментах тестирования.

Чтобы использовать этот метод, необходимо выполнить следующие шаги:

1. Разбейте проект на основные фазы или компоненты. Например, планирование, разработка тест-кейсов, выполнение тестов, создание баг-репортов и завершение тестирования.
2. Оцените важность и сложность каждого этапа.
3. На основе полученных оценок определите для каждого этапа процент от общего объема работ или ресурсов проекта. Эти проценты должны отражать относительный объем работ или ресурсов, которые, как ожидается, потребуются на каждом этапе.
4. Умножьте общее количество предполагаемых усилий или ресурсов для проекта на процент, выделенный для каждой фазы. Это даст вам оценку усилий или ресурсов, необходимых для каждого компонента.

Рассмотрим проект по тестированию программного обеспечения, общая трудоемкость которого оценивается в 100 человеко-дней. Если планирование тестирования займет 10 % усилий, разработка тест-кейсов – 20 %, выполнение тестов – 50 %, составление баг-репорта – 10 % и завершение тестирования – 10 %, то распределение усилий будет следующим:

• Планирование тестирования = 10 человеко-дней (10% от 100)
• Разработка тест-кейсов = 20 человеко-дней (20% от 100)
• Выполнение тестов = 50 человеко-дней (50% от 100)
• Создание баг-репорта = 10 человеко-дней (10% от 100)
• Закрытие тестирования = 10 человеко-дней (10% от 100)

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

Покер планирования и T-Shirt Sizing

Эти методы помогают команде договориться о сложности и размере задач путем обсуждений, фокусируясь на сравнительной сложности, а не на точных временных оценках.

Рекомендации по проведению оценки времени

1. Организуйте встречи и обсуждения с заинтересованными сторонами, чтобы получить глубокое понимание требований проекта.
2. Разбейте общий процесс тестирования на более мелкие, управляемые задачи.
3. Изучите прошлые проекты с аналогичными объемами или требованиями. Проанализируйте данные, чтобы понять, сколько времени было потрачено на выполнение аналогичных задач, и используйте эту информацию для определения текущей оценки.
4. Привлекайте к работе членов команды, имеющих соответствующий опыт или знания в аналогичных проектах.
5. В начале проекта проведите оценку рисков, чтобы выявить потенциальные проблемы, которые могут повлиять на сроки.
6. Убедитесь, что вы включили в оценку время на создание и поддержку необходимых тестовых сред и инструментов. Этот аспект часто упускается из виду и может существенно повлиять на общие сроки.
7. По мере реализации проекта и получения дополнительной информации оценка может подвергаться изменениям.

Научиться оценивать время для тестирования программного обеспечения – ключевой момент для успеха проекта. Применяя методы из нашей статьи, вы сможете значительно повысить точность своих оценок.

Перевод статьи «Effective Time Estimation in Software Testing».