Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Соответствие принятым шаблонам оформления и традициям. Как и в случае с тест-кейсами, с шаблонами оформления отчётов о дефектах проблем не возникает: они определены имеющимся образцом или экранной формой инстру- ментального средства управления жизненным циклом отчётов о дефектах. Но что касается традиций, которые могут различаться даже в разных командах в рамках одной компании, то единственный совет: почитайте уже готовые отчёты о дефек- тах, перед тем как писать свои. Это может сэкономить вам много времени и сил. Логика создания эффективных отчётов о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 195/298 2.5.6. Логика создания эффективных отчётов о дефектах При создании отчёта о дефекте рекомендуется следовать следующему ал- горитму: 0. Обнаружить дефект ☺ 1. Понять суть проблемы. 2. Воспроизвести дефект. 3. Проверить наличие описания найденного вами дефекта в системе управле- ния дефектами. 4. Сформулировать суть проблемы в виде «что сделали, что получили, что ожи- дали получить». 5. Заполнить поля отчёта, начиная с подробного описания. 6. После заполнения всех полей внимательно перечитать отчёт, исправив не- точности и добавив подробности. 7. Ещё раз перечитать отчёт, т.к. в пункте 6 вы точно что-то упустили ☺ Теперь — о каждом шаге подробнее. Понять суть проблемы Всё начинается именно с понимания происходящего с приложением. Только при наличии такого понимания вы сможете написать по-настоящему качественный отчёт о дефекте, верно определить важность дефекта и дать полезные рекоменда- ции по его устранению. В идеале отчёт о дефекте описывает именно суть про- блемы, а не её внешнее проявление. Сравните два отчёта об одной и той же ситуации (приложение «Конвертер файлов» не различает файлы и символические ссылки на файлы, что приводит к серии аномалий в работе с файловой системой). Плохой отчёт, при написании которого суть проблемы не понята: Краткое описание Подробное описание Шаги по воспроизведению Обрабатываются файлы вне SOURCE_DIR. Иногда по непонятным причинам приложение обрабатывает случай- ные файлы вне каталога SOURCE_DIR. Act: обрабатываются отдельные файлы вне SOURCE_DIR. Exp: обрабатываются только файлы, находящиеся в SOURCE_DIR. Req: ДС-2.1 К сожалению, не удалось обнару- жить последовательность шагов, приводящих к появлению этого дефекта. Воспро- изводи- мость Важность Сроч- ность Симптом Воз- мож- ность обойти Комментарий Иногда Высокая Высокая Некорректная операция Нет Логика создания эффективных отчётов о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 196/298 Хороший отчёт, при написании которого суть проблемы понята: Краткое описание Подробное описание Шаги по воспроизведению Приложение не раз- личает файлы и символические ссылки на файлы. Если в каталог SOURCE_DIR поме- стить символическую ссылку на файл, возникает следующее ошибочное по- ведение: а) Если символическая ссылка указы- вает на файл внутри SOURCE_DIR, файл обрабатывается дважды, а в DESTINATION_DIR перемещается как сам файл, так и символическая ссылка на него. б) Если символическая ссылка указы- вает на файл вне SOURCE_DIR, при- ложение обрабатывает этот файл, перемещает символическую ссылку и сам файл в DESTINATION_DIR, а за- тем продолжает обрабатывать файлы в каталоге, в котором изна- чально находился обработанный файл. Act: приложение считает символиче- ские ссылки на файлы самими фай- лами (см. подробности выше). Exp: в случае если в каталоге SOURCE_DIR приложение обнаружи- вает символическую ссылку, оно пре- кращает работу с выводом сообщения «Symbolic link [имя символической ссылки] in SOURCE_DIR folder de- tected. Remove it manually or restart ap- plication with --force_file_operations key to remove automatically. » Req: UR.56.BF.4.e. 1. В произвольном месте со- здать следующую структуру каталогов: /SRC/ /DST/ /X/ 2. Поместить в каталоги SRC и X несколько произвольных фай- лов допустимого формата и размера. 3. Создать в каталоге SRC две символические ссылки: а) на любой из файлов внутри ката- лога SRC; б) на любой из файлов внутри каталога X. 4. Запустить приложение. Дефект: в каталог DST пере- мещены как файлы, так и сим- волические ссылки; содержи- мое каталога X обработано и перемещено в каталог DST. Воспро- изводи- мость Важность Сроч- ность Симптом Возмож- ность обойти Комментарий Всегда Высокая Обычная Некор- ректная операция Нет Быстрый взгляд на код показал, что вместо is_file() используется file_exists(). Похоже, проблема в этом. Также этот дефект приво- дит к попытке обработать ката- логи как файлы (см. BR-999.99). В алгоритме обработки SOURCE_DIR явно есть логиче- ская ошибка: ни при каких усло- виях приложение не должно об- рабатывать файлы, находящиеся вне SOURCE_DIR, т.е. что-то не так с генерацией или проверкой полных имён файлов. Логика создания эффективных отчётов о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 197/298 Воспроизвести дефект Это действие не только поможет в дальнейшем правильно заполнить поле «Воспроизводимость {176} », но и позволит избежать неприятной ситуации, в которой за дефект приложения будет принят некий кратковременный сбой, который (скорее всего) произошёл где-то в вашем компьютере или в иной части ИТ-инфраструктуры, не имеющей отношения к тестируемому приложению. Проверить наличие описания найденного вами дефекта Обязательно стоит проверить, нет ли в системе управления дефектами опи- сания именно того дефекта, который вы только что обнаружили. Это простое дей- ствие, не относящееся непосредственно к написанию отчёта о дефекте, но значи- тельно сокращающее количество отчётов, отклонённых с резолюцией «дубликат». Сформулировать суть проблемы Формулировка проблемы в виде «что сделали (шаги по воспроизведению), что получили (фактический результат в подробном описании), что ожидали полу- чить (ожидаемый результат в подробном описании)» позволяет не только подгото- вить данные для заполнения полей отчёта, но и ещё лучше понять суть проблемы. В общем же случае формула «что сделали, что получили, что ожидали полу- чить» хороша по следующим причинам: • Прозрачность и понятность: следуя этой формуле, вы готовите именно дан- ные для отчёта о дефекте, не скатываясь в пространные отвлечённые рас- суждения. • Лёгкость верификации дефекта: разработчик, используя эти данные, может быстро воспроизвести дефект, а тестировщик после исправления дефекта удостовериться, что тот действительно исправлен. • Очевидность для разработчиков: ещё до попытки воспроизведения дефекта видно, на самом ли деле описанное является дефектом, или тестировщик где-то ошибся, записав в дефекты корректное поведение приложения. • Избавление от лишней бессмысленной коммуникации: подробные ответы на «что сделали, что получили, что ожидали получить» позволяют решать про- блему и устранять дефект без необходимости запроса, поиска и обсуждения дополнительных сведений. • Простота: на финальных стадиях тестирования с привлечением конечных пользователей можно ощутимо повысить эффективность поступающей об- ратной связи, если объяснить пользователям суть этой формулы и попро- сить их придерживаться её при написании сообщений об обнаруженных про- блемах. Информация, полученная на данном этапе, становится фундаментом для всех дальнейших действий по написанию отчёта. Заполнить поля отчёта Поля отчёта о дефекте мы уже рассмотрели ранее {171} , сейчас лишь подчерк- нём, что начинать лучше всего с подробного описания, т.к. в процессе заполнения этого поля может выявиться множество дополнительных деталей, а также появятся мысли по поводу формулирования сжатого и информативного краткого описания. Если вы понимаете, что для заполнения какого-то поля у вас не хватает дан- ных, проведите дополнительное исследование. Если и оно не помогло, опишите в Логика создания эффективных отчётов о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 198/298 соответствующем поле (если оно текстовое), почему вы затрудняетесь с его запол- нением, или (если поле представляет собой список) выберите значение, которое, на ваш взгляд, лучше всего характеризует проблему (в некоторых случаях инстру- ментальное средство позволяет выбрать значение наподобие «неизвестно», тогда выберите его). Если у вас нет идей по поводу устранения дефекта, или он настолько тривиа- лен, что не нуждается в подобных пояснениях, не пишите в комментариях «текст ради текста»: комментарии вида «рекомендую устранить этот дефект» не просто бессмысленны, но ещё и раздражают. Перечитать отчёт (и ещё раз перечитать отчёт) После того как всё написано, заполнено и подготовлено, ещё раз внима- тельно перечитайте написанное. Очень часто вы сможете обнаружить, что в про- цессе доработки текста где-то получились логические нестыковки или дублирова- ние, где-то вам захочется улучшить формулировки, где-то что-то поменять. Идеал недостижим, и не стоит тратить вечность на один отчёт о дефекте, но и отправлять невычитанный документ — тоже признак дурного тона. После оформления отчёта о дефекте рекомендуется дополнительно ис- следовать ту область приложения, в которой вы только что обнаружили дефект. Практика показывает, что дефекты часто проявляются группами. Типичные ошибки при написании отчётов о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 199/298 2.5.7. Типичные ошибки при написании отчётов о дефектах Перед прочтением этого текста рекомендуется перечитать раздел с описа- нием типичных ошибок при составлении тест-кейсов и чек-листов {157} , т.к. многие описанные там проблемы актуальны и для отчётов о дефектах (ведь и то, и другое — специфическая техническая документация). Ошибки оформления и формулировок Плохие краткие описания (summary). Формально эта проблема относится к оформлению, но фактически она куда опаснее: ведь чтение отчёта о дефекте и осознание сути проблемы начинается именно с краткого описания. Ещё раз напом- ним его суть: • Отвечает на вопросы «что?», «где?», «при каких условиях?». • Должно быть предельно кратким. • Должно быть достаточно информативным для понимания сути проблемы. Посмотрите на эти краткие описания и попробуйте ответить себе на вопрос о том, что за проблема возникает, где она возникает, при каких условиях она воз- никает: • «Неожиданное прерывание». • «Найдено 19 элементов». • «Поиск по всем типам файлов». • «Неинформативная ошибка». • «В приложении красный шрифт». • «Error when entering just the name of computer disk or folder». • «No reaction to 'Enter' key». Иногда ситуацию спасает поле «подробное описание», из которого можно по- нять суть проблемы, но даже в этом случае сначала нужно приложить немало уси- лий, чтобы соотнести такое краткое описание с подробным, где представлено со- вершенно иное и иначе. Перечитайте ещё раз раздел про формулировку качественных кратких опи- саний {172} Идентичные краткое и подробное описания (summary и description). Да, изредка бывают настолько простые дефекты, что для них достаточно одного крат- кого описания (например, «Опечатка в имени пункта главного меню “File” (сейчас “Fille”)»), но если дефект связан с неким более-менее сложным поведением прило- жения, стоит продумать как минимум три способа описания проблемы: • краткий для поля «краткое описание» (его лучше формулировать в самом конце размышлений); • подробный для поля «подробное описание» (поясняющий и расширяющий информацию из «краткого описания»); • ещё один краткий для последнего шага в шагах по воспроизведению де- фекта. И это не интеллектуальные игры от переизбытка свободного времени, это вполне рабочий инструмент для формирования понимания сути проблемы (по- верьте, вы едва ли сможете объяснить тремя разными способами то, что не пони- маете). Типичные ошибки при написании отчётов о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 200/298 Отсутствие в подробном описании явного указания фактического ре- зультата, ожидаемого результата и ссылки на требование, если они важны, и их представляется возможным указать. Да, для мелочей наподобие опечаток в надписях этого можно не делать (и всё равно: при наличии времени лучше написать). Но что можно понять из отчёта о дефекте, в кратком и подробном описании которого сказано только «приложение показывает содержимое OpenXML-файлов»? А что, не должно показывать? В чём вообще проблема? Ну, показывает и показы- вает — разве это плохо? Ах, оказывается (!), приложение должно не показывать содержимое этих файлов, а открывать их с помощью соответствующей внешней программы. Об этом можно догадаться из опыта. Но догадка — плохой помощник в случае, когда надо переписывать приложение, — можно сделать только хуже. Это также можно (наверное) понять, вдумчиво читая требования. Но давайте будем ре- алистами: отчёт о дефекте будет отклонён с резолюцией «описанное поведение не является дефектом» («not a bug»). Игнорирование кавычек, приводящее к искажению смысла. Как вы пой- мёте такое краткое описание, как «запись исчезает при наведении мыши»? Какая- то запись исчезает при наведении мыши? А вот и нет, оказывается, «поле “Запись” исчезает при наведении мыши». Даже если не дописать слово «поле», кавычки под- скажут, что имеется в виду имя собственное, т.е. название некоего элемента. Общие проблемы с формулировками фраз на русском и английском языках. Да, нелегко сразу научиться формулировать мысль одновременно очень кратко и информативно, но не менее сложно читать подобные творения (цитаты дословные): • «Поиск не работает нажатием кнопки Enter». • «По умолчанию в поле где искать стоит +». • «При поиске файлов в обширном каталоге приложение ненадолго "зави- сает"». • «При закрытии ошибки программа закрывается». • «The application doesn't work with the from keyboard by the user in the field "What to search" ». Лишние пункты в шагах воспроизведения. Не стоит начинать «с сотворе- ния мира», большинство проектной команды достаточно хорошо знает приложение, чтобы «опознать» его ключевые части, потому — сравните: Плохо Хорошо 1. Запустить приложение. 2. Открыть пункт меню «Файл». 3. Выбрать пункт меню «Новый». 4. Заполнить текстом не менее трёх страниц. 5. Открыть пункт меню «Файл». 6. Открыть подпункт меню «Печать». 7. Открыть вкладку «Параметры печати». 8. Выбрать в списке «Двусторонняя печать» значение «Нет». 9. Распечатать документ на принтере, под- держивающем дуплексную печать. Дефект: печать по-прежнему двусторонняя. 1. Создать или открыть файл с тремя и более непустыми страницами. 2. Выбрать «Файл» -> «Печать» -> «Пара- метры» -> «Двусторонняя печать» -> «Нет». 3. Распечатать документ на принтере, под- держивающем дуплексную печать. Дефект: печать по-прежнему двусторонняя. Типичные ошибки при написании отчётов о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 201/298 Копии экрана в виде «копий всего экрана целиком». Чаще всего нужно сделать копию какого-то конкретного окна приложения, а не всего экрана — тогда поможет Alt+PrintScreen. Даже если важно захватить больше, чем одно окно, прак- тически любой графический редактор позволяет отрезать ненужную часть кар- тинки. Копии экрана, на которых не отмечена проблема. Если обвести проблем- ную область красной линией, это в разы повысит скорость и простоту понимания сути проблемы в большинстве случаев. Копии экрана и иные артефакты, размещённые на сторонних серве- рах. Эта ошибка заслуживает особого упоминания: категорически запре- щено использовать для прикрепления к отчёту о дефекте копий экрана и других файлов ставшие распространёнными в последнее время сервисы обмена изображениями, файлами и т.д. Причин здесь две: • в большинстве случаев на размещение изображения или иного файла на таких сервисах есть ограничения по времени хранения и/или количе- ству обращений (скачиваний) — иными словами, через некоторое время файл может стать недоступным; • размещение информации о проекте на сторонних сервисах является раскрытием конфиденциальной информации, права на которую принад- лежат заказчику. Поэтому для хранения любых подобных артефактов следует использо- вать саму систему управления дефектами. Если в силу неких причин та- ковая не используется, все вложения стоит разместить прямо в том доку- менте, в котором вы описываете дефект (изображения можно разместить просто «в виде картинок», иные артефакты — в виде внедрённого доку- мента). Откладывание написания отчёта «на потом». Стремление сначала найти побольше дефектов, а уже потом их описывать приводит к тому, что какие-то важ- ные детали (а иногда и сами дефекты!) забываются. Если «на потом» измеряется не минутами, а часами или даже днями, проектная команда не получает важную информацию вовремя. Вывод простой: описывайте дефект сразу же, как только об- наружили его. Пунктуационные, орфографические, синтаксические и им подобные ошибки. Без комментариев. |