Тестирование практичности для пользователя

Безопасность ИТ — вопрос не только технический. Еще до тематических кампаний SAP под лозунгом «Passwords are like underwear» («Пароли как нижнее белье», http://www.lanline.de/kn30475366) краеугольным камнем — и, одновременно, слабым звеном — безопасности ИТ называли человека (правда, и тогда, и теперь человеческий фактор зачастую низводится до фактора риска; см. http://www.lanline.de/kn.31393726 ).

В то время как сами технологии –при условии, что их применяет квалифицированный пользователь —обеспечивают все более надежную защиту от вредоносного программного обеспечения (malware), «шпионских» программ (spyware) и троянов, неопытные пользователи остаются наедине с управлением все более сложными и далекими от повседневных нужд программами. Сообщения об ошибках кажутся цифровыми шифрами, а последствия принятых решений непрозрачны.

НЕ ДУМАТЬ

«Don’t make me think!» («Не заставляй меня думать!») – это название книги Стива Кругса, посвященной удобству использования дизайна Web, одновременно стало лозунгом практичности. Человеческая способность к восприятию и внимание не концентрируются на контекстах, связанных с безопасностью, если только обеспечение защиты не является самоцелью работы за компьютером, что маловероятно за пределами отдела ИТ.

Тем не менее, безопасность данных — непременное условие эффективной экономики предприятия. На рынке представлено множество продуктов для отражения атак на внутрикорпоративную информацию (сведения о клиентах, внутренние отчеты, коммуникационные данные и т.д.), осуществляемых как из пределов корпоративной сети, так и извне. Все они обещают свести угрозу безопасности к минимуму: брандмауэр, авторизация в Intranet, защищенные соединения, а также методы и приложения для шифрования чувствительных данных технически оптимизированы для устранения риска. Однако для конечных пользователей они остаются «вещью в себе».

ТЕСТИРОВАНИЕ В ОГРАНИЧЕННЫХ РАМКАХ

В качестве меры дружественности продуктов к пользователю утвердилось такое понятие, как Usability (дословно «практичность», «пригодность к использованию»). Практичность отличается множеством аспектов. Так, чашка с тремя ручками не особенно удобна в использовании, а вот банкомат с большими кнопками и антибликовым экраном — вполне. Поначалу термин Usability обсуждался лишь в отношении Internet (Web Usabilty), однако вопрос об удобстве использования возник и в области разработки программного обеспечения. Продукт для обеспечения безопасности со множеством опций может быть очень качественным с точки зрения функциональности и очень надежным, однако без соответствующих возможностей его использования техническая функциональность становится бесполезной.

Этот аспект выбираемого продукта особенно сложно оценить малым предприятиям. В то время как крупные компании обладают необходимыми финансовыми средствами, чтобы привлечь внешних специалистов для оценки практичности программы, большинство компаний не располагает такой возможностью, хотя для них защита данных не менее важна. Единственное, что остается, — доверять сотрудникам и разработчикам интерфейса.

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

Как правило, производители программного обеспечения предусматривают в договоре купли-продажи определенный срок возврата товара. Эту возможность следует использовать для тестирования программного обеспечения на предмет эргономичности в корпоративном контексте.

О ПОЛЬЗЕ СОБСТВЕННЫХ ТЕСТОВ

Практичность раскрывается лишь при активном применении продукта и в значительной степени зависит от условий, характерных для конкретной компании. При ее проверке самостоятельные испытания дают такие же квалифицированные результаты, как и внешние тесты. Подобное тестирование может включать следующие этапы: выявление потенциальных проблем при установке продукта, количественный и качественный учет возможных затруднений при повседневной эксплуатации в рабочей среде посредством постановки актуальных задач, а также отзывы пользователей в отношении удобства, прозрачности и имеющихся функций подсказки. Такой подход максимально прост, но эффективен. Казалось бы, банальная мысль – предложить опробовать продукт нескольким сотрудникам предприятия, которым в дальнейшем, возможно, придется его использовать в своей деятельности — приводит к вполне обоснованным и надежным результатам, если придерживаться нескольких научно проверенных приемов и методик.

Даже небольшое число участников тестирования способно предоставить адекватные результаты. По словам одного из ведущих специалистов в сфере Usability Якоба Нильсена, для выявления 80% недостатков интерфейса достаточно всего пяти человек. Лучше всего использовать максимально репрезентативную выборку сотрудников.

В процессе испытания необходимо определить и имитировать обычные рабочие действия, которые каждому придется предпринимать в повседневной деятельности. Важно подчеркнуть, что речь идет исключительно об оценке продукта, а не о навыках обращения с программами обеспечения безопасности. Такое предостережение должно быть обязательным условием, поскольку малейшее подозрение в том, что будет оцениваться и поведение пользователя, неизбежно скажется на его действиях, и тестирование потеряет всякий смысл. Экспериментальная модель предусматривает защиту данных и гарантию их анонимноности, а также исключительно статистическую обработку полученных результатов. Кроме того, участников следует ознакомить с общими преимуществами дружественной пользователю программы и с важностью безопасности ИТ в целом. При отсутствии этого этапа результаты также могут лишиться своей содержательности.

Разумеется, потребуется присутствие руководителя эксперимента. С согласия тестируемых возможны видеозапись или протоколирование всех действий, производимых на компьютере.

ОЗВУЧИВАНИЕ СВОИХ ДЕЙСТВИЙ

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

Мотивация в качестве одного из аспектов практичности также постепенно выдвигается на перед-ний план. Дональд Норман, тесно сотрудничающий с Нильсоном, даже констатирует прямую взаимосвязь между «Красотой, добротой и практичностью» («Beauty, Goodness and Usability») — именно так называется одна из его работ. Особенно раздражающее впечатление производят специфические помехи при выполнении непосредственной работы: к примеру, постоянное появление всплывающих окон системы безопасности во время установления соединения с Internet может так надоесть пользователю, что он предпочтет обходиться без этой дополнительной защиты.

Если на предприятии есть свой специалист по ИТ или сотрудник, отвечающий за электронную обработку данных, то и ему надо присутствовать при тестировании для осуществления мониторинга. В ином случае эту роль должен взять на себя тот, кто обладает глубокими базовыми знаниями и информацией о техническом оснащении предприятия.

На втором этапе можно выделить наиболее частые проблемы и разработать сценарии для тех случаев, которые предполагают возникновение этих проблем.

В тестирование следует вовлекать, прежде всего, менее опытных (в техническом отношении) сотрудников, которые еще не работали с новым продуктом. Таким образом можно определить, насколько первый опыт общения с программой, полученный в результате курса обучения, облегчает работу с ней.

ДОКУМЕНТАЦИЯ В КАЧЕСТВЕ РЕЗУЛЬТАТА

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

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

МЕРЫ ПО ФОРМИРОВАНИЮ ДОВЕРИЯ

Однако самые большие проблемы, возникающие при внутреннем тестировании на практичность, не так просто устранить. В тестовой ситуации сотрудники будут вести себя не так, как в повседневных условиях. Например, они могут скрывать свои негативные выводы, чтобы не произвести плохого впечатления на начальника. Или у них могут быть конфликты с отделом электронной обработки данных на предприятии. Возможный выход — привлечение к руководству тестированием одного или нескольких внешних экспертов, разбирающихся в проблемных ситуациях и не вовлеченных во внутрикорпоративную иерархию, причем об этом факте сообщается тестируемым. Альтернативный вариант — назначить руководителем тестирования лицо, находящееся с тестируемыми на одной должностной ступеньке.

Таким образом, тестирование практичности вполне осуществимо, причем с относительно небольшими финансовыми и временными затратами. Такие испытания результативны и внесут существенный вклад в безопасность ИТ. Иными словами, для оценки практичности совершенно не обязательны такие ресурсы, как внешние экспертные лаборатории, помещения с рефлекторными зеркалами или дипломированные нейропсихологи.

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

Таким образом, девиз «Не заставляй меня думать!» касается только работы с аппаратным и программным обеспечением, но никак не отношения к вопросам безопасности в целом.