- •Правила тестирования программ
- •Терминология
- •Выбор стратегии тестирования
- •Категории программных ошибок
- •Правила тестирования
- •Правила тестирования пользовательского интерфейса (взаимодействия программы с пользователем)
- •Правила тестирования функциональности
- •Правила тестирования производительности.
- •Правила тестирования надежности.
- •Правила тестирования пользовательской документации.
- •Правила тестирования инсталляции/деинсталляции.
- •Правила воспроизводимости ошибок.
- •Правила тестирования граничных условий.
- •Отчет о проблеме
- •Приложение 1 Примеры некоторых наиболее распространенных проблем Ошибки пользовательского интерфейса
- •Функциональность
- •Приложение 2 Примеры применения некоторых приемов тестирования
Отчет о проблеме
В компании отчеты о проблеме составляются в виде описания баги в баг-листе. Баг-лист (bug-list) является единственным документом, несущим полную информацию о найденных ошибках продукта (в обиходе сотрудников компании ошибка – бага). В баг-лист заносится информация о характере баги, об условиях ее проявления (среде тестирования), о ее исправлении. В баг-лист заносятся как баги, найденные группой тестирования проекта, так и баги, присланные заказчиком. Стиль баг-листа должен быть доброжелательным и конструктивным, стимулирующим партнерские отношения с девелоперами для достижения общих целей – качественного выполнения проектных задач. Беспристрастность и отсутствие эмоциональности – признак хорошего тона в описании баги.
Правила написания description («описания») баги в баг-лист.
1)Описание баги должно содержать не менее 20-30 слов, не считая артиклей; предлогов; союзов; междометий и т.п. Описания упрощенного типа: «Start the application. Application doesn’t run» не допускаются.
2) Используются короткие предложения с простой структурой, без сложносочиненных и сложноподчиненных предложений, без причастных и деепричастных оборотов. Описание баги должно быть преимущественно в Present и Past Indefinite временах в действительном залоге.
3) Будущие времена (и будущее в прошедшем) не допускаются – так как ошибок в «будущем» не бывает, ошибка – это зафиксированное событие, которое уже произошло к настоящему моменту.
4) Обязательно обстоятельно, пошагово описать условия возникновения баги, чтобы можно было без проблем добиться её воспроизведения на другой машине и другим пользователем.
Содержание описания должно соответствовать следующей схеме:
а) описание исходной ситуации - что было;
б) описание произведенных действий - что сделал;
в) описание полученного результата - что получилось;
г) описание того, что получилось - что не так и как должно быть правильно. Желательно с указанием документа-источника правильного состояния – например, дизайна или спецификации.
Приложение 1 Примеры некоторых наиболее распространенных проблем Ошибки пользовательского интерфейса
Понятие пользовательского интерфейса объединяет все аспекты продукта, с которыми имеет дело его пользователь. Разработчики пользовательского интерфейса пытаются достичь компромисса между такими факторами, как:
• функциональность;
• быстрота изучения программы новым пользователем;
• легкость запоминания необходимых приемов работы;
• производительность;
• вероятность возникновения ошибок пользователя;
• удовлетворенность пользователя программой.
Проектируя пользовательский интерфейс, конструктор программы учитывает опыт и нужды ее будущих пользователей, а также возможности аппаратного обеспечения.
Для достижения разумного баланса между всеми перечисленными характеристиками программы дизайнеру, так или иначе, приходится чем-то жертвовать. Поэтому, если в программе встретится одна из перечисленных ниже ошибок пользовательского интерфейса, она вполне может, оказался не случайной ошибкой, а намеренной уступкой, сделанной дизайнером ради улучшения другой составляющей качества продукта. Прежде чем составлять отчет об ошибке пользовательского интерфейса, спросите у дизайнера, почему программа спроектирована именно так. Возможно, окажется, что он принял в данном вопросе самое оптимальное решение.