Материал: Обеспечения Базовый курс (3е издание) Версия книги 2 от 17. 04. 2023

Оценка трудозатрат
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 230/301
• Принимайте во внимание не зависящие от вас обстоятельства. Например, вы точно уверены, что выполните тестирование очередного билда за N че- ловеко-часов, вы учли все отвлекающие факторы и т.д. и решили, что точно закончите к такой-то дате. А потом в реальности выпуск билда задержива- ется на два дня, и ваш прогноз по моменту завершения работы оказывается нереалистичным.
• Задумывайтесь заранее о необходимых ресурсах. Так, например, необходи- мую инфраструктуру можно (и нужно!) подготовить (или заказать) заранее, т.к. на подобные вспомогательные задачи может быть потрачено много вре- мени, к тому же основная работа часто не может быть начата, пока не будут завершены все приготовления.
• Ищите способы организовать параллельное выполнение задач. Даже если вы работаете один, всё равно какие-то задачи можно и нужно выполнять па- раллельно (например, уточнение тест-плана, пока происходит разворачива- ние виртуальных машин). В случае если работа выполняется несколькими людьми, распараллеливание работы можно считать жизненной необходимо- стью.
• Периодически сверяйтесь с планом, вносите корректировки в оценку и уве- домляйте заинтересованных лиц о внесённых изменениях заблаговременно.
Например, вы поняли (как в упомянутом выше примере с задержкой билда), что завершите работу как минимум на два дня позже. Если вы оповестите проектную команду немедленно, у ваших коллег появляется шанс скорректи- ровать свои собственные планы. Если же вы в «час икс» преподнесёте сюр- приз о сдвигах срока на два дня, вы создадите коллегам объективную про- блему.
• Используйте инструментальные средства — от электронных календарей до возможностей вашей системы управления проектом: это позволит вам как минимум не держать в памяти кучу мелочей, а как максимум — повысит точ- ность формируемой оценки.
Оценка с использованием структурной декомпозиции
С другими техниками формирования оценки вы можете ознакомиться в следующей литературе:
• «Essential Scrum», Kenneth Rubin.
• «Agile Estimating and Planning», Mike Cohn.
• «Extreme programming explained: Embrace change», Kent Beck.
• PMBOK («Project Management Body of Knowledge»).
• Краткий перечень основных техник с пояснениями можно посмотреть в статье «Software Estimation Techniques — Common Test Estimation Tech- niques used in SDLC
345
».
Структурная декомпозиция (work breakdown structure, WBS
346
)
— иерар- хическая декомпозиция объёмных задач на всё более и более малые под- задачи с целью упрощения оценки, планирования и мониторинга выпол- нения работы.
345
«Software Estimation Techniques - Common Test Estimation Techniques used in SDLC» [
http://www.softwaretest- ingclass.com/software-estimation-techniques/
]
346
The WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team, to accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project. The WBS subdivides the project work into smaller, more manageable pieces of work, with each descending level of the WBS representing an increasingly detailed definition of the project work. The planned work contained within the lowest-level WBS components, which are called work packages, can be scheduled, cost estimated, monitored, and controlled. [PMBOK, 3
rd edition]

Оценка трудозатрат
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 231/301
В процессе выполнения структурной декомпозиции большие задачи делятся на всё более и более мелкие подзадачи, что позволяет нам:
• описать весь объём работ с точностью, достаточной для чёткого понимания сути задач, формирования достаточно точной оценки трудозатрат и выра- ботки показателей достижения результатов;
• определить весь объём трудозатрат как сумму трудозатрат по отдельным за- дачам (с учётом необходимых поправок);
• от интуитивного представления перейти к конкретному перечню отдельных действий, что упрощает построение плана, принятие решений о распаралле- ливании работ и т.д.
Сейчас мы рассмотрим применение структурной декомпозиции в сочетании с упрощённым взглядом на оценку трудозатрат на основе требований и тест-кей- сов.
С подробной теорией по данному вопросу можно ознакомиться в следую- щих статьях:
• «Test Effort Estimation Using Use Case Points
347
», Suresh Nageswaran.
• «Test Case Point Analysis
348
», Nirav Patel.
Если абстрагироваться от научного подхода и формул, то суть такой оценки сводится к следующим шагам:
• декомпозиции требований до уровня, на котором появляется возможность создания качественных чек-листов;
• декомпозиции задач по тестированию каждого пункта чек-листа до уровня
«тестировщицких действий» (создание тест-кейсов, выполнение тест-кейсов, создание отчётов о дефектах и т.д.);
• выполнению оценки с учётом собственной производительности.
Рассмотрим этот подход на примере тестирования требования ДС-2.4
{62}
:
«При указании неверного значения любого из параметров командной строки прило- жение должно завершить работу, выдав сообщение об использовании (ДС-3.1), а также сообщив имя неверно указанного параметра, его значение и суть ошибки (см.
ДС-3.2)».
Это требование само по себе является низкоуровневым и почти не требует декомпозиции, но чтобы проиллюстрировать суть подхода, проведём разделение требования на составляющие:
• Если все три параметра командной строки указаны верно, сообщение об ошибке не выдаётся.
• Если указано неверно от одного до трёх параметров, то выдаётся сообщение об использовании, имя (или имена) неверно указанного параметра и невер- ное значение, а также сообщение об ошибке: o
Если неверно указан SOURCE_DIR или DESTINATION_DIR: «Directory not exists or inaccessible
». o
Если DESTINATION_DIR находится в SOURCE_DIR: «Destination dir may not reside within source dir tree
». o
Если неверно указан LOG_FILE_NAME: «Wrong file name or inaccessi- ble path
».
347
«Test Effort Estimation Using Use Case Points», Suresh Nageswaran [
http://citeseerx.ist.psu.edu/viewdoc/down- load?doi=10.1.1.597.6800&rep=rep1&type=pdf
]
348
«Test Case Point Analysis», Nirav Patel [
http://www.stickyminds.com/sites/default/files/article/file/2013/XUS373692file1_0.pdf
]

Оценка трудозатрат
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 232/301
Создадим чек-лист и здесь же пропишем примерное количество тест-кейсов на каждый пункт из предположения, что мы будем проводить достаточно глубокое тестирование этого требования:
• Все параметры корректные {1 тест-кейс}.
• Несуществующий/некорректный путь для: o SOURCE_DIR {3 тест-кейса}; o DESTINATION_DIR {3 тест-кейса}.
• Недопустимое имя файла LOG_FILE_NAME {3 тест-кейса}.
• Значения SOURCE_DIR и DESTINATION_DIR являются корректными име- нами существующих каталогов, но DESTINATION_DIR находится внутри
SOURCE_DIR {3 тест-кейса}.
• Недопустимые/несуществующие имена объектов ФС указаны в более чем одном параметре {5 тест-кейсов}.
• Значения SOURCE_DIR и DESTINATION_DIR не являются корректными/су- ществующими именами каталогов, и при этом DESTINATION_DIR находится внутри SOURCE_DIR {3 тест-кейса}.
У нас получилось примерно 22 тест-кейса. Также давайте для большей пока- зательности примера предположим, что часть тест-кейсов (например, 10) уже была создана ранее.
Теперь сведём полученные данные в таблицу 2.6.a, где также отразим коли- чество проходов. Этот показатель появляется из соображения, что некоторые тест- кейсы будут находить дефекты, что потребует повторного выполнения тест-кейса для верификации исправления дефекта; в некоторых случаях дефекты будут от- крыты заново, что потребует повторной верификации. Это относится лишь к части тест-кейсов, потому количество проходов может быть дробным, чтобы оценка была более точной.
Количество проходов для тестирования новой функциональности в общем случае можно грубо оценивать так:
• Простая функциональность: 1–1.5 (не все тесты повторяются).
• Функциональность средней сложности: 2.
• Сложная функциональность: 3–5.
Таблица 2.6.a — Оценка количества создаваемых и выполняемых тест-кейсов
Создание
Выполнение
Количество
12 22
Повторения (проходы)
1 1.2
Общее количество
12 26.4
Время на один тест-кейс
Итоговое время
Осталось заполнить ячейки со значениями времени, необходимого на разра- ботку и выполнение одного тест-кейса. К сожалению, не существует никаких маги- ческих способов выяснения этих параметров — только накопленный опыт о вашей собственной производительности, на которую среди прочего влияют следующие факторы (по каждому из них можно вводить коэффициенты, уточняющие оценку):
• ваш профессионализм и опыт;
• сложность и объёмность тест-кейсов;
• производительность тестируемого приложения и тестового окружения;
• вид тестирования;
• наличие и удобство средств автоматизации;
• стадия разработки проекта.

Оценка трудозатрат
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 233/301
Тем не менее существует простой способ получения интегральной оценки вашей собственной производительности, при котором влиянием этих факторов можно пренебречь: нужно измерять свою производительность на протяжении дли- тельного периода времени и фиксировать, сколько создать и выполнить тест-кей- сов вы можете в час, день, неделю, месяц и т.д. Чем больший промежуток времени будет рассмотрен, тем меньше на результаты измерений будут влиять кратковре- менные отвлекающие факторы, появление которых сложно предсказывать.
Допустим, что для некоторого выдуманного тестировщика эти значения ока- зались следующими — за месяц (28 рабочих дней) ему удаётся:
• Создать 300 тест-кейсов (примерно 11 тест-кейсов в день, или 1.4 в час).
• Выполнить 1000 тест-кейсов (примерно 36 тест-кейсов в день, или 4.5 в час).
Подставим полученные значения в таблицу 2.6.a и получим таблицу 2.6.b.
Таблица 2.6.b — Оценка трудозатрат
Создание
Выполнение
Количество
12 22
Повторения (проходы)
1 1.2
Общее количество
12 26.4
Время на один тест-кейс, ч
0.7 0.2
Итоговое время, ч
8.4 5.2
ИТОГО
13.6 часа
Если бы оценка производительности нашего выдуманного тестировщика производилась на коротких отрезках времени, полученное значение нельзя было бы использовать напрямую, т.к. в нём не было бы учтено время на написание отчё- тов о дефектах, участие в различных собраниях, переписку и прочие виды деятель- ности. Но мы потому и ориентировались на итоги измерений за месяц, что за 28 типичных рабочих дней все эти факторы многократно проявляли себя, и их влияние уже учтено в оценке производительности.
Если бы мы всё же опирались на краткосрочные исследования, можно было бы ввести дополнительный коэффициент или использовать допущение о том, что работе с тест-кейсами за один день удаётся посвятить не 8 часов, а меньше (напри- мер, 6).
Итого у нас получилось 13.6 часа, или 1.7 рабочих дня. Помня идею о за- кладке небольшого «буфера», можем считать, что за два полных рабочих дня наш выдуманный тестировщик точно справится с поставленной задачей.
В заключение этой главы ещё раз отметим, что для уточнения собственной производительности и улучшения своих навыков оценки трудозатрат стоит форми- ровать оценку, после чего выполнять работу и сравнивать фактический результат с оценкой. И повторять эту последовательность шагов раз за разом.

Примеры использования различных техник тестирования
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 234/301
2.7.
Примеры использования различных техник тестирования
2.7.1.
Позитивные и негативные тест-кейсы
Ранее мы уже рассматривали
{153}
алгоритм продумывания идей тест-кейсов, в котором предлагается ответить себе на следующие вопросы относительно тести- руемого объекта:
• Что перед вами?
• Кому и зачем оно нужно (и насколько это важно)?
• Как оно обычно используется?
• Как оно может сломаться, т.е. начать работать неверно?
Сейчас мы применим этот алгоритм, сконцентрировавшись на двух послед- них вопросах, т.к. именно ответы на них позволяют нам придумать много позитив- ных
{82}
и негативных
{82}
тест-кейсов. Продолжим тестировать наш «Конвертер фай- лов
{60}
», выбрав для исследования первый параметр командной строки —
SOURCE_DIR
— имя каталога, в котором приложение ищет файлы, подлежащие конвертации.
Что перед нами? Путь к каталогу. Казалось бы, просто, но стоит вспомнить, что наше приложение должно работать
{61}
как минимум под управлением Windows и Linux, что приводит к необходимости освежить в памяти принципы работы фай- ловых систем в этих ОС. А ещё может понадобиться работа с сетью.
Кому и зачем оно нужно (и насколько это важно)? Конечные пользователи не занимаются конфигурированием приложения, т.е. этот параметр нужен админи- стратору (предположительно, это человек квалифицированный и не делает явных глупостей, но из его же квалификации вытекает возможность придумать такие ва- рианты использования, до которых не додумается рядовой пользователь). Важ- ность параметра критическая, т.к. при каких-то проблемах с ним есть риск полной потери работоспособности приложения.
Как оно обычно используется? Здесь нам понадобится понимание прин- ципов работы файловых систем.
• Корректное имя существующего каталога: o Windows:
▪ X:\dir
▪
“X:\dir with spaces”
▪ .\dir
▪ ..\dir
▪ \\host\dir
▪
Всё вышеперечисленное с “\” в конце пути.
▪ X:\ o Linux:
▪ /dir
▪
“/dir with spaces”
▪ host:/dir
▪ smb://host/dir
▪ ./dir
▪ ../dir
▪
Всё вышеперечисленное с “/” в конце пути.
▪ /