Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Mantis 324 Рисунок 2.5.h — Создание отчёта о дефекте в Mantis 1. Category ( категория) содержит указание проекта или компонента приложе- ния, к которому относится описываемый дефект. 2. Reproducibility ( воспроизводимость) дефекта. Mantis предлагает нетипично большое количество вариантов: • Always (всегда). • Sometimes (иногда). • Random (случайным образом) — вариация на тему «иногда», когда не удалось установить никакой закономерности проявления дефекта. • Have not tried (не проверено) — это не столько воспроизводимость, сколько статус, но Mantis относит это значение к данному полю. 324 «Mantis Bug Tracker» [ https://www.mantisbt.org ] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Инструментальные средства управления отчётами о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 188/298 • Unable to reproduce (не удалось воспроизвести) — это не столько вос- производимость, сколько резолюция к отклонению отчёта о дефекте, но в Mantis тоже отнесено к данному полю. • N/A (non-applicable, неприменимо) — используется для дефектов, к ко- торым не применимо понятие воспроизводимости (например, про- блемы с документацией). 3. Severity ( важность) содержит указание важности дефекта. По умолчанию предложены такие варианты: • Block (блокирующий дефект) — дефект не позволяет решить с помо- щью приложения некоторую задачу. • Crash (критическая важность) — как правило, относится к дефектам, вызывающим неработоспособность приложения. • Major (высокая важность). • Minor (низкая важность). • Tweak (доработка) — как правило, косметический дефект. • Text (текст) — как правило, дефект относится к тексту (опечатки и т.д.). • Trivial (самая низкая важность). • Feature (особенность) — отчёт представляет собой не описание де- фекта, а запрос на добавление/изменение функциональности или свойств приложения. 4. Priority ( срочность) позволяет указать срочность исправления дефекта. По умолчанию Mantis предлагает следующие варианты: • Immediate (незамедлительно). • Urgent (самая высокая срочность). • High (высокая срочность). • Normal (обычная срочность). • Low (низкая срочность). • None (нет) — срочность не указана или не может быть определена. 5. Select profile ( выбрать профиль) позволяет выбрать из заранее подготовлен- ного списка профиль аппаратно-программной конфигурации, под которой проявляется дефект. Если такого списка нет или он не содержит необходи- мых вариантов, можно вручную заполнить поля 6–7–8 (см. ниже). 6. Platform (платформа) позволяет указать аппаратную платформу, под которой проявляется дефект. 7. OS (операционная система) позволяет указать операционную систему, под которой проявляется дефект. 8. OS Version (версия операционной системы) позволяет указать версию опе- рационной системы, под которой проявляется дефект. 9. Product version (версия продукта) позволяет указать версию приложения, в которой был обнаружен дефект. 10. Summary (краткое описание) позволяет указать краткое описание дефекта. 11. Description (подробное описание) позволяет указать подробное описание де- фекта. 12. Steps to reproduce (шаги по воспроизведению) позволяет указать шаги по вос- произведению дефекта. 13. Additional information (дополнительная информация) позволяет указать лю- бую дополнительную информацию, которая может пригодиться при анализе и устранении дефекта. 14. Upload file (загрузить файл) позволяет загрузить копии экрана и тому подоб- ные файлы, которые могут быть полезны при анализе и устранении дефекта. Инструментальные средства управления отчётами о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 189/298 15. View status (статус просмотра) позволяет управлять правами доступа к от- чёту о дефекте и предлагает по умолчанию два варианта: • Public (публичный). • Private (закрытый). 16. Report stay (остаться в режиме добавления отчётов) — отметка этого поля позволяет после сохранения данного отчёта сразу же начать писать следую- щий. Задание 2.5.b: изучите ещё 3–5 инструментальных средств управления жизненным циклом отчётов о дефектах, почитайте документацию по ним, посоздавайте в них несколько отчётов о дефектах. Свойства качественных отчётов о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 190/298 2.5.5. Свойства качественных отчётов о дефектах Отчёт о дефекте может оказаться некачественным (а следовательно, веро- ятность исправления дефекта понизится), если в нём нарушено одно из следующих свойств. Тщательное заполнение всех полей точной и корректной информацией. Нарушение этого свойства происходит по множеству причин: недостаточный опыт тестировщика, невнимательность, лень и т.д. Самыми яркими проявлениями такой проблемы можно считать следующие: • Часть важных для понимания проблемы полей не заполнена. В результате отчёт превращается в набор обрывочных сведений, использовать которые для исправления дефекта невозможно. • Предоставленной информации недостаточно для понимания сути проблемы. Например, из такого плохого подробного описания вообще не ясно, о чём идёт речь: «Приложение иногда неверно конвертирует некоторые файлы». • Предоставленная информация является некорректной (например, указаны неверные сообщения приложения, неверные технические термины и т.д.). Чаще всего такое происходит по невнимательности (последствия ошибоч- ного copy-paste и отсутствия финальной вычитки отчёта перед публикацией). • «Дефект» (именно так, в кавычках) найден в функциональности, которая ещё не была объявлена как готовая к тестированию. То есть тестировщик конста- тирует, что неверно работает то, что и не должно было (пока!) верно рабо- тать. • В отчёте присутствует жаргонная лексика: как в прямом смысле — нелитера- турные высказывания, так и некие технические жаргонизмы, понятные крайне ограниченному кругу людей. Например: «Фигово подцепились чартники». (Имелось в виду: «Не все таблицы кодировок загружены успешно».) • Отчёт вместо описания проблемы с приложением критикует работу кого-то из участников проектной команды. Например: «Ну каким дураком надо быть, чтобы такое сделать?!» • В отчёте упущена некая незначительная на первый взгляд, но по факту кри- тичная для воспроизведения дефекта проблема. Чаще всего это проявля- ется в виде пропуска какого-то шага по воспроизведению, отсутствию или не- достаточной подробности описания окружения, чрезмерно обобщённом ука- зании вводимых значений и т.п. • Отчёту выставлены неверные (как правило, заниженные) важность или сроч- ность. Чтобы избежать этой проблемы, стоит тщательно исследовать де- фект, определять его наиболее опасные последствия и аргументированно отстаивать свою точку зрения, если коллеги считают иначе. • К отчёту не приложены необходимые копии экрана (особенно важные для косметических дефектов) или иные файлы. Классика такой ошибки: отчёт описывает неверную работу приложения с некоторым файлом, но сам файл не приложен. • Отчёт написан безграмотно с точки зрения человеческого языка. Иногда на это можно закрыть глаза, но иногда это становится реальной проблемой, например: «Not keyboard in parameters accepting values» (это реальная ци- тата; и сам автор так и не смог пояснить, что же имелось в виду). Свойства качественных отчётов о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 191/298 Правильный технический язык. Это свойство в равной мере относится и к требованиям, и к тест-кейсам, и к отчётам о дефектах — к любой документации, а потому не будем повторяться — см. описанное ранее {133} Сравните два подробных описания дефекта: Плохое подробное описание Хорошее подробное описание Когда мы как будто бы хотим убрать папку, где что-то внутри есть, оно не спрашивает, хотим ли мы. Не производится запрос подтверждения при удалении непустого подкаталога в каталоге SOURCE_DIR. Act: производится удаление непустого подката- лога (со всем его содержимым) в каталоге SOURCE_DIR без запроса подтверждения. Exp: в случае, если в каталоге SOURCE_DIR приложение обнаруживает непустой подката- лог, оно прекращает работу с выводом сообще- ния «Non-empty subfolder [имя подкаталога] in SOURCE_DIR folder detected. Remove it manu- ally or restart application with --force_file_opera- tions key to remove automatically. » Req: UR.56.BF.4.c. Специфичность описания шагов. Говоря о тест-кейсах, мы подчёркивали, что в их шагах стоит придерживаться золотой середины между специфичностью и общностью. В отчётах о дефектах предпочтение, как правило, отдаётся специфич- ности по очень простой причине: нехватка какой-то мелкой детали может привести к невозможности воспроизведения дефекта. Потому, если у вас есть хоть малей- шее сомнение в том, важна ли какая-то деталь, считайте, что она важна. Сравните два набора шагов по воспроизведению дефекта: Недостаточно специфичные шаги Достаточно специфичные шаги 1. Отправить на конвертацию файл допусти- мого формата и размера, в котором русский текст представлен в разных кодировках. Дефект: конвертация кодировок произво- дится неверно. 1. Отправить на конвертацию файл в формате HTML размером от 100 КБ до 1 МБ, в кото- ром русский текст представлен в кодировках UTF8 (10 строк по 100 символов) и WIN-1251 (20 строк по 100 символов). Дефект: текст, который был представлен в UTF8, повреждён (представлен нечитаемым набором символов). В первом случае воспроизвести дефект практически нереально, т.к. он за- ключается в особенностях работы внешних библиотек по определению кодировок текста в документе, в то время как во втором случае данных достаточно если и не для понимания сути происходящего (дефект на самом деле очень «хитрый»), то хотя бы для гарантированного воспроизведения и признания факта его наличия. Ещё раз главная мысль: в отличие от тест-кейса отчёт о дефекте может об- ладать повышенной специфичностью, и это будет меньшей проблемой, чем невоз- можность воспроизведения дефекта из-за излишне обобщённого описания про- блемы. Свойства качественных отчётов о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 192/298 Отсутствие лишних действий и/или их длинных описаний. Чаще всего это свойство подразумевает, что не нужно в шагах по воспроизведению дефекта долго и по пунктам расписывать то, что можно заменить одной фразой: Плохо Хорошо 1. Указать в качестве первого параметра при- ложения путь к папке с исходными файлами. 2. Указать в качестве второго параметра при- ложения путь к папке с конечными файлами. 3. Указать в качестве третьего параметра при- ложения путь к файлу журнала. 4. Запустить приложение. Дефект: приложение использует первый па- раметр командной строки и как путь к папке с исходными файлами, и как путь к папке с конечными файлами. 1. Запустить приложение со всеми тремя кор- ректными параметрами (особенно обратить внимание, чтобы SOURCE_DIR и DESTINA- TION_DIR не совпадали и не были вложены друг в друга в любом сочетании). Дефект: приложение прекращает работу с сообщением «SOURCE_DIR and DESTINA- TION_DIR may not be the same !» (судя по всему, первый параметр командной строки используется для инициализации имён обоих каталогов.) Вторая по частоте ошибка — начало каждого отчёта о дефекте с запуска при- ложения и подробного описания по приведению его в то или иное состояние. Вполне допустимой практикой является написание в отчёте о дефекте приготовле- ний (по аналогии с тест-кейсами) или описание нужного состояния приложения в одном (первом) шаге. Сравните: Плохо Хорошо 1. Запустить приложение со всеми верными параметрами. 2. Подождать более 30 минут. 3. Передать на конвертацию файл допусти- мого формата и размера. Дефект: приложение не обрабатывает файл. Предусловие: приложение запущено и прора- ботало более 30 минут. 1. Передать на конвертацию файл допусти- мого формата и размера. Дефект: приложение не обрабатывает файл. Отсутствие дубликатов. Когда в проектной команде работает большое ко- личество тестировщиков, может возникнуть ситуация, при которой один и тот же дефект будет описан несколько раз разными людьми. А иногда бывает так, что даже один и тот же тестировщик уже забыл, что когда-то давно уже обнаруживал некую проблему, и теперь описывает её заново. Избежать подобной ситуации поз- воляет следующий набор рекомендаций: • Если вы не уверены, что дефект не был описан ранее, произведите поиск с помощью вашего инструментального средства управления жизненным цик- лом отчётов о дефектах. • Пишите максимально информативные краткие описания (т.к. поиск в первую очередь проводят по ним). Если на вашем проекте накопится множество де- фектов с краткими описаниями в стиле «Кнопка не работает», вы потратите очень много времени, раз за разом перебирая десятки таких отчётов в поис- ках нужной информации. • Используйте по максимуму возможности вашего инструментального сред- ства: указывайте в отчёте о дефекте компоненты приложения, ссылки на тре- бования, расставляйте теги и т.д. — всё это позволит легко и быстро сузить в будущем круг поиска. • Указывайте в подробном описании дефекта текст сообщений от приложения, если это возможно. По такому тексту можно найти даже тот отчёт, в котором остальная информация приведена в слишком общем виде. • Старайтесь по возможности участвовать в т.н. «собраниях по прояснению» Свойства качественных отчётов о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 193/298 (clarification meetings 325 ), т.к. пусть вы и не запомните каждый дефект или каж- дую пользовательскую историю дословно, но в нужный момент может воз- никнуть ощущение «что-то такое я уже слышал», которое заставит вас про- извести поиск и подскажет, что именно искать. • Если вы обнаружили какую-то дополнительную информацию, внесите её в уже существующий отчёт о дефекте (или попросите сделать это его автора), но не создавайте отдельный отчёт. Очевидность и понятность. Описывайте дефект так, чтобы у читающего ваш отчёт не возникло ни малейшего сомнения в том, что это действительно де- фект. Лучше всего это свойство достигается за счёт тщательного объяснения фак- тического и ожидаемого результата, а также указания ссылки на требование в поле «Подробное описание». Сравните: Плохое подробное описание Хорошее подробное описание Приложение не сообщает об обнаруженных подкаталогах в каталоге SOURCE_DIR. Приложение не уведомляет пользователя об обнаруженных в каталоге SOURCE_DIR подка- талогах, что приводит к необоснованным ожи- даниям пользователями обработки файлов в таких подкаталогах. Act: приложение начинает (продолжает) ра- боту, если в каталоге SOURCE_DIR находятся подкаталоги. Exp: в случае если в каталоге SOURCE_DIR приложение при запуске или в процессе работы обнаруживает пустой подкаталог, оно автома- тически его удаляет ( логично ли это? ), если же обнаружен непустой подкаталог, приложение прекращает работу с выводом сообщения «Non-empty subfolder [имя подкаталога] in SOURCE_DIR folder detected. Remove it manu- ally or restart application with --force_file_opera- tions key to remove automatically. » Req: UR.56.BF.4.c. В первом случае после прочтения подробного описания очень хочется спро- сить: «И что? А оно разве должно уведомлять?» Второй же вариант подробного описания даёт чёткое пояснение, что такое поведение является ошибочным со- гласно текущему варианту требований. Более того, во втором варианте отмечен вопрос (а в идеале нужно сделать соответствующую отметку и в самом требова- нии), призывающий пересмотреть алгоритм корректного поведения приложения в подобной ситуации: т.е. мы не только качественно описываем текущую проблему, но и поднимаем вопрос о дальнейшем улучшении приложения. Прослеживаемость. Из содержащейся в качественном отчёте о дефекте ин- формации должно быть понятно, какую часть приложения, какие функции и какие требования затрагивает дефект. Лучше всего это свойство достигается правиль- ным использованием возможностей инструментального средства управления отчё- тами о дефектах: указывайте в отчёте о дефекте компоненты приложения, ссылки на требования, тест-кейсы, смежные отчёты о дефектах (похожих дефектах; зави- симых и зависящих от данного дефектах), расставляйте теги и т.д. Некоторые инструментальные средства даже позволяют строить визуальные схемы на основе таких данных, что позволяет управление прослеживаемостью 325 Clarification meeting . A discussion that helps the customers achieve “advance clarity” — consensus on the desired behavior of each story — by asking questions and getting examples. [«Agile Testing», Lisa Crispin, Janet Gregory] Свойства качественных отчётов о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 194/298 даже на очень больших проектах превратить из непосильной для человека задачи в тривиальную работу. Отдельные отчёты для каждого нового дефекта. Существует два незыб- лемых правила: • В каждом отчёте описывается ровно один дефект (если один и тот же де- фект проявляется в нескольких местах, эти проявления перечисляются в по- дробном описании). • При обнаружении нового дефекта создаётся новый отчёт. Нельзя для опи- сания нового дефекта править старые отчёты, переводя их в состояние «от- крыт заново». Нарушение первого правила приводит к объективной путанице, которую проще всего проиллюстрировать так: представьте, что в одном отчёте описано два дефекта, один из которых был исправлен, а второй — нет. В какое состояние пере- водить отчёт? Неизвестно. Нарушение второго правила вообще порождает хаос: мало того, что теряется информация о ранее возникавших дефектах, так к тому же возникают проблемы со всевозможными метриками и банальным здравым смыслом. Именно во избежание этой проблемы на многих проектах правом перевода отчёта из состояния «закрыт» в состояние «открыт заново» обладает ограниченный круг участников команды. |