Тестирование
Автор:John W. Rittinghouse Перевод:Гуров А.В.
Краткий обзор
Эта глава объясняет циклический процесс испытания продукта, возвращение его к команде для дальнейших модификаций, и начала переиспытательной последовательности. Это покрывает аспекты управления проведения формализованного испытательного процесса. Но не покрывает детализированные процедуры для процесса испытания.
Материал в этой главе поможет и испытателю и диспетчеру программы понять, какие области испытания, какие типы испытательных случаев должны быть построены, чтобы соответственно покрыть самые общие аспекты выпуска продукта. Это поможет менеджерам учиться спрашивать определенные вопросы, о каждом аспекте испытания, это гарантирует, что они сосредоточат свои команды на выполнении надлежащего испытания.
Поскольку мы начинаем рассматривать фазу тестирования, давайте посмотрим на Фазу SEP V схема (иллюстрация 6.1) этой фазы. Схема показывает, что только несколько шагов должны быть достигнуты членами проектной команды; однако, не будьте обмануты ее простотой. Объем работы, необходимый в этом пункте высоко сосредоточен и сконцентрирован исключительно на завершении тестирования, и материалы должны быть документированы.
Иллюстрация 6.1: Фаза SEP V сетевой график.
Сетевой график также показывает повторяющийся процесс выполнения испытательных случаев и отчеты об ошибках. Испытательная группа выполняет испытательные случаи и документирует ошибки, найденные в процессе испытания. Отчеты об ошибках рассматриваются разработчиками. Группа развития тогда пытается исправить ошибки и повторно предоставляет закодированные модули для перетеста. Этот повторяющийся процесс продолжается, пока все модули не прошли все соответствующие испытательные случаи. Это еще не гарантирует, что программа без ошибок.Испытание в этой фазе гарантирует, что все испытательные случаи выполнены и работают как предполагалось. Ошибки, найденные в другом месте в системе зарегистрированы и им присвоен определенный статус. Эти ошибки могут требовать новых испытательных случаев, дополнительной работы развития, и так далее. Главный пункт здесь - то, что они зарегистрированы и обращены прежде, чем закончено производство продукта
В большинстве организаций, качественные процессы ведут эту итеративную последовательность. Модули отклоняются в процессе испытаний. Команда развития получает уведомление, что-то не так. Она ищет детали отказа в прослеживании ошибкок или программном обеспечении управления конфигурацией. Вообще, ведущий разработчик будет работать с его или её командой, чтобы установить проблему и утвердить устанавливание с руководителем группы. Руководитель группы одобрит выпуск модуля назад в группу испытания для переиспытания и причвоит статус прошел либо провалил.
Теперь, назад к сетевому графику. Еще раз, первый шаг в этой фазе рассмотрение котрольного списка продукта для фазы испытания. Поскольку Вы можете видеть на иллюстрации 6.2, все квадраты для этой секции контрольного списка необходимы. Давайте смотреть на первый пункт в иллюстрации 6.2,план тестирования контрольного списка.
Обзор плана контрольного тестирования (TPC)
Этот шаг предполагает, что основная команда проводит тщательный обзор плана контрольного тестирования (TPC). После того как рассмотрение TPC было завершено, он должен быть рассмотрен руководителем проекта и спонсором проекта. После того как план был составлен и утвержден, команде тестирования следует начать оперативное исполнение всех тестируемых случаев, подготовленных в рамках каждого из соответствующих тестируемых планов, которые ранее были завершены на IV этапе в SEP
Это не редкость для менеджера проекта назначить кого-то независимого из тестирующей команды в качестве наблюдателя. Это лицо несет ответственность за тестирующую команду и обеспечение того, чтобы тестирования проводились и документировались профессионально и логически. Назначение наблюдателя не должно восприниматься командой негативно. Постоянное присутствие представителя основной команды только подчеркивает то значение, которое уделяется тестировнию. Когда негативность исходит от членов тестирующей команды, хорошей идеей будет сообщить им как важны их усилия для успеха проекта и объяснить им что наблюдатель является связующим звеном между ними и основой команды.
План контрольного тестирования
Предположения тестирующей команды
• Имеет лидера и / или команда установлена?
• Имеют обязанности продавца для установления и согласования тестирования?Предположения о значении контрольного плана тестирования
• Существуют ли системы, которые могут максимально подчеркнуть уровни совместимости с пользовательской средой?
• Будет ли существующая система подчеркивать уровни воздействия деятельности?
Предположения по поводу интеграция плана тестирования
• Все ли интерфейсы для различных программ определены и функционируют нормально?
•Ручной-автоматический интерфейсы работают нормально?
• Внешние интерфейсы с другими системами функционируют нормально?
• Является ли преобразование данных полным и точным?
• Является ли безопасность системы адекватной?Предположения о программном обеспечении плана тестирования (в случае необходимости):
• Является ли внутренняя логика правильной и точной?
• Все ли модули интерфейса в программе корректны?
• Внутренняя логика программы осуществляется в следующих областях:
о отчет об охвате тестирования
о Ветви/петли охвата тестирования
о стоимости выборки испытания
о границах стоимости охвата тестирования
о тестирование программного интерфейса
о тесты обработки файлов
о тестирование отчетов об ошибках
о подверженные ошибкам испытания
Пользовательское рассмотрение плана тестирования
• Может ли пользователь без посторонней помощи пройти через программу?
• Экраннный диалог, звук, и в целом все ли приемлемо для удобства пользователя?
• Является ли все данные необходимыми пользователю?Качество плана тестирования
• все ли функции данного продукта были протестированы?
• все ли проблемные области рассмотрены?
• все ли проблемы и жалобы пользователей были выявлены и рассмотрены?
• все ли вопросы, касающиеся тестирования были решены?План тестирования требует не только, чтобы команда тестирования проводила обзоры четырех рекомендованых планов тестирования, которые были созданы на предыдущем этапе работы, но просит и интроспективного взгляда на команду тестирования и качество плана. Этот обзор поможет команде сосредоточиться на больше, чем просто прохождение к завершению тестирования; он требует от членов группы взять на себя ответственность за проверку, ратификацию данного продукта.
Полный испытательный процесс нужно вести системой взглядов проверки качества. Основная команда должна работать тщательно с тестирующей командой, чтобы гарантировать, что каждый испытательный разработанный план должным образом выполнен и зарегистрирован. В конечном счете, SPMO и менеджер проекта выскажутся за испытательный процесс, потому что они несут ответственность перед проектным спонсором для успеха проекта.
Журналы испытаний и отчеты об инцидентах
Следующие два пункта в контрольном списке, журнал испытаний и отчеты об инцидентах, закончены тестирующей командой в течение выполнения тестов. Глава 5 описала то, что должен содержать журнал испытаний. Резюмируя, каждый вход должен содержать следующую информацию
• описание выполнения
• процедура окончания
• информация окружения
• неожиданные события
• отчет об инциденте
Иллюстрация 6.3 (после страницы) - рекомендованный шаблон чтобы создать отчет об инциденте. Сообщения об инциденте должны следовать стандарту IEEE 829-1998 руководящих принципов. Эти руководящие принципы призывают, чтобы следующие пункты присутствовали в испытательном сообщении:
• номер сообщения об инциденте
• Резюме
• вход
• Ожидаемые результаты
• Фактические результаты
• Аномалии
• Дата и время инцидента
• процедурные шаг на котором произошел инцидент
• условия окружения
Иллюстрация 6.3: отчет об Инциденте.
• Документация любых попыток повторить или заново создать проблему
• Названия испытателей и наблюдателей
• Последствия инцидента были на испытательном плане или спецификации
"Сегодня нет сомнений в том, что если программный продукт не тестировался, он не будет работать. Не менее верно и то, что после того, как программа была испытана, шансы, что она будет работать корректно при всех условиях, лишь незначительно улучшились. Мы должны думать об испытании как пропалывание сада: индивидуальные ошибки могут быть найдены с тестами, но более мощные методы необходимы для чащ. [10] "- Уоттс ХамфриИспытательные Области.
Превосходная ссылка на предмете испытания программного обеспечения[11] Джем Канер, содержит 12 областей, описывающих некоторые определенные испытания (или испытание областей), на которых посвятившая себя тестирующая команда должна всегда сосредотачивать ее время и усилие. Те 12 областей, рекомендованных Канером являются:
• ошибки пользовательского интерфейса
• ошибки обработки
• граничные ошибки
• ошибки вычисления
• начальные и более поздние утверждения
• ошибки контрольного потока
• ошибки в обработке или интерпретации данных
• условия прогонки
• условия загрузки
• ошибки аппаратных средств
• источник, версия, ID ошибок контроля
• ошибки тестирования
Профессиональные испытатели создают ряд испытательных случаев, определенных для нового приложения, которое покроет каждую из испытательных перечисленных областей. Конечно, уровень испытания обычно ограничивается временем и ресурсами. Много раз, некоторые из этих испытательных областей опущены ради основного функционального испытания.Хотя я не рекомендую опустить любую из этих областей, действительность корпоративной окружающей среды состоит в том, что крайние сроки чаще всего не ведут списки поставки продукта, и эти организации часто выбирают между более полным процессом испытания или более быстрой проектной поставкой.Назначая SPMO организацией и впоследствии осуществляя SEP, поскольку часть инициативы управления программы поможет предотвращать такие ошибки. Эффективное управление программы позволит организационным проектным командам начать устанавливать более реалистические, управляемые процессом списки. В долгосрочной перспективе, это изменение повлияет на практический результат организации.
Теперь, давайте начнем с обзора областей испытания, которые должны быть частью любого плана теста продукта. Помните, цель этой секции книги состоит в том, чтобы помочь Вам, как лидеру программы, знать обо всех испытательных проблемах и областях, из-за которых инициатива программы может потерпеть неудачу. То, что следует в следующих немногих секциях, не предназначено, чтобы быть интенсивным курсом в формальном испытании продукта.
Ошибки пользовательского интерфейса
Все, что пользователь может видеть или делать с подлежащем доставке можно классифицировать в пользовательской области интерфейса. Канер разбил эту область на несколько секций. Руководителю проекта и руководителю испытаний следует задать несколько ключевых вопросов, касающихся каждой из этих областей, чтобы тесты адекватно отвечали потребностям бизнеса.
Функциональные возможности
Система функционирует как реклама? Есть несколько вещей,которые раздражают пользователя больше, чем ожидание действий приложения и осознать, что ничего не делается. Еще хуже, интерфейс указывает, что приложение делает одну вещь, когда это фактически делает что - то еще.
Действительно ли это является надлежащим для задачи, которую это поддерживает? В этом случае необходимо подумать о старой пословице использования молотка, чтобы ввести иглу. Требуется четыре выбора меню, чтобы изменить цвет текста? Если Вы нажимаете кнопку «назад», действие стирает характер, линию, или параграф? Следите за массовым уничтожением.
что - то не так или пропущено? Что? Нет никакой особенности печати вашей Программы Поколения Сообщения? Ой! Вы можете только вообразить уровень раздражения, что оплошность вызвала бы. Пользователи очень неумолимы к таким ошибкам. Не считайте ничто само собой разумеющимся, рассматривая проекты и вообразите, что Вы сидите в месте работы пользователя, пробуя сделать вашу работу. Визуализация усилия по работе от перспективы пользователя поможет в ловли этих типов ошибок.
Пользователь должен сделать что - нибудь дополнительное, чтобы заставить это работать? Чтобы напечатать файл, вообразите необходимость выбирать принтер, выбирать тип бумаги, выбирать бумажный лоток, проверять коммуникации принтера, и так далее, вместо того, чтобы установить принтер по умолчанию для всех ваших приложений. Это действительно тот путь!
Это делает то, что ожидает пользователь? Сколько раз Вы слышали выражение пользователей, "я думал, что это сделает X, но когда я нажал эту клавишу, программа сделала Y," или подобные выражения? Хорошее приложение не должно удивить пользователя, делая кое-что неожиданное.
Функциональные возможности чрезмерны или излишни? Есть ли пункты меню в вашем приложении разработанные, чтобы заставить ваше имя появиться в тексте каждый раз, когда Вы видите это в сообщении? Программа позволяет пользователям напрасно тратить время, пробуя использовать особенности, которые не перечислены в вашей проектной документации? Группы развития печально известны тем, что оставляют свой след на приложении. Убедитесь, что эта ситуация быстро приведена под контролем, если Вы находите такие вещи, происходящие в вашей организацииКоммуникация
Информация отсутствует в системы? Все онлайн сисьемы помощи состоят из копий оглавлений от ячеичного пользовательского руководства, находящегося на вашем столе?
Онлайновая документация доступна, чтобы поддержать приложение? Хуже чем неполная помощь, не иметь никакой помощи вообще для программного обеспечения, это может действительно ухудшить пользователю настроение! Первая вещь, которую большинство этих пользователей делает, - берут телефон и обременяют вас большим количеством работы.
Продукт имеет какие-нибудь недокументированные особенности? Нажим последовательности клавиш Ctrl-Alt-Left на вашем приложении вызывает показ нескольких мультипликационных медведей, одетых как линия горцов, танцующая вне их лачуги? Или это показывает кое-что еще более смешное? Еще худший сценарий, чтобы счесть - кое-что как разработчик, добавляющий некоторые специальные особенности к программе, которые могли действительно приносить пользу, но не вносящие те особенности, пока требование не представлено. Где - логика в этом?
Программа представляет неправильную, вводящую в заблуждение, или запутывающую информацию? Хорошим примером здесь был бы пункт меню, указывающий использование последовательности комбинации горячих клавиш. То, когда пользователь нажимает последовательность комбинации горячих клавиш, пункт меню немедленно был бы активизирован.
Действительно ли документация помощи адекватна? Известный компьютерный изготовитель однажды имел обыкновение хвастать о его документации продукта, поставляемой в терминах линейных футов бумажных стеков. Вы можете себе представить, как сделать кое-что, анализируя четыре линейных фута бумаги? Или еще хуже, как при наличии четырех линейных футов документации доступной онлайн, без гиперссылок, или перекрестных ссылок?
Есть ли ошибки произношения или типографские ошибки в документации онлайн? Это имеет смысл для Вас? Это было бы невообразимо, найти такие явные ошибки в документации онлайн, не так ли?
Существуют ли ошибки в дисплее программы? Когда наведен курсор мыши на командную кнопку, программа блокируется или делает что-либо неожиданное? Текст наводняет область показа? Цвета, оригинальные? Все эти вопросы могут действительно подорвать удовлетворенность пользователя продуктом.
Расположение показа правильно? Это соответствует тому, что предусмотрели проект и документы? В противном случае, почему это было бы приемлемым для пользователя? Эта ситуация предотвратима. Обзоры проекта позволяют пользователю смотреть на макеты показов и одобрять или не одобрять прежде, чем разбивки закодируются.
Какие-нибудь области программы считаются бесполезным? Рассмотрите сценарии, типа наличия выбора для того, чтобы направить продукцию принтера на планшетный плоттер и впоследствии понимая, что ваша компания даже не имеет плоттера! Решение ситуации здесь не состоит в том, чтобы выйти и купить плоттер!
Меню организованы логически? Они должны быть организованы по стандартизированным рекомендациям. Они были развиты в вакууме? Пользователи предусматривали организацию меню, которая бросает вызов логике? Разработчики пробовали осуществить симпатичные меню для чего - то другого?
Меню имеют адекватную формулировку, орфографию и т.д.? Примером здесь был бы Файл | выбор меню Печати, ссылаемый как Файл | прямое попадание на принтер/факс или некоторую другую формулировку.
Если отсутствует команды добавить? Что? Вы уверены, что Вы действительно хотите спасти вашу работу? После расходования двух часов, воздействуя на эту рукопись? Здравомыслие в течение обзоров проекта предотвращают бедствия, типа этого (это случалось прежде, действительно!).
Является ли программа слишком жесткой? Программа не должна заставить пользователя чувствовать, что это - "мой путь или шоссе", пробуя сделать кое-что. Это ситуации, которые происходят в результате плохого проекта и должны быть исправлены, как только они обнаружены.
Может ли пользователь адаптировать интерфейс? Еще не нравится оригинальный цвет? Хорошо? Только гарантируйте, что пользователь также не сталкивается кое с чем как "нажмите F6 и перезагрузка", чтобы изменить цвета, когда он или она пробует настроить интерфейс. Иногда, программисты думают очень немного о том, что пользователь испытает, воздействуя на систему. Я нашел, что многие из этих проблем решаются, когда программисты работают бок о бок с пользователями, чтобы получить новую перспективу.Командная структура
Существует ли программа поддержки последовательной, понятной командной структуры? Несоответствия в приложении приведет к разочарованию пользователей. Это может создать неблагоприятные впечатление от всего проекта усилий. Не забудьте проверить использование общих командных структур всех сегментов приложения и обеспечить, чтобы эти структуры придерживаться некоторых известных стандартов.
Использование структуры команд сохраняет или тратит время? Если требуется 11 нажатий клавиши для выполнения команды по меню, по всей вероятности, будет иметь большое недовольство среди пользователей этого продукта. Старый приложения зачастую состоят из вложенных окон. Перехода от одной части программы к другой означает переход от экрана к экрану, пока Вы не добрались туда, где Вы хотели быть; однако, если вам из первого экрана необходима опция 1, опция 4 на втором экране, и опция7 на третьем экране, в меню на первом экране вам необходимо набрать что-то вроде этого: = 1,4,7. Система немедленно пошла бы в результат выбора 7 на третьем экране. Если это не кажется настолько горячим к Вам, помните, что разделяя время компьютер часто производил настоящую задержку, собирающуюся от экрана к экране. Это стало фактическим методом проведения структур меню универсальной ЭВМ, потому что это экономило время.
Действительно ли меню адекватны для навигации полной системы, или есть тупиковые дорожки от меню? Структура меню имеет фривольные команды вложенные в пределах этого? Каждый пункт меню должен соответствовать предназначению в программе. Аналогично, каждое предназначение должно позволить Вам возвращаться к меню, которое принесло Вас к тому пункту.
Клавиатура используется логически? На первый взгляд, это может походить на глупый вопрос; однако, сочтите последовательность SHIFT | ALT | $ используемой, чтобы выполнить сообщение. Хорошо, таким образом сообщение – вход. Получите это? Вход? $? Теперь, Вы знаете, где голова программиста была в тот момент, когда эта система была изобретена. Эти типы проблем проекта могут быть пойманы на пользовательских сессиях обзора и исследованиях удобства и простоты использования. Не оставляйте это на программиста, чтобы решить, как или что должен сделать пользователь, чтобы выполнить выбор. Возвратитесь к пользователям, чтобы узнать то, что они хотят. Пробуйте не позволить этим вещая не проскользнуть через испытательный процесс. Насмешка будет направлена на проектную команду из-за таких простых проблем как эта.Отсутствие Команды
Пользователь становится запертым, когда он или она не может переходить от одной части программы к другой? Не существует ничего столь ужасного или ущербного для авторитета группы как пользователь, который ненавидит ваше пнриложение, поскольку оно отправляет его в мертвые зоны. Всегда гарантируйте двунаправленное пересечение в структурах меню.
Есть ли средства, встроеные в систему, чтобы предотвратить бедствие, и система поддерживает ошибочную обработку пользователем? Пример этого был бы кое-чем как печать ежеквартального коммерческого сообщения и внезапно замечающий, что принтер исчерпал бумагу. Очевидно, Вы надеялись бы, что программа заметит также, но увы, все 200 страниц вашего ежеквартального коммерческого сообщения должны наматываться прежде, чем программа восстанавливает контроль. Не было никакого средства в вашем приложении, чтобы остановить текущую работу печати потому что потому что это не была часть документа основных требований. Вообразите, ситуации когда это мог быть ваш конечный пользователь, который пробует вывести сообщение к Коммерческому VP, чтобы скатать числа для четверти. Ситуации как это просят обзоров проекта ловить проблему прежде, чем это случается. Устранение этого во время развития тривиальна, но уберегает от повреждения. Доверие будет разрушено.
Вообразите ситуацию, где каждый раз Вы желаете прочитать, что ежеквартальное коммерческое сообщение, на-экране Вы должны изменить фон и цвета переднего плана, чтобы сделать текст удобочитаемым. Программисты не имели никакого требования для того, чтобы установить текст и второстепенные цвета и послали продукцию стандартному показу; однако, на вашем специфическом мониторе цвета кажутся напуганными. Вы можете выкарабкаться, конечно, но Вы находите это намного лучше и легче на глазах, если Вы можете изменить цвета и сделать текст более удобочитаемым. Теперь, вообразите ситуацию, где нет никаких вариантов в заявлении, чтобы позволить Вам изменять напуганные цвета! Дополнительное повреждение доверия вашей команды.
Пользователь может уйти, когда он или она решает, что это необходимо? Это - определенно неделя ада. Вы нажимаете клавишу F3, чтобы возвратиться к предыдущему меню; однако, потому что Вы не могли изменить цвета на вашем дисплее, Вы не замечали текст переднего плана, который был только одним оттенком цвета, отличного от второстепенного текста - Вы знаете, тот текст, который сказал нажать Esc, чтобы выйти. Вы нажимаете F3 снова и снова. После нескольких минут и Вы и терминал, на который Вы воздействовали, стали невключенными!Гибкость программы
Пользователь может настроить программу, чтобы удовлетворить его или её потребности? Думайте о цветах снова. Эта тема проходит между цветов. Формат сообщения изменяется или настройка продукции, выборы меню, которые наиболее часто используются, будучи более доступными, выбор различного принтера, и так далее нужно все рассмотреть перед выходом из обзора проекта.
Пользователи могут чувствовать, как будто они находятся в контроле сессии? Если программа устроена таким образом, что пользователи чувствовуют себя, как будто они находятся на Марше смерти, они пробуют использовать систему, спецификации проекта вероятно были не в состоянии достигнуть желательных целей удобства и простоты использования. Пользователи являются самыми счастливыми, когда они чувствуют, как будто они - владельцы их вселенной. Гарантируйте, что Вы предпринимаете шаги, чтобы позволить им управлять их областью, предоставляя им способность сделать точно то, в чем они нуждаются и точно то,что они хотят увеличить производительность. Ищите способы изменить к лучшему существующие окружающие среды или использовать новые, стандартизированные, испытанные интерфейсы, которые принесут желаемые результаты.
Является ли система враждебной для опытных пользователей? Лучшим примером является ситуация, с пользователем, который начинает изучать новое приложение. Дизайн группа была достаточно тщательно продумывает включение всплывающей помощи для каждого варианта, кнопки. Это было бы отлично первые разы пользования приложением, но, после того как вы видели всплывающую помощь 400 раз на этой неделе после нажатия на кнопку печати, готов поспорить, что Вам не захочеться видеть ее - по крайней мере сегодня. Разве я не прав?
Существуют ли повторяющиеся действия? Вам необходимо выбрать пункт меню в главном меню вашей приложения. Диалоговое окно всплывает. Нажмите F1 для продолжения. Другой диалоговое окно всплывает снова. Нажмите клавишу F1, чтобы продолжить снова. До бесконечности. Уже с этим сталкивались!
Существуют ограничения, налагаемые на пользователей, которые являются ненужными или глупыми? Выбран вариант распечатать отчет. Принтер выкладывает страницу один. Диалоговое окно всплывает. Нажмите F1, чтобы продолжить. Принтер выкладывает страницу два. Другое диалоговое окно всплывает снова. Нажмите F1, чтобы продолжить снова. До бесконечности.Вы появляется идея. Если нет, то примерно через 25 страниц, она появится.Работа
Программа слишком медленна, действительно ли отклик вял, или программа срывается и умирает медленной смертью, когда загрузка помещена в систему? Деградация работы может быть вызвана разнообразием факторов. Это - ответственность команды проекта по установлению стандартов работы в документах проекта и ответственность испытательной команды по их проверке. На новых системах, обычно это испытание происходит, и система часто первоначально работает с летающими цветами.
Имеется ли применение процесса оптимизации функций, таких как тип - вперед или макросы? У большинства пользователей мысль об экономии времни вызывает слюноотделение, т.к она может сделать их работу легче. Проведение предварительного и последующих исследований обеспечат Вас счастливыми пользователями вашей системы.
Является ли система перегружена графикой или функциями, из-за которых страдает быстродействие? Золотое правило здесь состоит в том, чтобы всегда осознавать время, которое должен тратить пользователь для выполнения любой задачи в системе. Воспрепятствование продвижению, заливка мультимедиа, которое является лишним в выполнении задач, почти всегда рассматривается отрицательно.. Не променивайте завершение основной программы на симпатичную графику или полезную анимацию. Прежде всего, большинство пользователей легко согласиться, что получение желаемых результатов стоит на первомместе в их списке. Во вторых, если они потеряют время, позволяя эстетике препятствовать решению их задач, то большинство скажет Вам об ненужности эстетики. Лучший курс действий - предоставить пользователям механизм выбора способов приоритезации своего время.Тогда, если выполнение будет немного дольше, потому что они любят смотреть на танцующую собаку, то они не будут жаловаться на это к Вам.Результат
Могут ли все желаемые данные быть результатом, а результаты могут быть направлены куда пользователь хочет. Когда доклад генерируется, вы обнаружите, что коммерческие представительные названия были исключены из доклада. Много хорошего, что доклад будет делать! Возьмем немного дальше и предположим, что имена присутствовали в докладе. Вы столь рады результатам, что Вы хотите распечатать это в цвете и включить это как часть вашего выступления на еженедельной встрече с вице-президентом. Что? Нет опций для печати на цветном принтере? Дурная программа не может сделать то, что я хочу! Полезная Подсказка: Помните, этот глупый пример в течение обзора проекта!
Является ли формат вывода стандартным. Есть много стандартов на выбор: XML, RTF, SGML, HTML, и так далее. Не пытайтесь создать еще один без уверенности, что один из этих сделает эту работу за вас.
Является ли результат соответствующий для аудитории? Используйте различные форматы отчетов для различных уровней организации. В идеале, найдите, что тип "один размер соответствует всем" решения, подходящего для всей аудитории, если Вы абсолютно уверены, что ваш главный администратор будет не против видеть ваши ведомственные изображения, вложенные в его или её сверхканальные доклады. Он или она, вероятно, не хотели бы видеть такого рода материалов в докладах!
Результат может быть изменен или контролируется? Во многих случаях, пользователям нужно лишь несколько столбцов данных из доклада. Если это вообще возможно, разработать приложения, так чтобы пользователи могли выбрать, какие столбцы приводить в докладе и сохранить эти функции.Как вы можете видеть, существует достаточно много факторов, которые следует учитывать при начале тестирования приложения. В идеале, эти соображения были впервые сделаны в процессе проектирования и тестирующая группа не обнаруживает любой из этих примеров в ходе первоначального испытания. В этом случае, будьте уверены, ваши средства взлетят.
До сих пор одним из самых важных моментов, который я пытался донести в этой главе, чтобы Вы и Ваши сотрудникам тратили достаточно времени на процесс проектирования, чтобы избежать подобных ошибок. Мы только обсудили ошибки пользовательского интерфейса на этом этапе. Теперь, когда вы знаете, что искать в области интерфейса, давайте взглянем на некоторые другие типы ошибок и посмотрим, что еще мы можем сделать для спасения нашего бюджета.
© 2008, ДонНТУ, Гуров А.В.