Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
2.5.3. Атрибуты (поля) отчёта о дефекте В зависимости от инструментального средства управления отчётами о де- фектах внешний вид их записи может немного отличаться, могут быть добавлены или убраны отдельные поля, но концепция остаётся неизменной. Общий вид всей структуры отчёта о дефекте представлен на рисунке 2.5.e. 19 Бесконечный цикл об- работки входного файла с атрибутом «только для чтения» Если у входного файла выставлен атрибут «только для чтения», по- сле обработки приложению не уда- ётся переместить его в каталог- приёмник: создаётся копия файла, но оригинал не удаляется, и при- ложение снова и снова обрабаты- вает этот файл и безуспешно пы- тается переместить его в каталог- приёмник. Ожидаемый результат: после об- работки файл перемещён из ката- лога-источника в каталог-приём- ник. Фактический результат: обрабо- танный файл копируется в ката- лог-приёмник, но его оригинал остаётся в каталоге-источнике. Требование: ДС-2.1 1. Поместить в каталог-ис- точник файл допусти- мого типа и размера. 2. Установить данному файлу атрибут «только для чтения». 3. Запустить приложение. Дефект: обработанный файл появляется в ка- талоге-приёмнике, но не удаляется из ката- лога-источника, файл в каталоге-приёмнике непрерывно обновля- ется (видно по значе- нию времени послед- него изменения). Всегда Средняя Обычная Некорректная операция Нет Если заказчик не планирует использовать установку ат- рибута «только для чтения» файлам в каталоге-источ- нике для достижения неких своих целей, можно просто снимать этот атрибут и спо- койно перемещать файл. - Рисунок 2.5.e — Общий вид отчёта о дефекте Задание 2.5.a: как вы думаете, почему этот отчёт о дефекте можно по формальным признакам отклонить с резолюцией «не является дефек- том»? Теперь рассмотрим каждый атрибут подробно. Идентификатор Краткое описание Подробное описание Шаги по воспроизведению Воспроизводимость Важность Срочность Симптом Возможность обойти Комментарий Приложения Атрибуты (поля) отчёта о дефекте Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 172/298 Идентификатор (identifier) представляет собой уникальное значение, позво- ляющее однозначно отличить один отчёт о дефекте от другого и используемое во всевозможных ссылках. В общем случае идентификатор отчёта о дефекте может представлять собой просто уникальный номер, но (если позволяет инструменталь- ное средство управления отчётами) может быть и куда сложнее: включать пре- фиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро опреде- лить суть дефекта и часть приложения (или требований), к которой он относится. Краткое описание (summary) должно в предельно лаконичной форме давать исчерпывающий ответ на вопросы «Что произошло?» «Где это произошло»? «При каких условиях это произошло?». Например: «Отсутствует логотип на странице приветствия, если пользователь является администратором»: • Что произошло? Отсутствует логотип. • Где это произошло? На странице приветствия. • При каких условиях это произошло? Если пользователь является админи- стратором. Одной из самых больших проблем для начинающих тестировщиков является именно заполнение поля «краткое описание», которое одновременно должно: • содержать предельно краткую, но в то же время достаточную для понимания сути проблемы информацию о дефекте; • отвечать на только что упомянутые вопросы («что, где и при каких условиях случилось») или как минимум на те 1–2 вопроса, которые применимы к кон- кретной ситуации; • быть достаточно коротким, чтобы полностью помещаться на экране (в тех системах управления отчётами о дефектах, где конец этого поля обрезается или приводит к появлению скроллинга); • при необходимости содержать информацию об окружении, под которым был обнаружен дефект; • по возможности не дублировать краткие описания других дефектов (и даже не быть похожими на них), чтобы дефекты было сложно перепутать или по- считать дубликатами друг друга; • быть законченным предложением русского или английского (или иного) языка, построенным по соответствующим правилам грамматики. Для создания хороших кратких описаний дефектов рекомендуется пользо- ваться следующим алгоритмом: 1. Полноценно понять суть проблемы. До тех пор, пока у тестировщика нет чёт- кого, кристально чистого понимания того, «что сломалось», писать отчёт о дефекте вообще едва ли стоит. 2. Сформулировать подробное описание (description) дефекта — сначала без оглядки на длину получившегося текста. 3. Убрать из получившегося подробного описания всё лишнее, уточнить важ- ные детали. 4. Выделить в подробном описании слова (словосочетания, фрагменты фраз), отвечающие на вопросы, «что, где и при каких условиях случилось». 5. Оформить получившееся в пункте 4 в виде законченного грамматически пра- вильного предложения. 6. Если предложение получилось слишком длинным, переформулировать его, сократив длину (за счёт подбора синонимов, использования общепринятых аббревиатур и сокращений). К слову, в английском языке предложение почти всегда будет короче русского аналога. Атрибуты (поля) отчёта о дефекте Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 173/298 Рассмотрим несколько примеров применения этого алгоритма. Ситуация 1. Тестированию подвергается некое веб-приложение, поле опи- сания товара должно допускать ввод максимум 250 символов; в процессе тестиро- вания оказалось, что этого ограничения нет. 1. Суть проблемы: исследование показало, что ни на клиентской, ни на сервер- ной части нет никаких механизмов, проверяющих и/или ограничивающих длину введённых в поле «О товаре» данных. 2. Исходный вариант подробного описания: в клиентской и серверной части приложения отсутствуют проверка и ограничение длины данных, вводимых в поле «О товаре» на странице http://testapplication/admin/goods/edit/. 3. Конечный вариант подробного описания: • Фактический результат: в описании товара (поле «О товаре», http://testapplication/admin/goods/edit/ ) отсутствуют проверка и ограни- чение длины вводимого текста (MAX=250 символов). • Ожидаемый результат: в случае попытки ввода 251+ символов выво- дится сообщение об ошибке. 4. Определение «что, где и при каких условиях случилось»: • Что: отсутствуют проверка и ограничение длины вводимого текста. • Где: описание товара, поле «О товаре», http://testapplication/ad- min/goods/edit/. • При каких условиях: – (в данном случае дефект присутствует всегда, вне зависимости от каких бы то ни было особых условий). 5. Первичная формулировка: отсутствуют проверка и ограничение максималь- ной длины текста, вводимого в поле «О товаре» описания товара. 6. Сокращение (итоговое краткое описание): нет ограничения максимальной длины поля «О товаре». Английский вариант: no check for «О товаре» max length. Ситуация 2. Попытка открыть в приложении пустой файл приводит к краху клиентской части приложения и потере несохранённых пользовательских данных на сервере. 1. Суть проблемы: клиентская часть приложения начинает «вслепую» читать заголовок файла, не проверяя ни размер, ни корректность формата, ничего; возникает некая внутренняя ошибка, и клиентская часть приложения некор- ректно прекращает работу, не закрыв сессию с сервером; сервер закрывает сессию по таймауту (повторный запуск клиентской части запускает новую сессию, так что старая сессия и все данные в ней в любом случае утеряны). 2. Исходный вариант подробного описания: некорректный анализ открывае- мого клиентом файла приводит к краху клиента и необратимой утере теку- щей сессии с сервером. 3. Конечный вариант подробного описания: • Фактический результат: отсутствие проверки корректности открывае- мого клиентской частью приложения файла (в том числе пустого) при- водит к краху клиентской части и необратимой потере текущей сессии с сервером (см. BR852345). • Ожидаемый результат: производится анализ структуры открываемого файла; в случае обнаружения проблем отображается сообщение о не- возможности открытия файла. 4. Определение «что, где и при каких условиях случилось»: • Что: крах клиентской части приложения. • Где: – (конкретное место в приложении определить едва ли возможно). • При каких условиях: при открытии пустого или повреждённого файла. Атрибуты (поля) отчёта о дефекте Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 174/298 5. Первичная формулировка: отсутствие проверки корректности открываемого файла приводит к краху клиентской части приложения и потере пользова- тельских данных. 6. Сокращение (итоговое краткое описание): крах клиента и потеря данных при открытии повреждённых файлов. Английский вариант: client crash and data loss on damaged/empty files opening. Ситуация 3. Крайне редко по совершенно непонятным причинам на сайте нарушается отображение всего русского текста (как статических надписей, так и данных из базы данных, генерируемых динамически и т.д. — всё «становится во- просиками»). 1. Суть проблемы: фреймворк, на котором построен сайт, подгружает специфи- ческие шрифты с удалённого сервера; если соединение обрывается, нужные шрифты не подгружаются, и используются шрифты по умолчанию, в которых нет русских символов. 2. Исходный вариант подробного описания: ошибка загрузки шрифтов с удалён- ного сервера приводит к использованию локальных несовместимых с требу- емой кодировкой шрифтов. 3. Конечный вариант подробного описания: • Фактический результат: периодическая невозможность загрузить шрифты с удалённого сервера приводит к использованию локальных шрифтов, несовместимых с требуемой кодировкой. • Ожидаемый результат: необходимые шрифты подгружаются всегда (или используется локальный источник необходимых шрифтов). 4. Определение «что, где и при каких условиях случилось»: • Что: используются несовместимые с требуемой кодировкой шрифты. • Где: – (по всему сайту). • При каких условиях: в случае ошибки соединения с сервером, с кото- рого подгружаются шрифты. 5. Первичная формулировка: периодические сбои внешнего источника шриф- тов приводят к сбою отображения русского текста. 6. Сокращение (итоговое краткое описание): неверный показ русского текста при недоступности внешних шрифтов. Английский вариант: wrong presenta- tion of Russian text in case of external fonts inaccessibility. Для закрепления материала ещё раз представим эти три ситуации в виде таблицы 2.5.a. Атрибуты (поля) отчёта о дефекте Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 175/298 Таблица 2.5.a — Проблемные ситуации и формулировки кратких описаний дефек- тов Ситуация Русский вариант крат- кого описания Английский вариант краткого описания Тестированию подвергается некое веб- приложение, поле описания товара должно допускать ввод максимум 250 символов; в процессе тестирования ока- залось, что этого ограничения нет. Нет ограничения макси- мальной длины поля «О товаре». No check for «О товаре» max length. Попытка открыть в приложении пустой файл приводит к краху клиентской части приложения и потере несохранённых пользовательских данных на сервере. Крах клиента и потеря данных при открытии по- вреждённых/пустых фай- лов. Client crash and data loss on damaged/empty files opening. Крайне редко по совершенно непонят- ным причинам на сайте нарушается отображение всего русского текста (как статических надписей, так и данных из базы данных, генерируемых динамиче- ски и т.д. — всё «становится вопроси- ками»). Неверный показ русского текста при недоступности внешних шрифтов. Wrong presentation of Russian text in case of external fonts inaccessi- bility. Возвращаемся к рассмотрению полей отчёта о дефекте. Подробное описание (description) представляет в развёрнутом виде необ- ходимую информацию о дефекте, а также (обязательно!) описание фактического результата, ожидаемого результата и ссылку на требование (если это возможно). Пример подробного описания: Если в систему входит администратор, на странице приветствия отсут- ствует логотип. Фактический результат: логотип отсутствует в левом верхнем углу стра- ницы. Ожидаемый результат: логотип отображается в левом верхнем углу стра- ницы. Требование: R245.3.23b. В отличие от краткого описания, которое, как правило, является одним пред- ложением, здесь можно и нужно давать подробную информацию. Если одна и та же проблема (вызванная одним источником) проявляется в нескольких местах при- ложения, можно в подробном описании перечислить эти места. Шаги по воспроизведению (steps to reproduce, STR) описывают действия, которые необходимо выполнить для воспроизведения дефекта. Это поле похоже на шаги тест-кейса, за исключением одного важного отличия: здесь действия про- писываются максимально подробно, с указанием конкретных вводимых значений и самых мелких деталей, т.к. отсутствие этой информации в сложных случаях может привести к невозможности воспроизведения дефекта. Пример шагов воспроизведения: 1. Открыть http://testapplication/admin/login/. 2. Авторизоваться с именем «defaultadmin» и паролем «dapassword». Дефект: в левом верхнем углу страницы отсутствует логотип (вместо него отображается пустое пространство с надписью «logo»). Атрибуты (поля) отчёта о дефекте Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 176/298 Воспроизводимость (reproducibility) показывает, при каждом ли прохожде- нии по шагам воспроизведения дефекта удаётся вызвать его проявление. Это поле принимает всего два значения: всегда (always) или иногда (sometimes). Можно сказать, что воспроизводимость «иногда» означает, что тестировщик не нашёл настоящую причину возникновения дефекта. Это приводит к серьёзным дополнительным сложностям в работе с дефектом: • Тестировщику нужно потратить много времени на то, чтобы удостовериться в наличии дефекта (т.к. однократный сбой в работе приложения мог быть вы- зван огромным количеством посторонних причин). • Разработчику тоже нужно потратить время, чтобы добиться проявления де- фекта и убедиться в его наличии. После внесения исправлений в приложение разработчик фактически должен полагаться только на свой профессиона- лизм, т.к. даже многократное прохождение по шагам воспроизведения в та- ком случае не гарантирует, что дефект был исправлен (возможно, через ещё 10 –20 повторений он бы проявился). • Тестировщику, верифицирующему исправление дефекта и вовсе остаётся верить разработчику на слово по той же самой причине: даже если он попы- тается воспроизвести дефект 100 раз и потом прекратит попытки, может так случиться, что на 101-й раз дефект всё же воспроизвёлся бы. Как легко догадаться, такая ситуация является крайне неприятной, а потому рекомендуется один раз потратить время на тщательную диагностику проблемы, найти её причину и перевести дефект в разряд воспроизводимых всегда. Важность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. В общем случае выделяют следующие градации важности: • Критическая (critical) — существование дефекта приводит к масштабным по- следствиям катастрофического характера, например: потеря данных, рас- крытие конфиденциальной информации, нарушение ключевой функциональ- ности приложения и т.д. • Высокая (major) — существование дефекта приносит ощутимые неудобства многим пользователям в рамках их типичной деятельности, например: недо- ступность вставки из буфера обмена, неработоспособность общепринятых клавиатурных комбинаций, необходимость перезапуска приложения при вы- полнении типичных сценариев работы. • Средняя (medium) — существование дефекта слабо влияет на типичные сце- нарии работы пользователей, и/или существует обходной путь достижения цели, например: диалоговое окно не закрывается автоматически после нажа- тия кнопок «OK»/«Cancel», при распечатке нескольких документов подряд не сохраняется значение поля «Двусторонняя печать», перепутаны направле- ния сортировок по некоему полю таблицы. • Низкая (minor) — существование дефекта редко обнаруживается незначи- тельным процентом пользователей и (почти) не влияет на их работу, напри- мер: опечатка в глубоко вложенном пункте меню настроек, некое окно сразу при отображении расположено неудобно (нужно перетянуть его в удобное место), неточно отображается время до завершения операции копирования файлов. Атрибуты (поля) отчёта о дефекте Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 177/298 Срочность (priority) показывает, как быстро дефект должен быть устранён. В общем случае выделяют следующие градации срочности: • Наивысшая (ASAP, as soon as possible) срочность указывает на необходи- мость устранить дефект настолько быстро, насколько это возможно. В зави- симости от контекста «настолько быстро, насколько возможно» может варь- ироваться от «в ближайшем билде» до единиц минут. • Высокая (high) срочность означает, что дефект следует исправить вне оче- реди, т.к. его существование или уже объективно мешает работе, или начнёт создавать такие помехи в самом ближайшем будущем. • Обычная (normal) срочность означает, что дефект следует исправить в по- рядке общей очерёдности. Такое значение срочности получает большинство дефектов. • Низкая (low) срочность означает, что в обозримом будущем исправление данного дефекта не окажет существенного влияния на повышение качества продукта. Несколько дополнительных рассуждений о важности и срочности стоит рассмотреть отдельно. Один из самых частых вопросов относится к тому, какая между ними связь. Никакой. Для лучшего понимания этого факта можно сравнить важность и сроч- ность с координатами X и Y точки на плоскости. Хоть «на бытовом уровне» и ка- жется, что дефект с высокой важностью следует исправить в первую очередь, в реальности ситуация может выглядеть совсем иначе. Чтобы проиллюстрировать эту мысль подробнее, вернёмся к перечню града- ций: заметили ли вы, что для разных степеней важности примеры приведены, а для разных степеней срочности — нет? И это не случайно. Зная суть проекта и суть дефекта, его важность определить достаточно легко, т.к. мы можем проследить влияние дефекта на критерии качества, степень выполнения требований той или иной важности и т.д. Но срочность исправления дефекта можно определить только в конкретной ситуации. Поясним на жизненном примере: насколько для жизни человека важна вода? Очень важна, без воды человек умирает. Значит, важность воды для человека можно оценить как критическую. Но можем ли мы ответить на вопрос «Как быстро человеку нужно выпить воды?», не зная, о какой ситуации идёт речь? Если рассмат- риваемый человек умирает от жажды в пустыне, срочность будет наивысшей. Если он просто сидит в офисе и думает, не попить ли чая, срочность будет обычной или даже низкой. Вернёмся к примерам из разработки программного обеспечения и покажем четыре случая сочетания важности и срочности в таблице 2.5.b. Таблица 2.5.b — Примеры сочетания важности и срочности дефектов |