Файл: Обеспечения Базовый курс (3е издание) Версия книги 2 от 17. 04. 2023.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 07.11.2023
Просмотров: 874
Скачиваний: 31
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
Ситуация 2. Попытка открыть в приложении пустой файл приводит к краху клиентской части приложения и потере несохранённых пользовательских данных на сервере.
1.
Суть проблемы: клиентская часть приложения начинает «вслепую» читать заголовок файла, не проверяя ни размер, ни корректность формата, ничего; возникает некая внутренняя ошибка, и клиентская часть приложения некор- ректно прекращает работу, не закрыв сессию с сервером; сервер закрывает сессию по таймауту (повторный запуск клиентской части запускает новую сессию, так что старая сессия и все данные в ней в любом случае утеряны).
2.
Исходный вариант подробного описания: некорректный анализ открывае- мого клиентом файла приводит к краху клиента и необратимой утере теку- щей сессии с сервером.
3.
Конечный вариант подробного описания:
• Фактический результат: отсутствие проверки корректности открывае- мого клиентской частью приложения файла (в том числе пустого) при- водит к краху клиентской части и необратимой потере текущей сессии с сервером (см. BR852345).
• Ожидаемый результат: производится анализ структуры открываемого файла; в случае обнаружения проблем отображается сообщение о не- возможности открытия файла.
4.
Определение «что, где и при каких условиях случилось»:
• Что: крах клиентской части приложения.
• Где: – (конкретное место в приложении определить едва ли возможно).
• При каких условиях: при открытии пустого или повреждённого файла.
Атрибуты (поля) отчёта о дефекте
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 177/301 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–2023
Стр: 178/301
Таблица 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–2023
Стр: 179/301
Воспроизводимость (reproducibility) показывает, при каждом ли прохожде- нии по шагам воспроизведения дефекта удаётся вызвать его проявление. Это поле принимает всего два значения: всегда (always) или иногда (sometimes).
Можно сказать, что воспроизводимость «иногда» означает, что тестировщик не нашёл настоящую причину возникновения дефекта. Это приводит к серьёзным дополнительным сложностям в работе с дефектом:
• Тестировщику нужно потратить много времени на то, чтобы удостовериться в наличии дефекта (т.к. однократный сбой в работе приложения мог быть вы- зван огромным количеством посторонних причин).
• Разработчику тоже нужно потратить время, чтобы добиться проявления де- фекта и убедиться в его наличии. После внесения исправлений в приложение разработчик фактически должен полагаться только на свой профессиона- лизм, т.к. даже многократное прохождение по шагам воспроизведения в та- ком случае не гарантирует, что дефект был исправлен (возможно, через ещё
10
–20 повторений он бы проявился).
• Тестировщику, верифицирующему исправление дефекта и вовсе остаётся верить разработчику на слово по той же самой причине: даже если он попы- тается воспроизвести дефект 100 раз и потом прекратит попытки, может так случиться, что на 101-й раз дефект всё же воспроизвёлся бы.
Как легко догадаться, такая ситуация является крайне неприятной, а потому рекомендуется один раз потратить время на тщательную диагностику проблемы, найти её причину и перевести дефект в разряд воспроизводимых всегда.
Важность (severity) показывает степень ущерба, который наносится проекту существованием дефекта.
В общем случае выделяют следующие градации важности:
• Критическая (critical) — существование дефекта приводит к масштабным по- следствиям катастрофического характера, например: потеря данных, рас- крытие конфиденциальной информации, нарушение ключевой функциональ- ности приложения и т.д.
• Высокая (major) — существование дефекта приносит ощутимые неудобства многим пользователям в рамках их типичной деятельности, например: недо- ступность вставки из буфера обмена, неработоспособность общепринятых клавиатурных комбинаций, необходимость перезапуска приложения при вы- полнении типичных сценариев работы.
• Средняя (medium) — существование дефекта слабо влияет на типичные сце- нарии работы пользователей, и/или существует обходной путь достижения цели, например: диалоговое окно не закрывается автоматически после нажа- тия кнопок «OK»/«Cancel», при распечатке нескольких документов подряд не сохраняется значение поля «Двусторонняя печать», перепутаны направле- ния сортировок по некоему полю таблицы.
• Низкая (minor) — существование дефекта редко обнаруживается незначи- тельным процентом пользователей и (почти) не влияет на их работу, напри- мер: опечатка в глубоко вложенном пункте меню настроек, некое окно сразу при отображении расположено неудобно (нужно перетянуть его в удобное место), неточно отображается время до завершения операции копирования файлов.
Атрибуты (поля) отчёта о дефекте
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 180/301
Срочность (priority) показывает, как быстро дефект должен быть устранён.
В общем случае выделяют следующие градации срочности:
• Наивысшая (ASAP, as soon as possible) срочность указывает на необходи- мость устранить дефект настолько быстро, насколько это возможно. В зави- симости от контекста «настолько быстро, насколько возможно» может варь- ироваться от «в ближайшем билде» до единиц минут.
• Высокая (high) срочность означает, что дефект следует исправить вне оче- реди, т.к. его существование или уже объективно мешает работе, или начнёт создавать такие помехи в самом ближайшем будущем.
• Обычная (normal) срочность означает, что дефект следует исправить в по- рядке общей очерёдности. Такое значение срочности получает большинство дефектов.
• Низкая (low) срочность означает, что в обозримом будущем исправление данного дефекта не окажет существенного влияния на повышение качества продукта.
Несколько дополнительных рассуждений о важности и срочности стоит рассмотреть отдельно.
Один из самых частых вопросов относится к тому, какая между ними связь.
Никакой. Для лучшего понимания этого факта можно сравнить важность и сроч- ность с координатами X и Y точки на плоскости. Хоть «на бытовом уровне» и ка- жется, что дефект с высокой важностью следует исправить в первую очередь, в реальности ситуация может выглядеть совсем иначе.
Чтобы проиллюстрировать эту мысль подробнее, вернёмся к перечню града- ций: заметили ли вы, что для разных степеней важности примеры приведены, а для разных степеней срочности — нет? И это не случайно.
Зная суть проекта и суть дефекта, его важность определить достаточно легко, т.к. мы можем проследить влияние дефекта на критерии качества, степень выполнения требований той или иной важности и т.д. Но срочность исправления дефекта можно определить только в конкретной ситуации.
Поясним на жизненном примере: насколько для жизни человека важна вода?
Очень важна, без воды человек умирает. Значит, важность воды для человека можно оценить как критическую. Но можем ли мы ответить на вопрос «Как быстро человеку нужно выпить воды?», не зная, о какой ситуации идёт речь? Если рассмат- риваемый человек умирает от жажды в пустыне, срочность будет наивысшей. Если он просто сидит в офисе и думает, не попить ли чая, срочность будет обычной или даже низкой.
Вернёмся к примерам из разработки программного обеспечения и покажем четыре случая сочетания важности и срочности в таблице 2.5.b.
Таблица 2.5.b — Примеры сочетания важности и срочности дефектов
Важность (Severity)
Критическая (Critical)
Низкая (Minor)
Срочность
(Priority)
Наивысшая
(ASAP)
Проблемы с безопасностью во введённом в эксплуата- цию банковском ПО.
На корпоративном сайте повре- дилась картинка с фирменным логотипом.
Низкая
(Low)
В самом начале разработки проекта обнаружена ситуа- ция, при которой могут быть повреждены или вовсе уте- ряны пользовательские дан- ные.
В руководстве пользователя об- наружено несколько опечаток, не влияющих на смысл текста.
Атрибуты (поля) отчёта о дефекте
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 181/301
Симптом (symptom) — позволяет классифицировать дефекты по их типич- ному проявлению. Не существует никакого общепринятого списка симптомов. Бо- лее того, далеко не в каждом инструментальном средстве управления отчётами о дефектах есть такое поле, а там, где оно есть, его можно настроить. В качестве примера рассмотрим следующие значения симптомов дефекта.
• Косметический дефект (cosmetic flaw) — визуально заметный недостаток ин- терфейса, не влияющий на функциональность приложения (например, надпись на кнопке выполнена шрифтом не той гарнитуры).
• Повреждение/потеря данных (data corruption/loss) — в результате возникно- вения дефекта искажаются, уничтожаются (или не сохраняются) некоторые данные (например, при копировании файлов копии оказываются повреждён- ными).
• Проблема в документации (documentation issue) — дефект относится не к приложению, а к документации (например, отсутствует раздел руководства по эксплуатации).
• Некорректная операция (incorrect operation) — некоторая операция выполня- ется некорректно (например, калькулятор показывает ответ 17 при умноже- нии 2 на 3).
• Проблема инсталляции (installation problem) — дефект проявляется на ста- дии установки и/или конфигурирования приложения (см. инсталляционное тестирование
{86}
).
• Ошибка локализации (localization issue) — что-то в приложении не переве- дено или переведено неверно на выбранный язык интерфейса (см. локали- зационное тестирование
{89}
).
• Нереализованная функциональность (missing feature) — некая функция при- ложения не выполняется или не может быть вызвана (например, в списке форматов для экспорта документа отсутствует несколько пунктов, которые там должны быть).
• Проблема масштабируемости (scalability) — при увеличении количества до- ступных приложению ресурсов не происходит ожидаемого прироста произво- дительности приложения (см. тестирование производительности
{91}
и тести- рование масштабируемости
{92}
).
• Низкая производительность (low performance) — выполнение неких операций занимает недопустимо большое время (см. тестирование производительно- сти
{91}
).
• Крах системы (system crash) — приложение прекращает работу или теряет способность выполнять свои ключевые функции (также может сопровож- даться крахом операционной системы, веб-сервера и т.д.).
• Неожиданное поведение (unexpected behavior) — в процессе выполнения не- которой типичной операции приложение ведёт себя необычным (отличным от общепринятого) образом (например, после добавления в список новой за- писи активной становится не новая запись, а первая в списке).
• Недружественное поведение (unfriendly behavior) — поведение приложения создаёт пользователю неудобства в работе (например, на разных диалого- вых окнах в разном порядке расположены кнопки «OK» и «Cancel»).
• Расхождение с требованиями (variance from specs) — этот симптом указы- вают, если дефект сложно соотнести с другими симптомами, но тем не менее приложение ведёт себя не так, как описано в требованиях.
• Предложение по улучшению (enhancement) — во многих инструментальных средствах управления отчётами о дефектах для этого случая есть отдельный
1.
Суть проблемы: клиентская часть приложения начинает «вслепую» читать заголовок файла, не проверяя ни размер, ни корректность формата, ничего; возникает некая внутренняя ошибка, и клиентская часть приложения некор- ректно прекращает работу, не закрыв сессию с сервером; сервер закрывает сессию по таймауту (повторный запуск клиентской части запускает новую сессию, так что старая сессия и все данные в ней в любом случае утеряны).
2.
Исходный вариант подробного описания: некорректный анализ открывае- мого клиентом файла приводит к краху клиента и необратимой утере теку- щей сессии с сервером.
3.
Конечный вариант подробного описания:
• Фактический результат: отсутствие проверки корректности открывае- мого клиентской частью приложения файла (в том числе пустого) при- водит к краху клиентской части и необратимой потере текущей сессии с сервером (см. BR852345).
• Ожидаемый результат: производится анализ структуры открываемого файла; в случае обнаружения проблем отображается сообщение о не- возможности открытия файла.
4.
Определение «что, где и при каких условиях случилось»:
• Что: крах клиентской части приложения.
• Где: – (конкретное место в приложении определить едва ли возможно).
• При каких условиях: при открытии пустого или повреждённого файла.
Атрибуты (поля) отчёта о дефекте
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 177/301 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–2023
Стр: 178/301
Таблица 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–2023
Стр: 179/301
Воспроизводимость (reproducibility) показывает, при каждом ли прохожде- нии по шагам воспроизведения дефекта удаётся вызвать его проявление. Это поле принимает всего два значения: всегда (always) или иногда (sometimes).
Можно сказать, что воспроизводимость «иногда» означает, что тестировщик не нашёл настоящую причину возникновения дефекта. Это приводит к серьёзным дополнительным сложностям в работе с дефектом:
• Тестировщику нужно потратить много времени на то, чтобы удостовериться в наличии дефекта (т.к. однократный сбой в работе приложения мог быть вы- зван огромным количеством посторонних причин).
• Разработчику тоже нужно потратить время, чтобы добиться проявления де- фекта и убедиться в его наличии. После внесения исправлений в приложение разработчик фактически должен полагаться только на свой профессиона- лизм, т.к. даже многократное прохождение по шагам воспроизведения в та- ком случае не гарантирует, что дефект был исправлен (возможно, через ещё
10
–20 повторений он бы проявился).
• Тестировщику, верифицирующему исправление дефекта и вовсе остаётся верить разработчику на слово по той же самой причине: даже если он попы- тается воспроизвести дефект 100 раз и потом прекратит попытки, может так случиться, что на 101-й раз дефект всё же воспроизвёлся бы.
Как легко догадаться, такая ситуация является крайне неприятной, а потому рекомендуется один раз потратить время на тщательную диагностику проблемы, найти её причину и перевести дефект в разряд воспроизводимых всегда.
Важность (severity) показывает степень ущерба, который наносится проекту существованием дефекта.
В общем случае выделяют следующие градации важности:
• Критическая (critical) — существование дефекта приводит к масштабным по- следствиям катастрофического характера, например: потеря данных, рас- крытие конфиденциальной информации, нарушение ключевой функциональ- ности приложения и т.д.
• Высокая (major) — существование дефекта приносит ощутимые неудобства многим пользователям в рамках их типичной деятельности, например: недо- ступность вставки из буфера обмена, неработоспособность общепринятых клавиатурных комбинаций, необходимость перезапуска приложения при вы- полнении типичных сценариев работы.
• Средняя (medium) — существование дефекта слабо влияет на типичные сце- нарии работы пользователей, и/или существует обходной путь достижения цели, например: диалоговое окно не закрывается автоматически после нажа- тия кнопок «OK»/«Cancel», при распечатке нескольких документов подряд не сохраняется значение поля «Двусторонняя печать», перепутаны направле- ния сортировок по некоему полю таблицы.
• Низкая (minor) — существование дефекта редко обнаруживается незначи- тельным процентом пользователей и (почти) не влияет на их работу, напри- мер: опечатка в глубоко вложенном пункте меню настроек, некое окно сразу при отображении расположено неудобно (нужно перетянуть его в удобное место), неточно отображается время до завершения операции копирования файлов.
Атрибуты (поля) отчёта о дефекте
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 180/301
Срочность (priority) показывает, как быстро дефект должен быть устранён.
В общем случае выделяют следующие градации срочности:
• Наивысшая (ASAP, as soon as possible) срочность указывает на необходи- мость устранить дефект настолько быстро, насколько это возможно. В зави- симости от контекста «настолько быстро, насколько возможно» может варь- ироваться от «в ближайшем билде» до единиц минут.
• Высокая (high) срочность означает, что дефект следует исправить вне оче- реди, т.к. его существование или уже объективно мешает работе, или начнёт создавать такие помехи в самом ближайшем будущем.
• Обычная (normal) срочность означает, что дефект следует исправить в по- рядке общей очерёдности. Такое значение срочности получает большинство дефектов.
• Низкая (low) срочность означает, что в обозримом будущем исправление данного дефекта не окажет существенного влияния на повышение качества продукта.
Несколько дополнительных рассуждений о важности и срочности стоит рассмотреть отдельно.
Один из самых частых вопросов относится к тому, какая между ними связь.
Никакой. Для лучшего понимания этого факта можно сравнить важность и сроч- ность с координатами X и Y точки на плоскости. Хоть «на бытовом уровне» и ка- жется, что дефект с высокой важностью следует исправить в первую очередь, в реальности ситуация может выглядеть совсем иначе.
Чтобы проиллюстрировать эту мысль подробнее, вернёмся к перечню града- ций: заметили ли вы, что для разных степеней важности примеры приведены, а для разных степеней срочности — нет? И это не случайно.
Зная суть проекта и суть дефекта, его важность определить достаточно легко, т.к. мы можем проследить влияние дефекта на критерии качества, степень выполнения требований той или иной важности и т.д. Но срочность исправления дефекта можно определить только в конкретной ситуации.
Поясним на жизненном примере: насколько для жизни человека важна вода?
Очень важна, без воды человек умирает. Значит, важность воды для человека можно оценить как критическую. Но можем ли мы ответить на вопрос «Как быстро человеку нужно выпить воды?», не зная, о какой ситуации идёт речь? Если рассмат- риваемый человек умирает от жажды в пустыне, срочность будет наивысшей. Если он просто сидит в офисе и думает, не попить ли чая, срочность будет обычной или даже низкой.
Вернёмся к примерам из разработки программного обеспечения и покажем четыре случая сочетания важности и срочности в таблице 2.5.b.
Таблица 2.5.b — Примеры сочетания важности и срочности дефектов
Важность (Severity)
Критическая (Critical)
Низкая (Minor)
Срочность
(Priority)
Наивысшая
(ASAP)
Проблемы с безопасностью во введённом в эксплуата- цию банковском ПО.
На корпоративном сайте повре- дилась картинка с фирменным логотипом.
Низкая
(Low)
В самом начале разработки проекта обнаружена ситуа- ция, при которой могут быть повреждены или вовсе уте- ряны пользовательские дан- ные.
В руководстве пользователя об- наружено несколько опечаток, не влияющих на смысл текста.
Атрибуты (поля) отчёта о дефекте
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 181/301
Симптом (symptom) — позволяет классифицировать дефекты по их типич- ному проявлению. Не существует никакого общепринятого списка симптомов. Бо- лее того, далеко не в каждом инструментальном средстве управления отчётами о дефектах есть такое поле, а там, где оно есть, его можно настроить. В качестве примера рассмотрим следующие значения симптомов дефекта.
• Косметический дефект (cosmetic flaw) — визуально заметный недостаток ин- терфейса, не влияющий на функциональность приложения (например, надпись на кнопке выполнена шрифтом не той гарнитуры).
• Повреждение/потеря данных (data corruption/loss) — в результате возникно- вения дефекта искажаются, уничтожаются (или не сохраняются) некоторые данные (например, при копировании файлов копии оказываются повреждён- ными).
• Проблема в документации (documentation issue) — дефект относится не к приложению, а к документации (например, отсутствует раздел руководства по эксплуатации).
• Некорректная операция (incorrect operation) — некоторая операция выполня- ется некорректно (например, калькулятор показывает ответ 17 при умноже- нии 2 на 3).
• Проблема инсталляции (installation problem) — дефект проявляется на ста- дии установки и/или конфигурирования приложения (см. инсталляционное тестирование
{86}
).
• Ошибка локализации (localization issue) — что-то в приложении не переве- дено или переведено неверно на выбранный язык интерфейса (см. локали- зационное тестирование
{89}
).
• Нереализованная функциональность (missing feature) — некая функция при- ложения не выполняется или не может быть вызвана (например, в списке форматов для экспорта документа отсутствует несколько пунктов, которые там должны быть).
• Проблема масштабируемости (scalability) — при увеличении количества до- ступных приложению ресурсов не происходит ожидаемого прироста произво- дительности приложения (см. тестирование производительности
{91}
и тести- рование масштабируемости
{92}
).
• Низкая производительность (low performance) — выполнение неких операций занимает недопустимо большое время (см. тестирование производительно- сти
{91}
).
• Крах системы (system crash) — приложение прекращает работу или теряет способность выполнять свои ключевые функции (также может сопровож- даться крахом операционной системы, веб-сервера и т.д.).
• Неожиданное поведение (unexpected behavior) — в процессе выполнения не- которой типичной операции приложение ведёт себя необычным (отличным от общепринятого) образом (например, после добавления в список новой за- писи активной становится не новая запись, а первая в списке).
• Недружественное поведение (unfriendly behavior) — поведение приложения создаёт пользователю неудобства в работе (например, на разных диалого- вых окнах в разном порядке расположены кнопки «OK» и «Cancel»).
• Расхождение с требованиями (variance from specs) — этот симптом указы- вают, если дефект сложно соотнести с другими симптомами, но тем не менее приложение ведёт себя не так, как описано в требованиях.
• Предложение по улучшению (enhancement) — во многих инструментальных средствах управления отчётами о дефектах для этого случая есть отдельный