Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Ресурсы • Программные ресурсы: четыре виртуальных машины (две с ОС Windows 7 Ent x64, две с ОС Linux Ubuntu 14 LTS x64), две копии PHP Storm 8. • Аппаратные ресурсы: две стандартных рабочих станции (8GB RAM, i7 3GHz). Тест-план и отчёт о результатах тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 215/298 • Человеческие ресурсы: o Старший разработчик с опытом тестирования (100%-я занятость на всём протяжении проекта). Роли на проекте: лидер команды, старший разработчик. o Тестировщик со знанием PHP (100%-я занятость на всём протяжении проекта). Роль на проекте: тестировщик. • Временные ресурсы: одна рабочая неделя (40 часов). • Финансовые ресурсы: согласно утверждённому бюджету. Дополнительные финансовые ресурсы не требуются. Расписание • 25.05 — формирование требований. • 26.05 — разработка тест-кейсов и скриптов для автоматизированного тести- рования. • 27.05–28.05 — основная фаза тестирования (выполнение тест-кейсов, напи- сание отчётов о дефектах). • 29.05 — завершение тестирования и подведение итогов. Роли и ответственность • Старший разработчик: участие в формировании требований, участие в аудите кода. • Тестировщик: формирование тестовой документации, реализация тестиро- вания, участие в аудите кода. Оценка рисков • Персонал (вероятность низкая): в случае нетрудоспособности какого-либо из участников команды можно обратиться к представителям проекта «Катало- гизатор» для предоставления временной замены (договорённость с мене- джером «Каталогизатора» Джоном Смитом достигнута). • Время (вероятность высокая): заказчиком обозначен крайний срок сдачи 01.06, потому время является критическим ресурсом. Рекомендуется прило- жить максимум усилий к тому, чтобы фактически завершить проект 28.05 с тем, чтобы один день (29.05) остался в запасе. • Иные риски: иных специфических рисков не выявлено. Документация • Требования. Ответственный — тестировщик, дата готовности 25.05. • Тест-кейсы и отчёты о дефектах. Ответственный — тестировщик, период со- здания 26.05–28.05. • Отчёт о результатах тестирования. Ответственный — тестировщик, дата го- товности 29.05. Метрики • Успешное прохождение тест-кейсов: 𝑇 𝑆𝑃 = 𝑇 𝑆𝑢𝑐𝑐𝑒𝑠𝑠 𝑇 𝑇𝑜𝑡𝑎𝑙 ∙ 100%, где 𝑇 𝑆𝑃 — процентный показатель успешного прохождения тест-кейсов, 𝑇 𝑆𝑢𝑐𝑐𝑒𝑠𝑠 — количество успешно выполненных тест-кейсов, 𝑇 𝑇𝑜𝑡𝑎𝑙 — общее количество выполненных тест-кейсов. Минимальные границы значений: o Начальная фаза проекта: 10%. o Основная фаза проекта: 40%. o Финальная фаза проекта: 80%. Тест-план и отчёт о результатах тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 216/298 • Общее устранение дефектов: 𝐷 𝐿𝑒𝑣𝑒𝑙 𝐹𝑇𝑃 = 𝐷 𝐿𝑒𝑣𝑒𝑙 𝐶𝑙𝑜𝑠𝑒𝑑 𝐷 𝐿𝑒𝑣𝑒𝑙 𝐹𝑜𝑢𝑛𝑑 ∙ 100%, где 𝐷 𝐿𝑒𝑣𝑒𝑙 𝐹𝑇𝑃 — процентный показатель устранения дефектов уровня важности 𝐿𝑒𝑣𝑒𝑙 за время существования проекта 𝐷 𝐿𝑒𝑣𝑒𝑙 𝐶𝑙𝑜𝑠𝑒𝑑 — количество устранённых за время существования проекта дефектов уровня важности 𝐿𝑒𝑣𝑒𝑙, 𝐷 𝐿𝑒𝑣𝑒𝑙 𝐹𝑜𝑢𝑛𝑑 — количество обнаруженных за время существования проекта дефектов уровня важности 𝐿𝑒𝑣𝑒𝑙. Минимальные границы значений: Важность дефекта Низкая Средняя Высокая Критическая Фаза проекта Начальная 10% 40% 50% 80% Основная 15% 50% 75% 90% Финальная 20% 60% 100% 100% • Текущее устранение дефектов: 𝐷 𝐿𝑒𝑣𝑒𝑙 𝐹𝐶𝑃 = 𝐷 𝐿𝑒𝑣𝑒𝑙 𝐶𝑙𝑜𝑠𝑒𝑑 𝐷 𝐿𝑒𝑣𝑒𝑙 𝐹𝑜𝑢𝑛𝑑 ∙ 100%, где 𝐷 𝐿𝑒𝑣𝑒𝑙 𝐹𝐶𝑃 — процентный показатель устранения в текущем билде дефектов уровня важности 𝐿𝑒𝑣𝑒𝑙, обнаруженных в предыдущем билде, 𝐷 𝐿𝑒𝑣𝑒𝑙 𝐶𝑙𝑜𝑠𝑒𝑑 — количество устранённых в текущем билде дефектов уровня важности 𝐿𝑒𝑣𝑒𝑙, 𝐷 𝐿𝑒𝑣𝑒𝑙 𝐹𝑜𝑢𝑛𝑑 — количество обнаруженных в предыдущем билде дефектов уровня важности 𝐿𝑒𝑣𝑒𝑙. Минимальные границы значений: Важность дефекта Низкая Средняя Высокая Критическая Фаза проекта Начальная 60% 60% 60% 60% Основная 65% 70% 85% 90% Финальная 70% 80% 95% 100% • Стоп-фактор: 𝑆 = { 𝑌𝑒𝑠, 𝑇 𝐸 ≥ 25% && 𝑇 𝑆𝑃 < 50% 𝑁𝑜, 𝑇 𝐸 < 25% || 𝑇 𝑆𝑃 ≥ 50% , где 𝑆— решение о приостановке тестирования, 𝑇 𝐸 — текущее значение метрики 𝑇 𝐸 , 𝑇 𝑆𝑃 — текущее значение метрики 𝑇 𝑆𝑃 • Выполнение тест-кейсов: 𝑇 𝐸 = 𝑇 𝐸𝑥𝑒𝑐𝑢𝑡𝑒𝑑 𝑇 𝑃𝑙𝑎𝑛𝑛𝑒𝑑 ∙ 100%, где 𝑇 𝐸 — процентный показатель выполнения тест-кейсов, 𝑇 𝐸𝑥𝑒𝑐𝑢𝑡𝑒𝑑 — количество выполненных тест-кейсов, 𝑇 𝑃𝑙𝑎𝑛𝑛𝑒𝑑 — количество тест-кейсов, запланированных к выполнению. Уровни (границы): o Минимальный уровень: 80 %. o Желаемый уровень: 95–100 %. • Покрытие требований тест-кейсами: 𝑅 𝐶 = 𝑅 𝐶𝑜𝑣𝑒𝑟𝑒𝑑 𝑅 𝑇𝑜𝑡𝑎𝑙 ∙ 100%, где 𝑅 𝐶 — процентный показатель покрытия требования тест-кейсами, 𝑅 𝐶𝑜𝑣𝑒𝑟𝑒𝑑 — количество покрытых тест-кейсами требований, 𝑅 𝑇𝑜𝑡𝑎𝑙 — общее количество требований. Минимальные границы значений: o Начальная фаза проекта: 40 %. o Основная фаза проекта: 60 %. o Финальная фаза проекта: 80 % (рекомендуется 90 % и более). Тест-план и отчёт о результатах тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 217/298 Задание 2.6.a: поищите в Интернет более развёрнутые примеры тест- планов. Они периодически появляются, но и столь же быстро удаляются, т.к. настоящие (не учебные) тест-планы, как правило, являются конфиден- циальной информацией. На этом мы завершаем обсуждение планирования и переходим к отчётности, которая завершает цикл тестирования. Отчёт о результатах тестирования Отчёт о результатах тестирования (test progress report 341 , test summary report 342 ) — документ, обобщающий результаты работ по тестированию и содержащий информацию, достаточную для соотнесения текущей ситуа- ции с тест-планом и принятия необходимых управленческих решений. К низкоуровневым задачам отчётности в тестировании относятся: • оценка объёма и качества выполненных работ; • сравнение текущего прогресса с тест-планом (в том числе с помощью ана- лиза значений метрик); • описание имеющихся сложностей и формирование рекомендаций по их устранению; • предоставление лицам, заинтересованным в проекте, полной и объективной информации о текущем состоянии качества проекта, выраженной в конкрет- ных фактах и числах. Как и любой другой документ, отчёт о результатах тестирования может быть качественным или обладать недостатками. Качественный отчёт о результатах те- стирования обладает многими свойствами качественных требований {41} , а также расширяет их набор следующими пунктами: • Информативность (в идеале после прочтения отчёта не должно оставаться никаких открытых вопросов о том, что происходит с проектом в контексте ка- чества). • Точность и объективность (ни при каких условиях в отчёте не допускается искажение фактов, а личные мнения должны быть подкреплены твёрдыми обоснованиями). Отчёт о результатах тестирования создаётся по заранее оговорённому рас- писанию (зависящему от модели управления проектом) при участии большинства представителей проектной команды, задействованных в обеспечении качества. Большое количество фактических данных для отчёта может быть легко извлечено в удобной форме из системы управления проектом. Ответственным за создание отчёта, как правило, является ведущий тестировщик («тест-лид»). При необходи- мости отчёт может обсуждаться на небольших собраниях. Отчёт о результатах тестирования в первую очередь нужен следующим ли- цам: • менеджеру проекта — как источник информации о текущей ситуации и ос- нова для принятия управленческих решений; • руководителю команды разработчиков («дев-лиду») — как дополнительный объективный взгляд на происходящее на проекте; 341 Test progress report. A document summarizing testing activities and results, produced at regular intervals, to report progress of testing activities against a baseline (such as the original test plan) and to communicate risks and alternatives requiring a decision to management. [ISTQB Glossary] 342 Test summary report. A document summarizing testing activities and results. It also contains an evaluation of the corresponding test items against exit criteria. [ISTQB Glossary] Тест-план и отчёт о результатах тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 218/298 • руководителю команды тестировщиков («тест-лиду») — как способ структу- рировать собственные мысли и собрать необходимый материал для обра- щения к менеджеру проекта по насущным вопросам, если в этом есть необ- ходимость; • заказчику — как наиболее объективный источник информации о том, что про- исходит на проекте, за который он платит свои деньги. В общем случае отчёт о результатах тестирования включает следующие раз- делы (примеры их наполнения будут показаны далее, потому здесь — только пере- числение). Важно! Если по поводу тест-плана в сообществе тестировщиков есть бо- лее-менее устоявшееся мнение, то формы отчётов о результатах тести- рования исчисляются десятками (особенно, если отчёт привязан к некото- рому отдельному виду тестирования). Здесь приведён наиболее универ- сальный вариант, который может быть адаптирован под конкретные нужды. • Краткое описание (summary). В предельно краткой форме отражает основ- ные достижения, проблемы, выводы и рекомендации. В идеальном случае прочтения краткого описания может быть достаточно для формирования полноценного представления о происходящем, что избавит от необходимо- сти читать весь отчёт (это важно, т.к. отчёт о результатах тестирования мо- жет попадать в руки очень занятым людям). Важно! Различайте краткое описание отчёта о результатах тестиро- вания и краткое описание отчёта о дефекте {172} ! При одинаковом названии они создаются по разным принципам и содержат разную информацию! • Команда тестировщиков (test team). Список участников проектной команды, задействованных в обеспечении качества, с указанием их должностей и ро- лей в подотчётный период. • Описание процесса тестирования (testing process description). Последова- тельное описание того, какие работы были выполнены за подотчётный пе- риод. • Расписание (timetable). Детализированное расписание работы команды те- стировщиков и/или личные расписания участников команды. • Статистика по новым дефектам (new defects statistics). Таблица, в которой представлены данные по обнаруженным за подотчётный период дефектам (с классификацией по стадии жизненного цикла и важности). • Список новых дефектов (new defects list). Список обнаруженных за подот- чётный период дефектов с их краткими описаниями и важностью. • Статистика по всем дефектам (overall defects statistics). Таблица, в которой представлены данные по обнаруженным за всё время существования про- екта дефектам (с классификацией по стадии жизненного цикла и важности). Как правило, в этот же раздел добавляется график, отражающий такие ста- тистические данные. • Рекомендации (recommendations). Обоснованные выводы и рекомендации по принятию тех или иных управленческих решений (изменению тест-плана, запросу или освобождению ресурсов и т.д.). Здесь этой информации можно отвести больше места, чем в кратком описании (summary), сделав акцент именно на том, что и почему рекомендуется сделать в имеющейся ситуации. Тест-план и отчёт о результатах тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 219/298 • Приложения (appendixes). Фактические данные (как правило, значения мет- рик и графическое представление их изменения во времени). Логика построения отчёта о результатах тестирования Для того чтобы отчёт о результатах тестирования был действительно полез- ным, при его создании следует постоянно помнить об универсальной логике отчёт- ности (см. рисунок 2.6.b), особенно актуальной для таких разделов отчёта о резуль- татах тестирования, как краткое описание (summary) и рекомендации (recommendations): • Выводы строятся на основе целей (которые были отражены в плане). • Выводы дополняются рекомендациями. • Как выводы, так и рекомендации строго обосновываются. • Обоснование опирается на объективные факты. Рисунок 2.6.b — Универсальная логика отчётности Выводы должны быть: • Краткими. Сравните: Плохо Хорошо 1.17. Как показал глубокий анализ протоко- лов о выполнении тестирования, можно сделать достаточно уверенные выводы о том, что основная часть функций, отмечен- ных заказчиком как наиболее важные, функ- ционирует в рамках допустимых отклоне- ний от согласованных на последнем обсуж- дении с заказчиком метрик качества. 1.11. Базовая функциональность полно- стью работоспособна (см. 2.1–2.2). 1.23. Существуют некритические проблемы с детализацией сообщений в файле жур- нала (см. 2.3–2.4). 1.28. Тестирование приложения под ОС Linux не удалось провести из-за недоступ- ности сервера SR-85 (см. 2.5). • Информативными. Сравните: Плохо Хорошо 1.8. Результаты обработки файлов с множе- ственными кодировками, представленными в сопоставимых пропорциях, оставляют же- лать лучшего. 1.9. Приложение не запускается при некото- рых значениях параметров командной строки. 1.10. Непонятно, что происходит с анализом изменения содержимого входного каталога. 1.8. Обнаружены серьёзные проблемы с библиотекой распознавания кодировок (см. BR 834). 1.9. Нарушена функциональность анализа параметров командной строки (см. BR 745, BR 877, BR 878). 1.10. Выявлена нестабильность в работе модуля «Сканер», проводятся дополни- тельные исследования. Фактический материал Обоснование Выводы Рекомендации На основе целей Тест-план и отчёт о результатах тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 220/298 • Полезными для читающего отчёт. Сравните: Плохо Хорошо 1.18. Некоторые тесты прошли на удивле- ние хорошо. 1.19. В процессе тестирования мы не испы- тывали сложности с настройкой среды ав- томатизации. 1.20. По сравнению с результатами, кото- рые были получены вчера, ситуация не- много улучшилась. 1.21. С качеством по-прежнему есть некото- рые проблемы. 1.22. Часть команды была в отпуске, но мы всё равно справились. Представленного в колонке «Плохо» просто не должно быть в отчёте! Рекомендации должны быть: • Краткими. Да, мы снова говорим о краткости, т.к. её отсутствием страдает слишком большое количество документов. Сравните: Плохо Хорошо 2.98. Мы рекомендуем рассмотреть воз- можные варианты исправления данной си- туации в контексте поиска оптимального решения при условии минимизации усилий разработчиков и максимального повыше- ния соответствия приложения заявленным критериям качества, а именно: исследо- вать возможность замены некоторых биб- лиотек их более качественными анало- гами. 2.98. Необходимо изменить способ опреде- ления кодировки текста в документе. Воз- можные решения: • [сложно, надёжно, но очень долго] напи- сать собственное решение; • [требует дополнительного исследования и согласования] заменить проблемную биб- лиотеку «cflk_n_r_coding» аналогом (воз- можно, коммерческим). • Реально выполнимыми. Сравните: Плохо Хорошо 2.107. Использовать механизм обработки слов, аналогичный используемому в Google. 2.304. Не загружать в оперативную память информацию о файлах во входном ката- логе. 2.402. Полностью переписать проект без использования внешних библиотек. 2.107. Реализовать алгоритм приведения слов русского языка к именительному па- дежу (см. описание по ссылке …) 2.304. Увеличить размер доступной скрипту оперативной памяти на 40-50% (в идеале — до 512 МБ). 2.402. Заменить собственными решениями функции анализа содержимого каталога и параметров файлов библиотеки «cflk_n_r_flstm». Тест-план и отчёт о результатах тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 221/298 • Дающими как понимание того, что надо сделать, так и некоторое простран- ство для принятия собственных решений. Сравните: Плохо Хорошо 2.212. Рекомендуем поискать варианты ре- шения этого вопроса. 2.245. Использовать только дисковую сор- тировку. 2.278. Исключить возможность передачи некорректных имён файла журнала через параметр командной строки. 2.212. Возможные варианты решения: а) … б) [рекомендуем!] … в) … 2.245. Добавить функциональность опреде- ления оптимального метода сортировки в зависимости от количества доступной опе- ративной памяти. 2.278. Добавить фильтрацию имени файла журнала, получаемого через параметр ко- мандной строки, с помощью регулярного выражения. Обоснование выводов и рекомендаций — промежуточное звено между пре- дельно сжатыми результатами анализа и огромным количеством фактических дан- ных. Оно даёт ответы на вопросы наподобие: • «Почему мы так считаем?» • «Неужели это так?!» • «Где взять дополнительные данные?» Сравните: Плохо Хорошо 4.107. Покрытие требований тест-кейсами достаточно. 4.304. Необходимо больше усилий напра- вить на регрессионное тестирование. 4.402. От сокращения сроков разработки стоит отказаться. 4.107. Покрытие требований тест-кейсами вышло на достаточный уровень (значение 𝑅 𝐶 составило 63 % при заявленном мини- муме 60 % для текущей стадии проекта). 4.304. Необходимо больше усилий напра- вить на регрессионное тестирование, т.к. две предыдущих итерации выявили 21 де- фект высокой важности (см. список в 5.43) в функциональности, в которой ранее не об- наруживалось проблем. 4.402. От сокращения сроков разработки стоит отказаться, т.к. текущее опережение графика на 30 человеко-часов может быть легко поглощено на стадии реализации тре- бований R84.* и R89.*. |