Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Фактический материал содержит самые разнообразные данные, получен- ные в процессе тестирования. Сюда могут относиться отчёты о дефектах, журналы работы средств автоматизации, созданные различными приложениями наборы файлов и т.д. Как правило, к отчёту о результатах тестирования прилагаются лишь сокращённые агрегированные выборки подобных данных (если это возможно), а также приводятся ссылки на соответствующие документы, разделы системы управ- ления проектом, пути в хранилище данных и т.д. На этом мы завершаем теоретическое рассмотрение отчётности и перехо- дим к примеру — учебному отчёту о результатах тестирования нашего приложения «Конвертер файлов» {57} . Напомним, что приложение является предельно простым, потому и отчёт о результатах тестирования будет очень маленьким. Тест-план и отчёт о результатах тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 222/298 Пример отчёта о результатах тестирования Для того, чтобы заполнить некоторые части отчёта, нам придётся сделать допущения о текущем моменте развития проекта и сложившейся ситуации с каче- ством. Поскольку данный отчёт находится внутри текста книги, у него нет таких ти- пичных частей, как обложка, содержание и т.п. Итак. Краткое описание. За период 26–28 мая было выпущено четыре билда, на последнем из которых успешно прошло 100 % тест-кейсов дымового тестирования и 76 % тест-кейсов тестирования критического пути. 98 % требований высокой важ- ности реализовано корректно. Метрики качества находятся в зелёной зоне, потому есть все основания рассчитывать на завершение проекта в срок (на текущий мо- мент реальный прогресс в точности соответствует плану). На следующую итерацию (29 мая) запланировано выполнение оставшихся низкоприоритетных тест-кейсов. Команда тестировщиков. Имя Должность Роль Джо Блэк Тестировщик Ответственный за обеспече- ние качества Джим Уайт Старший разработчик Ответственный за парное те- стирование и аудит кода Описание процесса тестирования. Каждый из четырёх выпущенных за под- отчётный период билдов (3–6) был протестирован под ОС Windows 7 Ent x64 и ОС Linux Ubuntu 14 LTS x64 в среде исполнения PHP 5.6.0. Дымовое тестирование (см. http://projects/FC/Testing/SmokeTest) выполнялось с использованием автоматиза- ции на основе командных файлов (см. \\PROJECTS\FC\Testing\Aut\Scripts). Тести- рование критического пути (см. http://projects/FC/Testing/CriticalPathTest) выполня- лось вручную. Регрессионное тестирование показало высокую стабильность функ- циональности (обнаружен только один дефект с важностью «средняя»), а повтор- ное тестирование показало ощутимый прирост качества (исправлено 83 % обнару- женных ранее дефектов). Расписание. Имя Дата Деятельность Продолжительность, ч Джо Блэк 27.05.2015 Разработка тест-кейсов 2 Джо Блэк 27.05.2015 Парное тестирование 2 Джо Блэк 27.05.2015 Автоматизация дымового тестирова- ния 1 Джо Блэк 27.05.2015 Написание отчётов о дефектах 2 Джим Уайт 27.05.2015 Аудит кода 1 Джим Уайт 27.05.2015 Парное тестирование 2 Джо Блэк 28.05.2015 Разработка тест-кейсов 3 Джо Блэк 28.05.2015 Парное тестирование 1 Джо Блэк 28.05.2015 Написание отчётов о дефектах 2 Джо Блэк 28.05.2015 Написание отчёта о результатах те- стирования 1 Джим Уайт 28.05.2015 Аудит кода 1 Джим Уайт 28.05.2015 Парное тестирование 1 Тест-план и отчёт о результатах тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 223/298 Статистика по новым дефектам. Важность Статус Количество Низкая Средняя Высокая Критическая Найдено 23 2 12 7 2 Исправлено 17 0 9 6 2 Проверено 13 0 5 6 2 Открыто за- ново 1 0 0 1 0 Отклонено 3 0 2 1 0 Список новых дефектов. Идентификатор Важность Описание BR 21 Высокая Приложение не различает файлы и символические ссылки на файлы. BR 22 Критическая Приложение игнорирует файлы .md во входном ката- логе. И так далее — описание всех 23 найденных дефектов. Статистика по всем дефектам. Важность Статус Количество Низкая Средняя Высокая Критическая Найдено 34 5 18 8 3 Исправлено 25 3 12 7 3 Проверено 17 0 7 7 3 Открыто за- ново 1 0 0 1 0 Отклонено 4 0 3 1 0 Рекомендации. В настоящий момент никаких изменений не требуется. 0 5 10 15 20 25 30 35 40 26.05.2015 26.05.2015 27.05.2015 27.05.2015 28.05.2015 28.05.2015 1 2 3 4 5 6 Статистика по всем дефектам Найдено Закрыто Всего найдено Всего закрыто Тест-план и отчёт о результатах тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 224/298 Приложение. График изменения значений метрик. Задание 2.6.b: поищите в Интернете более развёрнутые примеры отчётов о результатах тестирования. Они периодически появляются, но и столь же быстро удаляются, т.к. настоящие (не учебные) отчёты, как правило, яв- ляются конфиденциальной информацией. 0 20 40 60 80 100 120 140 160 180 200 26.05.2015 26.05.2015 27.05.2015 27.05.2015 28.05.2015 28.05.2015 1 2 3 4 5 6 Метрики Tsp Dftp Dfcp S Te Rc Оценка трудозатрат Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 225/298 2.6.3. Оценка трудозатрат В завершение данной главы мы снова возвращаемся к планированию, но уже куда более простому — к оценке трудозатрат. Трудозатраты (man-hours 343 ) — количество рабочего времени, необходи- мого для выполнения работы (выражается в человеко-часах). Каждый раз, когда вы получаете задание или выдаёте кому-то задание, явно или неявно возникают вопросы наподобие следующих: • Как много времени понадобится на выполнение работы? • Когда всё будет готово? • Можно ли гарантированно выполнить работу к такому-то сроку? • Каковы наиболее оптимистичный и пессимистичный прогнозы по времени? Рассмотрим несколько соображений относительно того, как производится оценка трудозатрат. Любая оценка лучше её отсутствия. Даже если область предстоящей ра- боты для вас совершенно нова, даже если вы ошибётесь в своей оценке на поря- док, вы как минимум получите опыт, который сможете использовать в будущем при возникновении подобного рода задач. Оптимизм губителен. Как правило, люди склонны недооценивать сложность незнакомых задач, что приводит к занижению оценки трудозатрат. Но даже при достаточно точном определении самих трудозатрат люди без опыта выполнения оценки склонны рассматривать предстоящую работу как некую изолированную деятельность, забывая о том, что на протяжении любого рабочего дня «чистую производительность труда» будут снижать такие факторы, как пере- писка по почте, участие в собраниях и обсуждениях, решение сопутствующих тех- нических вопросов, изучение документации и обдумывание сложных частей задачи, форс-мажорные обстоятельства (неотложные дела, проблемы с техникой и т.д.). Таким образом, обязательно стоит учитывать, что в реальности вы сможете заниматься поставленной задачей не 100 % рабочего времени, а меньше (насколько меньше — зависит от конкретной ситуации, в среднем принято считать, что на поставленную задачу из каждых восьми рабочих часов вы сможете потратить не более шести). Учитывая этот факт, стоит сделать соответствующие поправки в оценке общего времени, которое понадобится на выполнение работы (а именно оно чаще всего интересует постановщика задачи). Оценка должна быть аргументирована. Это не значит, что вы всегда должны пускаться в подробные пояснения, но вы должны быть готовы объяснить, почему вы считаете, что та или иная работа займёт именно столько времени. Во- первых, продумывая эти аргументы, вы получаете дополнительную возможность лучше оценить предстоящую работу и скорректировать оценку. Во-вторых, если ваша оценка не соответствует ожиданиям постановщика задачи, вы сможете отсто- ять свою точку зрения. 343 Man-hour. A unit for measuring work in industry, equal to the work done by one man in one hour. [ http://dictionary.refer- ence.com/browse/man-hour ] Оценка трудозатрат Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 226/298 Простой способ научиться оценивать — оценивать. В специализирован- ной литературе (см. ниже небольшой список) приводится множество технологий, но первична сама привычка выполнять оценку предстоящей работы. В процессе вы- работки этой привычки вы естественным образом встретитесь с большинством ти- пичных проблем и через некоторое время научитесь делать соответствующие по- правки в оценке, даже не задумываясь. Что оценивать? Что угодно. Сколько времени у вас уйдёт на прочтение новой книги. За сколько времени вы доедете домой новым маршрутом. За сколько вре- мени вы напишете курсовую или дипломную работу. И так далее. Не важно, что именно вы оцениваете, важно, что вы повторяете это раз за разом, учитывая накап- ливающийся опыт. Если вас заинтересовал профессиональный подход к формированию оценки трудозатрат, рекомендуется ознакомиться со следующими источ- никами: • «The Mythical Man Month», Frederick Brooks. • «Controlling Software Projects», Tom De Marco. • «Software engineering metrics and models», Samuel Conte. Алгоритм обучения формированию оценки: • Сформируйте оценку. Ранее уже было отмечено, что нет ничего страшного в том, что полученное значение может оказаться очень далёким от реально- сти. Для начала оно просто должно быть. • Запишите полученную оценку. Обязательно именно запишите. Это за- страхует вас как минимум от двух рисков: забыть полученное значение (осо- бенно, если работа заняла много времени), соврать себе в стиле «ну, я как- то примерно так и думал». • Выполните работу. В отдельных случаях люди склонны подстраиваться под заранее сформированную оценку, ускоряя или замедляя выполнение ра- боты, — это тоже полезный навык, но сейчас такое поведение будет мешать. Однако если вы будете тренироваться на десятках и сотнях различных за- дач, вы физически не сможете «подстроиться» под каждую из них и начнёте получать реальные результаты. • Сверьте реальные результаты с ранее сформированной оценкой. • Учтите ошибки при формировании новых оценок. На этом этапе очень по- лезно не просто отметить отклонение, а подумать, что привело к его появле- нию. • Повторяйте этот алгоритм как можно чаще для самых различных областей жизни. Сейчас цена ваших ошибок крайне мала, а наработанный опыт от этого становится ничуть не менее ценным. Полезные идеи по формированию оценки трудозатрат: • Добавляйте небольшой «буфер» (по времени, бюджету или иным критиче- ским ресурсам) на непредвиденные обстоятельства. Чем более дальний про- гноз вы строите, тем большим может быть этот «буфер» — от 5–10 % до 30– 40 %. Но ни в коем случае не стоит осознанно завышать оценку в разы. • Выясните свой «коэффициент искажения»: большинство людей в силу осо- бенности своего мышления склонны постоянно или занижать, или завышать оценку. Многократно формируя оценку трудозатрат и сравнивая её впослед- ствии с реальностью, вы можете заметить определённую закономерность, которую вполне можно выразить числом. Например, может оказаться, что вы склонны занижать оценку в 1.3 раза. Попробуйте в следующий раз внести соответствующую поправку. Оценка трудозатрат Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 227/298 • Принимайте во внимание не зависящие от вас обстоятельства. Например, вы точно уверены, что выполните тестирование очередного билда за 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 344 ». Структурная декомпозиция (work breakdown structure, WBS 345 ) — иерар- хическая декомпозиция объёмных задач на всё более и более малые под- задачи с целью упрощения оценки, планирования и мониторинга выпол- нения работы. 344 «Software Estimation Techniques - Common Test Estimation Techniques used in SDLC» [ http://www.softwaretest- ingclass.com/software-estimation-techniques/ ] 345 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–2022 Стр: 228/298 В процессе выполнения структурной декомпозиции большие задачи делятся на всё более и более мелкие подзадачи, что позволяет нам: • описать весь объём работ с точностью, достаточной для чёткого понимания сути задач, формирования достаточно точной оценки трудозатрат и выра- ботки показателей достижения результатов; • определить весь объём трудозатрат как сумму трудозатрат по отдельным за- дачам (с учётом необходимых поправок); • от интуитивного представления перейти к конкретному перечню отдельных действий, что упрощает построение плана, принятие решений о распаралле- ливании работ и т.д. Сейчас мы рассмотрим применение структурной декомпозиции в сочетании с упрощённым взглядом на оценку трудозатрат на основе требований и тест-кей- сов. С подробной теорией по данному вопросу можно ознакомиться в следую- щих статьях: • «Test Effort Estimation Using Use Case Points 346 », Suresh Nageswaran. • «Test Case Point Analysis 347 », Nirav Patel. Если абстрагироваться от научного подхода и формул, то суть такой оценки сводится к следующим шагам: • декомпозиции требований до уровня, на котором появляется возможность создания качественных чек-листов; • декомпозиции задач по тестированию каждого пункта чек-листа до уровня «тестировщицких действий» (создание тест-кейсов, выполнение тест-кейсов, создание отчётов о дефектах и т.д.); • выполнению оценки с учётом собственной производительности. Рассмотрим этот подход на примере тестирования требования ДС-2.4 {59} : «При указании неверного значения любого из параметров командной строки прило- жение должно завершить работу, выдав сообщение об использовании (ДС-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 ». 346 «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 ] 347 «Test Case Point Analysis», Nirav Patel [ http://www.stickyminds.com/sites/default/files/article/file/2013/XUS373692file1_0.pdf ] |