Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Важность (Severity) Критическая (Critical) Низкая (Minor) Срочность (Priority) Наивысшая (ASAP) Проблемы с безопасностью во введённом в эксплуата- цию банковском ПО. На корпоративном сайте повре- дилась картинка с фирменным логотипом. Низкая (Low) В самом начале разработки проекта обнаружена ситуа- ция, при которой могут быть повреждены или вовсе уте- ряны пользовательские дан- ные. В руководстве пользователя об- наружено несколько опечаток, не влияющих на смысл текста. Атрибуты (поля) отчёта о дефекте Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 178/298 Симптом (symptom) — позволяет классифицировать дефекты по их типич- ному проявлению. Не существует никакого общепринятого списка симптомов. Бо- лее того, далеко не в каждом инструментальном средстве управления отчётами о дефектах есть такое поле, а там, где оно есть, его можно настроить. В качестве примера рассмотрим следующие значения симптомов дефекта. • Косметический дефект (cosmetic flaw) — визуально заметный недостаток ин- терфейса, не влияющий на функциональность приложения (например, надпись на кнопке выполнена шрифтом не той гарнитуры). • Повреждение/потеря данных (data corruption/loss) — в результате возникно- вения дефекта искажаются, уничтожаются (или не сохраняются) некоторые данные (например, при копировании файлов копии оказываются повреждён- ными). • Проблема в документации (documentation issue) — дефект относится не к приложению, а к документации (например, отсутствует раздел руководства по эксплуатации). • Некорректная операция (incorrect operation) — некоторая операция выполня- ется некорректно (например, калькулятор показывает ответ 17 при умноже- нии 2 на 3). • Проблема инсталляции (installation problem) — дефект проявляется на ста- дии установки и/или конфигурирования приложения (см. инсталляционное тестирование {83} ). • Ошибка локализации (localization issue) — что-то в приложении не переве- дено или переведено неверно на выбранный язык интерфейса (см. локали- зационное тестирование {86} ). • Нереализованная функциональность (missing feature) — некая функция при- ложения не выполняется или не может быть вызвана (например, в списке форматов для экспорта документа отсутствует несколько пунктов, которые там должны быть). • Проблема масштабируемости (scalability) — при увеличении количества до- ступных приложению ресурсов не происходит ожидаемого прироста произво- дительности приложения (см. тестирование производительности {88} и тести- рование масштабируемости {89} ). • Низкая производительность (low performance) — выполнение неких операций занимает недопустимо большое время (см. тестирование производительно- сти {88} ). • Крах системы (system crash) — приложение прекращает работу или теряет способность выполнять свои ключевые функции (также может сопровож- даться крахом операционной системы, веб-сервера и т.д.). • Неожиданное поведение (unexpected behavior) — в процессе выполнения не- которой типичной операции приложение ведёт себя необычным (отличным от общепринятого) образом (например, после добавления в список новой за- писи активной становится не новая запись, а первая в списке). • Недружественное поведение (unfriendly behavior) — поведение приложения создаёт пользователю неудобства в работе (например, на разных диалого- вых окнах в разном порядке расположены кнопки «OK» и «Cancel»). • Расхождение с требованиями (variance from specs) — этот симптом указы- вают, если дефект сложно соотнести с другими симптомами, но тем не менее приложение ведёт себя не так, как описано в требованиях. • Предложение по улучшению (enhancement) — во многих инструментальных средствах управления отчётами о дефектах для этого случая есть отдельный Атрибуты (поля) отчёта о дефекте Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 179/298 вид отчёта, т.к. предложение по улучшению формально нельзя считать де- фектом: приложение ведёт себя согласно требованиям, но у тестировщика есть обоснованное мнение о том, как ту или иную функциональность можно улучшить. Часто встречается вопрос о том, может ли у одного дефекта быть сразу не- сколько симптомов. Да, может. Например, крах системы очень часто ведёт к потере или повреждению данных. Но в большинстве инструментальных средств управле- ния отчётами о дефектах значение поля «Симптом» выбирается из списка, и потому нет возможности указать два и более симптома одного дефекта. В такой ситуации рекомендуется выбирать либо симптом, который лучше всего описывает суть ситу- ации, либо «наиболее опасный» симптом (например, недружественное поведение, состоящее в том, что приложение не запрашивает подтверждения перезаписи су- ществующего файла, приводит к потере данных; здесь «потеря данных» куда уместнее, чем «недружественное поведение»). Возможность обойти (workaround) — показывает, существует ли альтерна- тивная последовательность действий, выполнение которой позволило бы пользо- вателю достичь поставленной цели (например, клавиатурная комбинация Ctrl+P не работает, но распечатать документ можно, выбрав соответствующие пункты в меню). В некоторых инструментальных средствах управления отчётами о дефектах это поле может просто принимать значения «Да» и «Нет», в некоторых при выборе «Да» появляется возможность описать обходной путь. Традиционно считается, что дефектам без возможности обхода стоит повысить срочность исправления. Комментарий (comments, additional info) — может содержать любые полез- ные для понимания и исправления дефекта данные. Иными словами, сюда можно писать всё то, что нельзя писать в остальные поля. Вложения (attachments) — представляет собой не столько поле, сколько спи- сок прикреплённых к отчёту о дефекте приложений (копий экрана, вызывающих сбой файлов и т.д.). Общие рекомендации по формированию приложений таковы: • Если вы сомневаетесь, делать или не делать приложение, лучше сделайте. • Обязательно прилагайте т.н. «проблемные артефакты» (например, файлы, которые приложение обрабатывает некорректно). • Если вы прилагаете копию экрана: o Чаще всего вам будет нужна копия активного окна (Alt+PrintScreen), а не всего экрана (PrintScreen). o Обрежьте всё лишнее (используйте Snipping Tool или Paint в Windows, Pinta или XPaint в Linux). o Отметьте на копии экрана проблемные места (обведите, нарисуйте стрелку, добавьте надпись — сделайте всё необходимое, чтобы с пер- вого взгляда проблема была заметна и понятна). o В некоторых случаях стоит сделать одно большое изображение из не- скольких копий экрана (разместив их последовательно), чтобы пока- зать процесс воспроизведения дефекта. Альтернативой этого реше- ния является создание нескольких копий экрана, названных так, чтобы имена образовывали последовательность, например: br_9_sc_01.png, br_9_sc_02.png, br_9_sc_03.png. o Сохраните копию экрана в формате JPG (если важна экономия объёма данных) или PNG (если важна точная передача картинки без искаже- ний). Атрибуты (поля) отчёта о дефекте Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 180/298 • Если вы прилагаете видеоролик с записью происходящего на экране, обяза- тельно оставляйте только тот фрагмент, который относится к описываемому дефекту (это будет буквально несколько секунд или минут из возможных многих часов записи). Старайтесь подобрать настройки кодеков так, чтобы получить минимальный размер ролика при сохранении достаточного каче- ства изображения. • Поэкспериментируйте с различными инструментами создания копий экрана и записи видеороликов с происходящим на экране. Выберите наиболее удоб- ное для вас программное обеспечение и приучите себя постоянно его ис- пользовать. Для более глубокого понимания принципов оформления отчётов о дефектах рекомендуется прямо сейчас ознакомиться с главой «Типичные ошибки при напи- сании отчётов о дефектах» {199} Инструментальные средства управления отчётами о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 181/298 2.5.4. Инструментальные средства управления отчётами о дефек- тах Так называемые «инструментальные средства управления отчётами о де- фектах» в обычной разговорной речи называют «баг-трекинговыми систе- мами», «баг-трекерами» и т.д. Но мы здесь по традиции будем придержи- ваться более строгой терминологии. Инструментальных средств управления отчётами о дефектах (bug tracking system, defect management tool 318 ) очень много 319 , к тому же многие компании разра- батывают свои внутренние средства решения этой задачи. Зачастую такие инстру- ментальные средства являются частями инструментальных средств управления тестированием {127} Как и в случае с инструментальными средствами управления тестированием, здесь не имеет смысла заучивать, как работать с отчётами о дефектах в том или ином средстве. Мы лишь рассмотрим общий набор функций, как правило, реализу- емых такими средствами: • Создание отчётов о дефектах, управление их жизненным циклом с учётом контроля версий, прав доступа и разрешённых переходов из состояния в со- стояние. • Сбор, анализ и предоставление статистики в удобной для восприятия чело- веком форме. • Рассылка уведомлений, напоминаний и иных артефактов соответствующим сотрудникам. • Организация взаимосвязей между отчётами о дефектах, тест-кейсами, тре- бованиями и анализ таких связей с возможностью формирования рекомен- даций. • Подготовка информации для включения в отчёт о результатах тестирования. • Интеграция с системами управления проектами. Иными словами, хорошее инструментальное средство управления жизнен- ным циклом отчётов о дефектах не только избавляет человека от необходимости внимательно выполнять большое количество рутинных операций, но и предостав- ляет дополнительные возможности, облегчающие работу тестировщика и делаю- щие её более эффективной. Для общего развития и лучшего закрепления темы об оформлении отчётов о дефектах мы сейчас рассмотрим несколько картинок с формами из разных ин- струментальных средств. Здесь вполне сознательно не приведено никакого сравнения или подробного описания — подобных обзоров достаточно в Интернете, и они стремительно уста- ревают по мере выхода новых версий обозреваемых продуктов. Но интерес представляют отдельные особенности интерфейса, на которые мы обратим внимание в каждом из примеров (важно: если вас интересует подроб- ное описание каждого поля, связанных с ним процессов и т.д., обратитесь к офици- альной документации — здесь будут лишь самые краткие пояснения). 318 Defect management tool, Incident management tool. A tool that facilitates the recording and status tracking of defects and changes. They often have workflow-oriented facilities to track and control the allocation, correction and re-testing of defects and provide reporting facilities. See also incident management tool. [ISTQB Glossary] 319 «Comparison of issue-tracking systems», Wikipedia [ http://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems ] Инструментальные средства управления отчётами о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 182/298 Jira 320 1. Project (проект) позволяет указать, к какому проекту относится дефект. 2. Issue type ( тип записи/артефакта) позволяет указать, что именно представ- ляет собой создаваемый артефакт. JIRA позволяет создавать не только от- чёты о дефектах, но и множество других артефактов 321 , типы которых можно настраивать 322 . По умолчанию представлены: • Improvement (предложение по улучшению) — было описано подробно в разделе, посвящённом полям отчёта о дефекте (см. описание поля «симптом», значение «предложение по улучшению» {178} ). • New feature (новая особенность) — описание новой функционально- сти, нового свойства, новой особенности продукта. • Task (задание) — некое задание для выполнения тем или иным участ- ником проектной команды. • Custom issue (произвольный артефакт) — как правило, это значение при настройке JIRA удаляют, заменяя своими вариантами, или пере- именовывают в Issue. 3. Summary ( краткое описание) позволяет указать краткое описание дефекта. 4. Priority ( срочность) позволяет указать срочность исправления дефекта. По умолчанию JIRA предлагает следующие варианты: • Highest (самая высокая срочность). • High (высокая срочность). • Medium (обычная срочность). • Low (низкая срочность). • Lowest (самая низкая срочность). Обратите внимание: по умолчанию поля severity (важность) нет. Но его можно добавить. 5. Components ( компоненты) содержит перечень компонентов приложения, за- тронутых дефектом (хотя иногда здесь перечисляют симптомы дефектов). 6. Affected versions ( затронутые версии) содержит перечень версий продукта, в которых проявляется дефект. 7. Environment ( окружение) содержит описание аппаратной и программной кон- фигурации, в которой проявляется дефект. 8. Description ( подробное описание) позволяет указать подробное описание де- фекта. 9. Original estimate ( начальная оценка времени исправления) позволяет указать начальную оценку того, сколько времени займёт устранение дефекта. 10. Remaining estimate (расчётное остаточное время исправления) показывает, сколько времени осталось от начальной оценки. 11. Story points ( оценочные единицы) позволяет указать сложность дефекта (или иного артефакта) в специальных оценочных единицах, принятых в гибких ме- тодологиях управления проектами. 12. Labels ( метки) содержит метки (теги, ключевые слова), по которым можно группировать и классифицировать дефекты и иные артефакты. 13. Epic/Theme ( история/область) содержит перечень высокоуровневых меток, описывающих относящиеся к дефекту крупные области требований, крупные модули приложения, крупные части предметной области, объёмные пользо- вательские истории и т.д. 320 «JIRA — Issue & Project Tracking Software» [ https://www.atlassian.com/software/jira/ ] 321 «What is an Issue» [ https://confluence.atlassian.com/jira063/what-is-an-issue-683542485.html ] 322 «Defining Issue Type Field Values» [ https://confluence.atlassian.com/display/JIRA/Defining+Issue+Type+Field+Values ] Инструментальные средства управления отчётами о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 183/298 Рисунок 2.5.f — Создание отчёта о дефекте в JIRA 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Инструментальные средства управления отчётами о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 184/298 14. External issue id ( идентификатор внешнего артефакта) позволяет связать от- чёт о дефекте или иной артефакт с внешним документом. 15. Epic link ( ссылка на историю/область) содержит ссылку на историю/область (см. пункт 13), наиболее близко относящуюся к дефекту. 16. Has a story/s (истории) содержит ссылки и/или описание пользовательских историй, связанных с дефектом (как правило, здесь приводятся ссылки на внешние документы). 17. Tester ( тестировщик) содержит имя автора описания дефекта. 18. Additional information ( дополнительная информация) содержит полезную до- полнительную информацию о дефекте. 19. Sprint ( спринт) содержит номер спринта (2–4-недельной итерации разработки проекта в терминологии гибких методологий управления проектами), во время которого был обнаружен дефект. Многие дополнительные поля и возможности становятся доступными при других операциях с дефектами (просмотром или редактированием созданного де- фекта, просмотре отчётов и т.д.). Bugzilla 323 1. Product (продукт) позволяет указать, к какому продукту (проекту) относится дефект. 2. Reporter ( автор отчёта) содержит e-mail автора описания дефекта. 3. Component ( компонент) содержит указание компонента приложения, к кото- рому относится описываемый дефект. 4. Component description ( описание компонента) содержит описание компо- нента приложения, к которому относится описываемый дефект. Эта инфор- мация загружается автоматически при выборе компонента. 5. Version ( версия) содержит указание версии продукта, в которой был обнару- жен дефект. 6. Severity (важность) содержит указание важности дефекта. По умолчанию предложены такие варианты: • Blocker (блокирующий дефект) — дефект не позволяет решить с помо- щью приложения некоторую задачу. • Critical (критическая важность). • Major (высокая важность). • Normal (обычная важность). • Minor (низкая важность). • Trivial (самая низкая важность). • Enhancement (предложение по улучшению) — было описано подробно в разделе, посвящённом полям отчёта о дефекте (см. описание поля «симптом», значение «предложение по улучшению» {178} ). 7. Hardware (аппаратное обеспечение) позволяет выбрать профиль аппарат- ного окружения, в котором проявляется дефект. 8. OS (операционная система) позволяет указать операционную систему, под которой проявляется дефект. 323 «Bugzilla» [ https://www.bugzilla.org ] Инструментальные средства управления отчётами о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 185/298 Рисунок 2.5.g — Создание отчёта о дефекте в Bugzilla 9. Priority (срочность) позволяет указать срочность исправления дефекта. По умолчанию Bugzilla предлагает следующие варианты: • Highest (самая высокая срочность). • High (высокая срочность). • Normal (обычная срочность). • Low (низкая срочность). • Lowest (самая низкая срочность). 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Инструментальные средства управления отчётами о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 186/298 10. Status ( статус) позволяет установить статус отчёта о дефекте. По умолчанию Bugzilla предлагает следующие варианты статусов: • Unconfirmed (не подтверждено) — дефект пока не изучен, и нет гаран- тии того, что он действительно корректно описан. • Confirmed (подтверждено) — дефект изучен, корректность описания подтверждена. • In progress (в работе) — ведётся работа по изучению и устранению де- фекта. В официальной документации рекомендуется сразу же после установки Bugzilla сконфигурировать набор статусов и правила жизненного цикла от- чёта о дефектах в соответствии с принятыми в вашей компании правилами. 11. Assignee (ответственный) указывает e-mail участника проектной команды, от- ветственного за изучение и исправление дефекта. 12. CC (уведомлять) содержит список e-mail адресов участников проектной ко- манды, которые будут получать уведомления о происходящем с данным де- фектом. 13. Default CC (уведомлять по умолчанию) содержит e-mail адрес(а) участников проектной команды, которые по умолчанию будут получать уведомления о происходящем с любыми дефектами (чаще всего здесь указываются e-mail адреса рассылок). 14. Original estimation (начальная оценка) позволяет указать начальную оценку того, сколько времени займёт устранение дефекта. 15. Deadline (крайний срок) позволяет указать дату, к которой дефект обяза- тельно нужно исправить. 16. Alias (псевдоним) позволяет указать короткое запоминающееся название де- фекта (возможно, в виде некоей аббревиатуры) для удобства упоминания дефекта в разнообразных документах. 17. URL (URL) позволяет указать URL, по которому проявляется дефект (осо- бенно актуально для веб-приложений). 18. Summary ( краткое описание) позволяет указать краткое описание дефекта. 19. Description ( подробное описание) позволяет указать подробное описание де- фекта. 20. Attachment (вложение) позволяет добавить к отчёту о дефекте вложения в виде прикреплённых файлов. 21. Depends on (зависит от) позволяет указать перечень дефектов, которые должны быть устранены до начала работы с данным дефектом. 22. Blocks (блокирует) позволяет указать перечень дефектов, к работе с кото- рыми можно будет приступить только после устранения данного дефекта. |