Юзабилититестирование программного
 Скачать 0.61 Mb.
|
Лабораторная работа №5 Поиск и документирование дефектовЦель: протестировать web-приложение и описать найденные дефекты. Планзанятия: Изучить теоретические сведения. Выполнить практическое задание по лабораторной работе. Оформить отчет и ответить на контрольные вопросы. Теоретическиесведения Дефекты, обнаруженные тестировщиком, должны быть корректно и понятно описаны, чтобы разработчик смог воспроизвести данный дефект и устранить его. Описание каждого дефекта сохраняется в специализированной – багтрэкинговой – системе (например, JIRA, Bugzilla, Mantis, Redmine и др.) или в предварительно созданном в программной среде Microsoft Excel файле (пример приведен в табли- це 5.1). Таблица 5.1 – Пример описания дефекта
Описание дефекта включает следующие обязательные поля: 47 Headline – название дефекта. Severity – степень критичности (важность дефекта). Description – алгоритм воспроизведения. Result – фактический результат. Expected result – ожидаемый результат. Attachment – прикрепленные файлы (приложение). В багтрэкинговых системах для каждого дефекта автоматически генерируется его уникальный номер, в случае использования Microsoft Excel номер дефекту необходимо присваивать вручную. Требование спецификации, которое нарушает обнаруженный дефект, можно дополнительно вынести в примечание. Дополнительно в описании дефекта может быть указана Priority – степень срочности исправления дефекта разработчиком. Рассмотрим подробно каждую категорию описания дефекта. Headline (название дефекта). Цель составления заголовка дефекта – предо- ставить краткую и в тоже время понятную информацию о том, где, что и в резуль- тате чего произошло. Характеристиками качественного заголовка являются крат- кость, информативность, точная идентификация проблемы. Заголовок дефекта должен отвечать на три вопроса: Где? В каком месте интерфейса пользователя находится проблема. В данной части заголовка следует также дополнительно указать особенности теста, если это поможет разобраться в проблеме (версия операционной системы, браузера, сторонних приложений, которые имеют отношение к тестируемому про- граммному средству). Что? Что происходит или не происходит согласно спецификации или представлению о нормальной работе программного продукта. При этом необхо- димо указывать на наличие проблемы, а не на ее содержание (его указывают в описании). Если содержание проблемы варьируется, все известные варианты ука- зываются в описании. Когда (при каких условиях)? В какой момент работы программы или по наступлению какого события проблема проявляется. Пример: в приложении есть диалог «Преобразовать данные» с кнопкой «Пре- образовать». При нажатии этой кнопки появляется сообщение об ошибке «Ошиб- ка 315». Заголовок дефекта по описанной методике составляется так: Где?: Диалог «Преобразовать данные». Что?: Показывается сообщение об ошибке. Когда?: При нажатии кнопки «Преобразовать». Итоговый заголовок будет иметь следующий вид: Диалог «Преобразовать данные» показывает сообщение об ошибке при нажатии кнопки «Преобразовать». 48 Уберем лишние слова, добавим код ошибки для удобства поиска: Диалог «Преоб- разовать данные»: сообщение об ошибке 315 при нажатии кнопки «Преобразо- вать». Если сформулировать заголовок по формуле Где? Что? Когда (при каких условиях)? трудно, то можно воспользоваться следующим алгоритмом действий: Пропустите заголовок дефекта. Напишите описание дефекта, фактический и ожидаемый результаты. Выделите ключевые моменты, руководствуясь формулой Где? Что? Когда (при каких условиях)? Сложите эти ключевые моменты вместе. То, что получится в итоге, и будет составлять заголовок дефекта. Severity (степень критичности). Степень критичности (серьезности, важно- сти) показывает степень ущерба, который наносится проекту существованием де- фекта. В общем случае выделяют следующие градации критичности дефектов (таб- лица 5.2): Critical (критический), Major (значительный), Average (средней значи- мости), Minor (незначительный), Enhancement (предложение по улучшению). Description(алгоритмвоспроизведения). Цель составления алгоритма вос- произведения дефекта – последовательно описать шаги для повторения дефекта. Description должен быть оформлен в виде списка перечисления действий: Шаг #1. Шаг #2. … n. Шаг #n. В случае, если для воспроизведения дефекта требуется ряд начальных усло- вий (например, должен быть создан определенный набор документов, пользова- тель или группа пользователей с особыми правами), то эти предусловия должны быть вынесены в начало описания: Предусловия. Шаг #1. Шаг #2. … n. Шаг #n. 49 Таблица 5.2 – Степени критичности дефектов
50 При составлении Description необходимо следовать приведенным ниже реко- мендациям. Description – это четкий алгоритм, в котором приветствуются короткие, по- нятные фразы и нумерация. Нельзя использовать личные предложения формата «Я думаю, что так будет лучше», «Я зашел на страницу…» и т. д. Можно использовать специальные символы «+», «=», «<>», которые помогут сделать подобие навигации: File > Open, DOC + XLS. Однако не рекомендуется писать шаги в строку через символы перехода – это затрудняет восприятие дефекта. Следует указывать специфичные условия воспроизведения дефекта, если та- ковые имеются. Например, под каким пользователем вы работаете (если это важно). Описание предложений по улучшению должно быть максимально полным и аргументированным. Result (фактический результат). Цель написания Result – четко описать по- лученный результат. Expected result (ожидаемый результат). Цель написания Expected result – привести аргументы разработчикам, как именно должно работать приложение. В Expected result должно быть четкое обоснование, почему именно так долж- но работать приложение. Лучше всего, если в нем приведена ссылка на конкрет- ный пункт спецификации. Если в Expected result приводится ссылка на спецификацию, сам тестировщик дополнительно цитирует текст спецификации, чтобы сократить время разработчи- ка на анализ документа и однозначно указать на способ решения проблемы. Если функция работает, но некорректно, то в Expected Result обязательно должно быть описание того, как она должна работать корректно. Если сделана ошибка в надписи или интерфейсе проекта, необходимо гра- мотно и полностью указать, как она должна быть исправлена – написать надпись без ошибки или описать требуемые изменения интерфейса. Expected Result всегда следует заполнять. Не стоит полагаться на очевидность представлений о правильном поведении приложения. Текст Expected result рекомендуется писать законченными полными безлич- ными предложениями. Attachment (приложения). Attachment – это прикрепленный к дефекту файл, дополняющий описание: скриншот, файлы, необходимые для воспроизведения дефекта, логи программы, видео ошибки и т. д. Attachment является вспомогатель- ным средством передачи информации о проблеме. Для всех GUI дефектов attachment обязателен. Если к дефекту прикрепляется файл, об этом обязательно должно быть указа- но в описании дефекта («See the file/screenshot/log/video attached»). Прикреплен- 51 ный файл не должен быть слишком большим по размеру (особенно это касается видео: до 10 Мбайт), а также должен относиться именно к описанной ошибке (например, из лога приложения стоит скопировать в прикрепляемый файл только данные об ошибке). Формат файла скриншота – PNG. Имя файла скриншота реко- мендуется делать числовым, нейтральным – 1.png, 25.png и т. п. Скриншот должен содержать следующие элементы: сама ошибка, выделение места ошибки, стрелка к прямоугольнику, описание ошибки: «Наблюдаемый ре- зультат» и/или «Ожидаемый результат». Текст на скриншоте также необходимо выделить: обвести в прямоугольник и набрать шрифтом, заметно отличающимся от шрифта программы. Качественно подготовленный скриншот должен давать возможность понять смысл дефекта без необходимости читать его описание (ри- сунок 5.1).  Рисунок 5.1 – Пример скриншота, поясняющего обнаруженный дефект Делать снимок всего окна программы необязательно: на снимке должна быть видна ошибка и место, в котором она находится. Если для понимания дефекта не- обходим контекст, то помимо собственно ошибки фиксируют необходимую ин- формацию (браузер, в котором открыто web-приложение, все окно программы в фоне с названием диалогового окна, где эта ошибка появилась). Если необходимо привести снимки нескольких страниц проекта, связанных между собой, лучше сделать это на одном скриншоте, совместив изображения по горизонтали и при необходимости отметив стрелками переходы значений, полей и т. п. Далее приведены рекомендации по описанию дефектов. Часто сообщение об ошибке превращается в сокращенную запись только ос- новных действий, необходимых для воспроизведения ошибки, опуская все несу- щественные. Но, будучи незнакомым с внутренней структурой приложения, те- 52 стировщик не может знать, какие из выполненных им действий наиболее суще- ственны для диагностирования данной ошибки. Пренебрегая действиями, которые кажутся незначительными, повышается риск потери важной информации. Лучший способ избежать этой проблемы состоит в том, чтобы просто перечислить все дей- ствия, которые необходимы для воспроизведения ошибочного поведения, начиная с открытия нужной формы в проекте. Если есть подозрение на повторение дефекта в нескольких модулях проекта, этот факт нужно исследовать еще до внесения дефекта и при его описании указать все места, где дефект воспроизводится. Дефект не должен содержать фразу: «Это не работает», дефект должен пока- зать, что и при каких условиях не работает. Чтобы внести дефект, его следует воспроизвести минимум два раза, причем начиная с самых нейтральных условий воспроизведения, и только после гаранти- рованного повторения описать последовательность действий. Нельзя не описывать дефекты только потому, что их не получается воспроиз- вести. Факт невозможности выяснить причину дефекта в таком случае обязатель- но должен быть указан в описании дефекта. Дефекты целесообразно группировать, однако делать это необходимо в соот- ветствии с приведенными ниже правилами. GUI дефекты могут группироваться в один по признаку формы, на которой они находятся, т. е. если одна форма содержит несколько GUI дефектов с одина- ковым уровнем Severity, то их можно объединить. Функциональные дефекты группируются в том случае, если речь идет об од- нотипных дефектах, которые воспроизводятся в различных модулях, страницах или полях (например, динамическое обновление не работает в модулях 1, 2 и 4 или отсутствует валидация на спецсимволы на всех полях страницы). Группировка функциональных дефектов по признаку формы, на которой они найдены, не применяется. Недопустимо объединять в один дефекты разного типа, например функцио- нальные и GUI. В таком случае пишутся несколько дефектов на каждый тип. Рекомендации по хорошему описанию дефектов: Шаги воспроизведения, фактический и ожидаемый результаты должны быть подробно описаны. Дефект должен быть понятно описан (с использованием общеупотребимой лексики, точных названий программных средств). Необходимо давать ссылку на соответствующее требование, к нарушению которого приводит фактический результат работы программного средства. Если существует какая-либо информация, которая поможет быстрее обна- ружить или исправить дефект, необходимо сообщить эту информацию. 53 Окружение (ОС, браузер, настройки и т. п.), под которым возникла ошибка, должно быть четко указано. Создавать дефект и описывать его необходимо сразу же, как только он был обнаружен. Откладывание «на потом» приводит к риску забыть о дефекте или ка- ких-либо деталях его воспроизведения. Несвоевременное создание дефекта не позволяет проектной команде реагировать на ее обнаружение в реальном времени. После описания дефекта необходимо еще раз перечитать его, убедится, что все необходимые поля заполнены и все написано верно. Помимо собственно описания дефектов, результаты тестирования вносят в рабочую тестовую документацию (Acceptance Sheet, Test Survey, Test Cases). Для этого напротив выполненной проверки указывают степень критичности обнару- женного дефекта, его номер и заголовок. Если по результатам конкретной провер- ки выявлено несколько дефектов, то перечисляют номера всех дефектов, а в каче- стве степени критичности и заголовка указывают наиболее серьезный дефект. Практическоезадание: Выбрать объект реального мира (например: холодильник, блендер, лифт и др.), выделить в нем модули. Разработать 20 и более тестовых проверок для выбранного объекта реаль- ного мира с указанием тестируемого модуля и глубины тестового покрытия (Smoke, MAT, AT). Сформулировать по два возможных дефекта на каждый уровень Severity (Critical, Major, Average, Minor, Enhancement) для выбранного объекта реального мира. Описать по одному дефекту на каждый уровень Severity (Critical, Major, Average, Minor, Enhancement) для выбранного объекта реального мира. Протестировать web-приложение в соответствии с составленной ранее те- стовой документацией. Описать все найденные дефекты в отчете о дефектах в среде Microsoft Excel. В отчете о дефектах указать номер тестируемой сборки, название прило- жения, период времени тестирования, ФИО тестировщика, тестовое окружение (операционная система, браузер). Для каждого дефекта указать его порядковый номер, заголовок, важность, алгоритм воспроизведения, фактический результат, ожидаемый результат, прило- жение, примечание. Для каждого дефекта обязательно сделать скриншоты. В рабочую тестовую документацию внести результаты тестирования с указанием напротив соответствующей проверки степени критичности обнаружен- ного дефекта, его номера и заголовка. Оформить отчет и защитить лабораторную работу. 54 Содержаниеотчета: Цель работы. Отчет о результатах тестирования выбранного объекта реального мира с перечислением тестовых проверок, сформулированных дефектов на каждый уро- вень Severity, описания дефектов. Отчет о найденных дефектах web-приложения. Рабочая тестовая документация с внесенными дефектами web-приложения. Выводы по работе. Контрольныевопросы: Что такое дефект? Какие характеристики необходимо указать при описании дефекта? Что такое Headline/Summary в описании дефекта? На какие три вопроса должен отвечать Headline/Summary? Что такое Severity в описании дефекта? Какие существуют степени Severity? Приведите примеры. Что такое Description в описании дефекта? Что такое Expected result в описании дефекта? Зачем нужен Attachment при описании дефекта? Какие существуют рекомендации по описанию дефектов? Какие дефекты можно группировать? 55 |