Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 4. Проектирование и разработка тестов 117 • Разработка методики тестирования, обладающей требуемым уровнем дета лизации. • Автоматизация часто используемых тестов, требующих больших затрат времени. • Перевод тестовых примеров под управление конфигурациями. • Определение настройки и очистки тестов с учетом их взаимозависимости. • Пересмотр методик тестирования. • Проверка автоматизированных тестов с использованием статических и дина мических средств. В результате выполнения всех этих действий будет получен набор отлаженных тестовых случаев, который может использоваться для проведения системных испы таний. В следующей главе мы рассмотрим, что требуется для прогона тестов, доку ментирования выявленных дефектов и составления отчетов по результатам выпол нения тестов. Системные испытания Темы, рассматриваемые в главе: • О б н а р у ж е н и е и о т с л е ж и в а н и е д е ф е к т о в • П р о г о н т е с т о в • С о с т а в л е н и е о т ч е т о в по результатам т е с т и р о в а н и я • К р и т е р и й выхода из и с п ы т а н и й и г о т о в н о с т ь выпуска п р о г р а м м н о г о продукта • Ч т о дальше Для профессионального тестировщиков программного обеспечения стадия систем ных испытаний — это то же, что игровой день для футболиста или день спектакля для театрального актера. Проделана большая работа по планированию, все подготови тельные работы завершены, наступило время действовать. Как показано на рис. 5.1, первое, что нужно сделать, это проверить, все ли на месте и все ли готово. Все эти мероприятия могут быть дополнены применением критериев входа в системные ис пытания, определения которых включаются в план проведения испытаний. Крите рий входа в испытания принимает форму опросного листа: составлен ли, пересмот рен и утвержден план проведения испытаний? Завершила ли группа разработчиков запланированное тестирование модулей и проверку взаимодействия и функциониро вания компонентов программного продукта? Проведены ли испытания "на герме тичность" с целью удостовериться в том, что тестируемая программа может быть ус тановлена и, по меньшей мере, способна продемонстрировать открытый экран? Если достигнуто соответствие критериям вхождения в испытания, тестирование системы можно начинать. Начало тестирования обычно представляет собой важный этап графика проектных работ. В идеальном случае задержка системных испытаний преобразуется в задержку поставки программного продукта, хотя группу тестирова ния часто просят отыскать возможности ускорить испытания, чтобы программный продукт был поставлен во время. Несмотря на риск использования слишком многих аналогий, добавим еще одну: если сравнить разработку программного продукта с эс тафетой, то группа тестирования пробегает последний этап гонки. Если бегуны на предыдущих этапах проигрывают своим соперникам, то нереально надеяться на то, что спортсмен, бегущий на последнем этапе, - это супермен, способный наверстать Глава 5. Системные испытания 119 ранее упущенное. Реально это или нереально, но на практике ситуация, складываю щаяся в бизнесе, часто приводит к необходимости ускоренного выполнения стадии тестирования, поэтому всегда нужно быть готовым применить тестирование по при оритетам и другие планы на случай непредвиденных обстоятельств с целью смягче ние последствий от овеществления рисков нарушения графика работ. . На приемочные испытания или выпуск программного продукта Рис. 5.1. Обзор системных испытаний Основу тестирования составляет прогон тестов, включенных в план проведения испытаний. В результате прогона тестов обнаруживаются различные дефекты и вы даются сообщения об обнаруженных дефектах. При этом данные, обеспечивающие возможность отслеживания дефектов, вводятся в специальную базу данных, в кото рой хранится информация, предназначенная для отслеживания дефектов. В следую щем разделе, "Обнаружение и отслеживание дефектов", эти аспекты тестирования рассматриваются более подробно. Во время прогона тестов результаты тестирования должны передаваться другим подразделениям организации. Все, кто принимает участие в разработке, маркетинге или в руководстве проектом, должны знать, как продвигается тестирование, сколько и какие типы дефектов были обнаружены. По окончании тестирования должен быть подготовлен отчет, в котором подводятся итоги тестирования. В этом отчете должен использоваться набор критериев для оценки готовности программного продукта к выпуску. Например, если были выполнены все запланированные тесты, но еще оста ется какое-то допустимое число неустраненных дефектов, группа тестирования мо жет утверждать, что программный продукт соответствует требованиям, предъявляе мым к нему заказчиком, благодаря чему можно начинать поставки. 120 Часть I. Процесс быстрого тестирования Обнаружение и отслеживание дефектов Цель тестирования заключается в нахождении дефектов. Однако недостаточно толь ко отыскать дефекты. Об их наличии должным образом должны быть оповещены разработчики, чтобы они смогли эти дефекты устранить, а сведения о результатах выполненных ими исправлений доводятся до заинтересованных служб с тем, чтобы график разработки программного продукта не нарушался. Любые неэффективные действия при оповещении о дефектах, об их отслеживании, устранении и контроле приводят к потере времени. В связи со сказанным выше, следующие два вида деятельности считаются основ ными при выявлении дефектов. Первым из них является прогон тестов в соответст вии с планом проведения испытаний для выяснения, имеются ли какие-либо расхож дения между ожидаемыми и фактическими результатами тестирования. Вторым ви дом деятельности является качественное документирование в системе отслеживания дефектов всех отклонений, обнаруженных во время тестирования. Хорошее качество документации важно по двум причинам — во-первых, разработчикам нужна достовер ная и надежная информация для того, чтобы снять все порождаемые неисправностя ми проблемы, и, во-вторых, тестировщики должны иметь возможность воспроизве сти проблемы, чтобы убедиться, что внесенные изменения устранили дефект. Систе ма, применяемая для документирования и отслеживания дефектов, представляет со бой важное инструментальное средство тестирования программного обеспечения. Несколько последующих разделов посвящаются изучению системы отслеживания дефектов, анализу состояний дефектов, изменению состояний дефектов и изучению других важных аспектов документирования и отслеживания дефектов. Определение состояний дефектов В главе 1 отмечалось, что дефектом является ошибка в рабочем документе, таком как технические требования, план проведения испытаний или программный код. Дефект остается необнаруженным до тех пор, пока рабочий продукт не будет подвергнут пе ресмотру или не будет выполнен прогон программы, во время которого программа выдаст ожидаемые результаты. После нахождения дефект подвергается анализу с целью определения, представ ляет ли он неисправность теста, ошибку в программном коде или дефект в проектных спецификациях. Если источником проблемы является тест, а не программный код, то тест должен быть исправлен, а обнаруженный дефект "проигнорирован". Проверяет ся также, насколько серьезен дефект: принадлежит ли рассматриваемый дефект к категории катастрофических, подлежащих обязательному устранению перед постав кой программного продукта? Является ли возникшая проблема настолько серьезной, что она существенно снижает функциональные возможности программного продук та, но при этом все еще остаются открытыми обходные пути, позволяющие продол жать процессы тестирования и разработки? Либо же эта проблема не настолько кри тична, что ее решение нельзя отложить до будущих выпусков программного про дукта? Программный код, содержащий обнаруженный дефект, должен быть направлен разработчикам для исправлений. Нужно внимательно следить за стадиями исправле ния, чтобы не потерять из виду сам дефект. Один из эффективных способов отеле- Глава 5. Системные испытания 121 живания дефекта состоит в четком определении явных состояний, которые может принимать дефект на пути от его обнаружения до завершающего тестирования. Каж дое состояние должно быть недвусмысленным и обладать набором определений критериев входа и выхода из испытания. В таблице 5.1 показан пример определения состояний дефекта. Названия состоя ний в каждой компании могут быть свои, возможны также дополнительные состоя ния, которые не указаны в этой таблице. В ней показан обобщенный набор названий и состояний, который, возможно, стоит использовать как отправную точку при соз дании системы отслеживания дефектов "с нуля". Таблица 5.1. Определение категории дефекта Категория дефекта Ответственность Описание Новый (new) Исправить (fix) Отложить (defer) Игнорировать (trash) Исправлено (repair) Исправлено и проверено (fix verified) Группа тестирования Группа разработки Группа анализа дефектов Группа анализа дефектов Группа разработки Группа тестирования Дефект был обнаружен во время тестирования, этот факт был отражен в отчете, однако разра ботчик не получил распоряжения устранить про блему. Разработчик получил распоряжение устранить проблему, и соответствующие работы ведутся. Принято решение о том, чтобы отложить работы по устранению дефекта до последующих выпус ков программного продукта. Дефект был получен по ошибке, программный продукт работает в соответствии с проектным замыслом, возможны и другие причины того, что решено ничего не делать по устранению дефекта. Разработчик выявил и устранил основную причи ну дефекта и выполнил предварительное тести рование с целью убедиться в том, что проблема решена. Специалист по тестированию проверил исправ ление, используя для этой цели ту же методику тестирования и конфигурацию средств тестиро вания, которые позволили первоначально обна ружить дефект. Отслеживание дефекта на протяжении его жизненного цикла, от его обнаружения до устранения и проверки правильности исправления, показывает, что он меняет свое состояние в соответствии с некоторым набором правил. На рис. 5.2 приведен пример изменения состояний дефекта. Дефект обнаруживается во время пересмотра или в процессе системных испытаний и попадает в систему отслеживания дефектов, будучи в состоянии "новый". Ему присваивается уровень серьезности, после чего он передается на рассмотрение в группу анализа дефектов. Группа анализа дефектов (известная в некоторых кругах как группа контроля за внесением изменений в техни ческую документацию) определяет, нужно ли исправлять дефект в рамках текущего выпуска или отложить это до будущих версий. Если группы разработчиков и тести- ровщиков провели дальнейший анализ уже после того, как дефект был зафиксирован, и пришли к заключению, что в программный код не содержит каких-либо проблем, 122 Часть I. Процесс быстрого тестирования требующих его исправления, то группа анализа дефектов может принять решение не обращать на него внимания. Действие, предпринятое группой анализа дефектов, до кументируется, а сам дефект может находиться в состоянии "исправить", "отложить" или "игнорировать". Если принято решение исправлять дефект, то эта работа поручается разработчи ку, который вносит соответствующие изменения в программный код и проводит тес тирование, дабы удостовериться, что исправленный код работает правильно. Как только разработчик придет к выводу, что дефект устранен, он меняет состояние де фекта на "исправлено" и включает исправленный код в сборку, направляемую на сис темные испытания. Если тестировщик убеждается в том, что дефект устранен, то по следний переходит в окончательное состояние "исправлено и проверено". Глава 5. Системные испытания 123 Если вы не обладаете опытом тестирования или работаете в компании, которая не использует мощных промышленный средств отслеживания дефектов, возможно, воз никнет впечатление, что методология отслеживания дефектов, в основе которой ле жит состояние дефекта, чересчур избыточна и громоздка. Если вы занимаетесь раз работкой программного продукта, выпуски которого редко когда содержат более 40 или 50 дефектов, то вы, скорее всего, правы. Однако в условиях разработки множест ва различных проектов количество дефектов, требующих отслеживания, достигае i многих сотен и даже тысяч. Если система отслеживания неэффективна, или если х<> тя бы всего лишь несколько заметных серьезных дефектов просочатся в поставляв мый программный продукт, руководству вашей испытательной лаборатории прел стоят довольно-таки неприятные объяснения с заказчиком. По причине исключительной важности системы отслеживания дефектов для тес тирования программного обеспечения, следующие несколько разделов посвящаются обсуждению ее базовых характеристик. Базовые характеристики системы отслеживания дефектов В момент самого первого столкновения с дефектом необходимо собрать о нем боль шую порцию информации, чтобы облегчить задачу его последующего устранения Пример информации о вновь обнаруженном дефекте, которую необходимо записать в системе отслеживания дефектов, приводится в таблице 5.2. В этой таблице приво дится список параметров с кратким описанием каждого параметра и причины необ ходимости его регистрации. Если для отслеживания дефектов применяются инстр\ ментальные средства управления базами данных, параметры, представленные в пер вом столбце, соответствуют полям базы данных. Таблица 5.2. Данные о дефекте, пребывающем в состоянии "Новый" Характеристика Описание Обоснование Идентификатор дефекта Состояние дефекта Кем обнаружен Дата обнаружения дефекта Обнаружен в сборке Уникальный идентификатор дефекта, обычно это строка алфавитно-цифровых символов. Одно из допустимых состоя ний; в рассматриваемом слу чае таким состоянием являет ся "новый". Имя исполнителя, обнаружив шего дефект. По меньшей мере, день/месяц/год; в этом поле может также быть указано время в часах и минутах. Уникальный идентификатор сборки программного обеспе чения, проходящего тестиро вание. Позволяет отслеживать дефект в про цессе изменения его состояний и логи чески связать с дефектом всю его обра ботку. Присвоить дефекту состояние "новый" в момент его обнаружения. Обеспечивает возможность задавать вопросы относительно дефекта. Позволяет отслеживать хронологию событий, связанных с дефектом. Время в часах и минутах может оказаться полезным при отладке, если возникнет необходимость восстановить последо вательность тестовых событий. Этот показатель позволяет разработчи кам выявить источник проблемы и дает возможность разработчику или тести- ровщику воспроизвести проблему. 124 Часть I. Процесс быстрого тестирования Окончание табл. 5.2 Характеристика Описание Обоснование Идентификатор Краткое описание проблемы Описание проблемы Степень серьезности дефекта Как воспроизвести проблему Уникальный идентификатор теста, во время прогона кото рого возникла проблема. Если эта проблема была обнаруже на во время специализирован ного тестирования,это поле может быть помечено как NA (not applicable - не примени мое). Описание проблемы на кон цептуальном уровне. Обычно такое описание дефекта уме щается в одной строке. Детальное описание симпто мов проблемы и того, как она ограничивает функциональные возможности или производи тельность системы. Упорядочивание дефектов по степени серьезности послед ствий. Примеры: Катастрофический - вызыва ет разрушение системы Крупный - программный про дукт не подлежит использова нию Умеренный - продукт можно использовать, однако имеют место некоторые неудобства для пользователя Незначительный - пользова тель не ощущает последствий Помеха - можно устранить, когда позволит время. Используется детально прора ботанная методика воспроиз ведения проблемы, включая выбор используемой конфигу рации средств тестирования. Может оказаться достаточным сказать: "Выполнить прогон теста с идентификатором та ким-то", если этот тест хорошо документирован. Снабжает разработчика и тестировщика сведениями о том, прогон какого теста выполнять, чтобы воспроизвести про блему. Тест, который обнаруживает проблему, должен стать частью регрес сивного тестирования, предназначенно го для того, чтобы убедиться, что дальнейшие программные сборки не нужно подвергать регрессивному тести рованию. Это описание используется в сообщени ях о статусе дефекта и в отчетных док ладах и адресовано руководству проекта и членам других групп, стремящихся к пониманию проблемы во всех деталях. Это описание предназначено для тех, кому требуется детальное понимание проблемы, например, разработчику, который работает над устранением дефекта, или руководителю, распреде ляющему ресурсы. Серьезность последствий часто опреде ляет приоритеты усилий разработчиков при устранении дефектов и тестировщи- ков при проверке результатов этих ис правлений. Детально проработанная методика по зволяет разработчикам воспроизвести дефект и предоставляет возможность разработчикам и тестировщикам прове рять результаты устранения проблемы. Глава 5. С и с т е м н ы е и с п ы т а н и я 125 Каждый дефект получает в базе данных отслеживания дефектов уникальный идентификатор, так называемый идентификатор дефекта. Идентификатор дефектов представляет собой ключ, который поддерживает запросы, поступающие в базу дан ных с таким расчетом, чтобы можно было получить информацию о его состоянии, которое можно рассматривать как показатель продвижения работ по его устранению. В базе данных отслеживания дефектов должны храниться сведения о том, кто обна ружил дефект, когда он был обнаружен, уровень серьезность дефекта, а также под робное описание проблем, которые он вызвал. Если дефект был обнаружен во время системных испытаний, должна быть записана информация, касающаяся теста, кото рый выявил этот дефект. Для хорошо документированного тестового случая вполне достаточно запомнить только идентификатор теста. Если тест не задокументирован должным образом или если дефект был обнаружен в результате специализированного (ad hoc) тестирования, необходимо записать информацию о конфигурации средств тестирования и о специальных действиях, выполненных для обнаружения этого де фекта. Пример отчета о дефекте, который может использоваться для целей докумен тирования, приводится далее в разделе "Как составлять сообщения о дефектах". Данные о дефекте, попадающие в базу данных отслеживания дефектов, должны быть изучены группой анализа обнаруженных дефектов (или группой контроля за внесением изменений) с целью определения степени серьезности дефекта. На самом ли деле это дефект? Правильная ли степень серьезности была присвоена обнаружен ному дефекту? Должен ли он быть устранен в текущем выпуске программного продук та? И н ф о р м а ц и я , которая должна быть внесена в базу данных отслеживания дефек тов по результатам работы группы анализа дефектов, показана в таблице 5.3. В ре зультате анализа дефект переводится в одно из следующих трех состояний: • Исправить (fix) — дефект переходит в это состояние, если группа анализа ре шит, что данных дефект должен быть исправлен в текущем выпуске. • Отложить (defer) — дефект переводится в это состояние, если группа анализа решит отложить устранение этого дефекта до последующих выпусков про граммного продукта. • Игнорировать (trash) — дефект переходит в это состояние, если группа анали за решила, что дефект был внесен по ошибке. В зависимости от итогового состояния дефекта, в базу данных отслеживания де фектов вводятся различные данные. Например, если дефект двигается в направлении состояния "исправить", следует ввести имя исполнителя, ответственного за устране ние дефекта. Если информация относительно дефекта готовится для передачи заказ чикам, должен быть введен текст пояснительной записки по выпуску. Более подроб ная информация, касающаяся анализа дефектов, будет изложена в разделе "Анализ дефектов". Как показано в таблице 5.4, окончательный набор данных нужно вводить в систе му отслеживания дефектов во время исправления дефекта. Необходимо зафиксиро вать имя исполнителя, исправляющего дефект, дату исправления и идентификатор сборки, в которой производилось исправление. Должно быть дано подробное объяс нение основной причины проблемы, чтобы группа разработки могла воспроизвести и устранить проблему. 126 Часть I. Процесс быстрого тестирования Таблица 5.3. Данные отслеживания дефекта в состояниях "исправить" (fix), "отложить" (defer) и "игнорировать" (trash) Характеристика Описание Обоснование Идентификатор дефекта (не изменяется) Состояние дефекта Кто исправил Кем отложен срок исправления Кто проигнорировал дефект Дата начала исправления Дата, когда исправ ление было отложено Дата, когда было принято решение не делать исправления. Нужна пояснитель ная записка к выпуску (Y/N)? Уникальный идентификатор дефекта Состояния "исправить" и "игнорировать" отложить Имя исполнителя, которому пору чено устранить дефект. Имя ответственного лица, которое своим решением отодвинуло ис правления дефекта на более поздний срок (оставить поле пус тым, если исправление дефекта не отложено). Имя ответственного лица, которое приняло решение не исправлять дефект (оставить поле пустым, если исправление дефекта не откладывалось). День, месяц и год, когда устране ние дефекта было поручено раз работчику, ответственному за исправления. День, месяц и год, когда исправ ление было отложено. День, месяц и год, когда было принято решение не делать ис правления. Введите "Y", если нужна поясни тельная записка к выпуску, и "N", если такая пояснительная записка не нужна. Позволяет отслеживать дефект в процессе изменения его состояний Присвоить дефекту состояние "ис править" в момент его отправки раз работчикам на исправление;присво ить дефекту состояние "отложить", если он будет устранен в следую щем выпуске программного продук та; присвоить дефекту состояние "игнорировать", если его нельзя вос произвести или если проблема за-_ ключается не в дефекте, а в чем-то другом; дефект игнорируется также в случае, когда принято решение не исправлять его. Обеспечивает возможность задавать вопросы относительно исправления дефекта. Обеспечивает возможность задавать вопросы относительно решения от ложить исправление дефекта на более поздний срок. Обеспечивает возможность задавать вопросы относительно решения не исправлять дефект. Позволяет отслеживать хронологию событий, связанных с дефектом. Позволяет отслеживать хронологию событий, связанных с дефектом. Позволяет отслеживать хронологию событий, связанных с дефектом. Помечает дефект флагами таким образом, чтобы можно было соста вить список дефектов, для которых требуются пояснительные записки к выпуску. Глава 5. Системные испытания 127 Окончание табл. 5.3 Характеристика Описание Обоснование Информация о Описание дефекта, которое будет выпуске передано заказчику как составная программного часть пояснительных записок, продукта прилагаемых к выпуску (необхо димы только в тех случаях, когда дефекты не исправлены в кон кретном выпуске). Таблица 5.4. Данные отслеживания дефекта в состояниях "исправлено" (repaired) и "исправлено и проверено" (fix verified) Характеристика Описание Обоснование Идентификатор дефекта (не изменяется) Состояние дефекта Кто вносил исправления Кто проверял исправления Дата, когда исправ ление было сделано Дата, когда исправ ление было прове рено Исправление внесе но в сборку Описание исправления Уникальный идентификатор дефекта Состояния "исправлено", "исправлено и проверено". Имя исполнителя, который устра нял дефект. Имя исполнителя, который прове рял исправления. День, месяц и год, когда исправ ление было внесено в код. День, месяц и год, когда исправ ление было проверено. Уникальный идентификатор сборки, в которую будет внесено исправление. Объяснение основной причины проблемы и как она была исправ лена. Позволяет отслеживать дефект в процессе изменения его состояний Присвоить дефекту состояние "ис правлено", когда исправление вне сено в основание кода; присвоить дефекту состояние "исправлено и проверено", когда специалист по тестированию подтвердил,что исправленный код работает пра вильно. Обеспечивает возможность задавать вопросы относительно исправления дефекта. Обеспечивает возможность задавать вопросы относительно проверки исправления дефекта. Позволяет отслеживать хронологию событий, связанных с дефектом Позволяет отслеживать хронологию событий, связанных с дефектом Позволяет тестировщику знать, ка кую сборку следует использовать, чтобы проверить исправление; если исправление дефекта отложено до последующих выпусков программно го продукта, то это поле показывает, в рамках какого выпуска планируется внести исправление. Препятствует возникновению подоб ных проблем в будущем; помогает разработчику и тестировщику выяв лять другие дефекты, имеющие отношение к первоначальной про блеме. 128 Часть I. Процесс быстрого тестирования В таблицах с 5.1 по 5.4 дано краткое описание некоторых основных свойств, кото рыми должна обладать система отслеживания дефектов. Можно построить собствен ное инструментальное средство отслеживания дефектов, тем не менее, существуют различные серийно выпускаемые инструментальные средства, позволяющие сэконо мить массу времени и усилий, которые пришлось бы потратить на разработку эффек тивной системы отслеживания дефектов. Набор возможностей и удобство и простота использования вашей системы отслеживания дефектов существенно влияет на эф фективность применяемой организации тестирования, поэтому выбор системы от слеживания дефектов следует производить максимально аккуратно. В следующем разделе дано описание формата сообщения о дефекте, который хо рошо вписывается в только что приведенную общую схему. Как составлять сообщения о дефектах Каждый раз, когда обнаруживается новый дефект, должно составляться письменное сообщение об этом дефекте. Если информация о дефекте не будет получена доста точно оперативно, могут возникнуть трудности при восстановлении обстоятельств, которые привели к возникновению проблемы. Это тем более справедливо, если при меняются специализированные виды тестирования. Если выполняется прогон доку ментированного тестового случая, то его исход может быть обозначен как неудач ный, а отличия фактических результатов тестов от ожидаемых могут быть зарегист рированы как составная часть прогона теста. Как только специализированный вид тестирования обнаруживает проблему или как только прогон теста завершен, должно быть составлено сообщение о дефекте. П р и м е р шаблона сообщения о дефекте показан на рис. 5.3. Этот шаблон может быть представлен в форме печатного бланка, который вручную заполняется тести- ровщиком, в виде шаблона ввода данных в Web-формате или как часть базы данных системы отслеживания дефектов. Такой шаблон сообщения о дефекте представляет собой средство сбора тестовых данных, которые отображаются в таблице 5.2. От умения специалистов по тестированию составить толковое сообщение о де ф е к т е в значительной мере зависит успех их деятельности. Часто время, затрачивае мое тестировщиками на изучение сообщений о дефектах, которые были составлены их организациями во время разработки аналогичных проектов, приносит большую пользу. В идеальном случае имеется набор "золотых примеров", который дает воз можность тестировщикам, не имеющим достаточного опыта, получить понимание того, что такое высококачественное сообщение о дефекте и какие факторы делают такое сообщение неэффективным. Вообще говоря, сообщение о дефекте считается плохо составленным или неэф фективным, если: • О н о составлено по ошибке — дефект, описанный в сообщении, не существует. • Возникшая проблема представлена в описании нечетко или неоднозначно — проблема, возможно, и существует, но в то же время она описана настолько плохо, что поведение системы не ясно. • О н о не содержит информации, необходимой разработчику для воссоздания проблемы — признаки проблемы описаны, но при этом отсутствуют пояснения к действиям, которые послужили причиной возникновения проблемы. |