Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Rules_of_testing_full.doc
Скачиваний:
7
Добавлен:
04.11.2018
Размер:
198.66 Кб
Скачать

Отчет о проблеме

В компании отчеты о проблеме составляются в виде описания баги в баг-листе. Баг-лист (bug-list) является единственным документом, несущим полную информацию о найденных ошибках продукта (в обиходе сотрудников компании ошибка – бага). В баг-лист заносится информация о характере баги, об условиях ее проявления (среде тестирования), о ее исправлении. В баг-лист заносятся как баги, найденные группой тестирования проекта, так и баги, присланные заказчиком. Стиль баг-листа должен быть доброжелательным и конструктивным, стимулирующим партнерские отношения с девелоперами для достижения общих целей – качественного выполнения проектных задач. Беспристрастность и отсутствие эмоциональности – признак хорошего тона в описании баги.

Правила написания description («описания») баги в баг-лист.

1)Описание баги должно содержать не менее 20-30 слов, не считая артиклей; предлогов; союзов; междометий и т.п. Описания упрощенного типа: «Start the application. Application doesn’t run» не допускаются.

2) Используются короткие предложения с простой структурой, без сложносочиненных и сложноподчиненных предложений, без причастных и деепричастных оборотов. Описание баги должно быть преимущественно в Present и Past Indefinite временах в действительном залоге.

3) Будущие времена (и будущее в прошедшем) не допускаются – так как ошибок в «будущем» не бывает, ошибка – это зафиксированное событие, которое уже произошло к настоящему моменту.

4) Обязательно обстоятельно, пошагово описать условия возникновения баги, чтобы можно было без проблем добиться её воспроизведения на другой машине и другим пользователем.

Содержание описания должно соответствовать следующей схеме:

а) описание исходной ситуации - что было;

б) описание произведенных действий - что сделал;

в) описание полученного результата - что получилось;

г) описание того, что получилось - что не так и как должно быть правильно. Желательно с указанием документа-источника правильного состояния – например, дизайна или спецификации.

Приложение 1 Примеры некоторых наиболее распространенных проблем Ошибки пользовательского интерфейса

Понятие пользовательского интерфейса объединяет все аспекты продук­та, с которыми имеет дело его пользователь. Разработчики пользовательс­кого интерфейса пытаются достичь компромисса между такими факторами, как:

• функциональность;

• быстрота изучения программы новым пользователем;

• легкость запоминания необходимых приемов работы;

• производительность;

• вероятность возникновения ошибок пользователя;

• удовлетворенность пользователя программой.

Проектируя пользовательский интерфейс, конструктор программы учи­тывает опыт и нужды ее будущих пользователей, а также возможности аппаратного обеспечения.

Для достижения разумного баланса между всеми перечисленными характеристиками программы дизайнеру, так или иначе, приходится чем-то жертвовать. Поэтому, если в программе встретится одна из перечисленных ниже ошибок пользовательского интерфейса, она вполне может, оказался не случайной ошибкой, а намеренной уступкой, сделан­ной дизайнером ради улучшения другой составляющей качества продук­та. Прежде чем составлять отчет об ошибке пользовательского интерфейса, спросите у дизайнера, почему программа спроектирована именно так. Возможно, окажется, что он принял в данном вопросе самое оптимальное решение.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]