Лабораторна робота №5 Тестування інтерфейсу користувача

Теоретичні відомості

Тестуванням є будь-який експеримент, спрямований на визначення якості інтерфейсу або ж пошук конкретних проблем в ньому. Користь тестування багатогранна. Тестування дозволяє:

• зрозуміти, наскільки погано або добре працює інтерфейс, що може або спонукати поліпшити його, або, якщо він вже достатньо хороший, заспокоїтися; у будь-якому випадку досягається користь;

• порівняти якість старого і нового інтерфейсів і тим самим дати обґрунтування змінам або впровадженню;

• знайти і пізнати проблематичні фрагменти інтерфейсу, а при достатньому об'ємі вибірки також і оцінити їх частотність.

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

1. Деяке спрощення поняття “зручність”.

2. Відмова від збору кількісних даних.

3. Зниження вартості устаткування і зменшення оплати часу респондентів.

Третій підхід полягає у використанні тільки мобільних лабораторій. Головними показниками ефективності є швидкість роботи користувача, швидкість навчання і кількість людських помилок. Це потрібні показники, які впливають на дизайн. Що приємно, вимірювати їх не особливо проблематично. З показниками КПД все дещо складніше. До цієї групи входять:

• успішність, тобто співвідношення правильно виконаних тестових завдань до невиконаних або виконаних зовсім неправильно.

• потужність, тобто співвідношення завдань з діяльності користувача до завдань, для вирішення яких даний продукт призначений.

• навантаження на користувача (як ментальне навантаження, так і, наприклад, кількість дій користувача на тестове завдання).

Проблеми тут дві. Потужність - взагалі не вимірюваний показник (велика або менша потужність продукту є цілком і повністю питання дизайну). Навантаження ж на користувача або важко вимірюється, або неактуальне оскільки все одно виявляється в показниках ефективності - при інтенсивному навантаженні знижується швидкість роботи. Таким чином, від всіх показників КПД на практиці залишається тільки успішність. У цьому спрощенні немає нічого крамольного. У реальному тестуванні все одно ніколи не збирається великий набір показників - як-не-як для кожної конкретної системи важливі тільки деякі з них. Проте принциповий наслідок даного спрощення формулювання - значне спрощення методології тестування - не може бути досягнуто ніяким іншим способом.. Таким чином, тут і далі тестування розуміється як міра в якій продукт може бути використаний певними користувачами при певному контексті використання для досягнення певної мети з належною успішністю, ефективністю і задоволеністю. Друга можливість понизити трудомісткість тестування - відмова від збору більшої частини кількісних даних. Робиться це з двох причин:

1. Кожен конкретний тест може бути направлений або на отримання кількісних даних, або якісних даних. Якісні дані, як правило, більш затребувані при дизайні, тому тест краще планувати саме з розрахунку на них.

2. Кількісні дані все одно виходять ненадійними. їх можна зміряти надійно, але справа це надзвичайно трудомістка.

Кількість вимірюваних показників в конкретному тесті може бути досить велика, але всі вони, як правило, зводяться до набору з п'яти базових характеристик. Нижче вказано список цих характеристик з прикладами метрик, створених на їх основі.

1. Швидкість роботи користувача. Метрики: тривалість виконання операції; час витрачений на виявлення помилок; час витрачений на виправлення помилок; кількість команд, що виконуються при виконанні операції (мається на увазі, що чим більше команд, тим довше на них йтиме часу); тривалість пошуку відомостей в документації; кількість команд, ефективніших, ніж використані користувачем; зниження продуктивності при тривалій роботі.

2. Помилки. Метрики: відсоток операцій, що викликали помилку; середнє число помилок на операцію у досвідчених користувачів (саме у досвідчених, оскільки у недосвідчених можуть діяти і чинники з групи швидкості навчання); кількість помилок, не виявлених і не виправлених користувачами.

3. Навчання навикам роботи з системою. Метрики: кількість і частота звернень до довідкової системи; тривалість періоду між початком використання системи і точкою в якій швидкість праці (кількість помилок користувачів) перестає рости; різниця в кількості помилок (швидкості роботи) у користувачів з досвідом використання системи і без такого досвіду.

4. Суб'єктивна задоволеність користувача. Вимірювання цієї характеристики зв'язане з певними труднощами, заслуговуючими окремого розгляду. Метрики цієї властивості див. нижче).

5. Збереження навиків роботи з системою. Метрики: різниця в швидкості роботи (кількості помилок користувача після години роботи з системою і у того ж користувача на початку використання системи після тривалої перерви.

Як видно, вимірювання якості інтерфейсу може бути досить складним. Так, наприклад, тест збереження навиків може зайняти більше місяця. Але це тільки тести на другу і третю складові юзабіліті, а саме на ефективність і задоволеність. Крім них є ще і успішність, яка важливіша і яку виміряти набагато простіше, - потрібно всього лише підрахувати, який відсоток завдань користувач або виконує повністю неправильно, або не може виконати зовсім. На відміну від інших характеристик, задоволеність знаходиться не в реальному світі, а в голові у користувача. Як наслідок, її неможливо «помацати», а значить, і об'єктивно виміряти. Але, принаймні, її можна визначити опосередковано.

Існує два можливі напрями дій. По-перше, респондента можна запитати, наскільки інтерфейс здається йому задовільним. По-друге, по поведінці респондента можна визначити, подобається чи не подобається йому інтерфейс в будь-який конкретний момент часу; підрахувавши кількість і знак проявлених реакцій, можна оцінити задоволеність. Зрозуміло, ці оцінки відносні; їх цінність виявляється тільки порівняно з новим інтерфейсом або порівняно з конкурентами.

Нижче приведені деякі методи вимірювання задоволеності.

Анкетування

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

Анкета по словах

Вперше цю анкету запропонували дослідники з Microsoft Usability Laboratory як спосіб дуже швидко, нехай і свідомо ненадійно, оцінити задоволеність. Анкета дуже проста. Респонденту пред'являється лист паперу з набором випадково підібраних прикметників, одна половина яких швидше позитивна, друга - негативна. Респонденту пропонується підкреслити слова, які, на його думку, застосовні до продукту (схожість анкети з анкетами, що використовуються в методиці семантичного диференціала, не суттєва - це абсолютно різні методи). Після того, як анкета заповнена, підраховується різниця між числом негативних і позитивних термінів.

Наступний набір прикметників:

Застарілий - Ефективний - Незручний - Засмічений - Тьмяний - Яскравий - Чистий - Прямий - Ясний - Непослідовний - Некерований - Привабливий - Стандартний - Керований - Хороший - Інтуїтивний - Веселий - Любительський - Неефективний - Небезпечний - Нудний - Радісний - Безпечний - Жорсткий - Дратівливий - Трикутний - Комфортабельний - Холодний - Розумний - Даремний - Халтура - Теплий - Світлий - Послідовний - Загадковий - Якісний - Цікавий - Ненадійний - Гнучкий - Красивий - Непривабливий - Корисний - Дурний - Заплутаний - Зручний - Зрозумілий - Непередбачуваний - Важкий - Сучасний - Легкий - Дружний - Нестандартний - Поганий - Надійний - Складний - Простий - Темний - Професійний - Повільний - Круглий - Сумний - Недружний - Передбачений - Незрозумілий - Швидкий - Головоломний.

Формальна анкета

На відміну від анкети по словах, ця анкета не може бути використана без адаптації під конкретний проект. Частина її питань деколи неактуальна, деколи потребує зміни формулювання. У будь-якому випадку, для респондентів-жінок потрібно міняти, статеву приналежність формулювань анкети. Анкета складається з декількох питань, для кожного з яких респондент може вибрати один з п'яти варіантів відповіді.

Запитання анкети:

Під час виконання завдань я рідко

помилявся. Ні Так

Система здатна робити все, що мені

потрібно і навіть більше. Ні Так

Система працює достатньо швидко. Ні Так

Мені подобається зовнішній вигляд

Інтерфейсу. Ні Так

Я відчуваю, що якщо я краще вивчу

систему, я зможу робити в ній речі, про Ні Так

які зараз навіть не підозрюю.

Систему можна легко добудувати під

мої потреби. Ні Так

Почати роботу буде легко; я не зіткнусь

з істотними труднощами. Ні Так

Кожного разу, коли я помилявся,я з легкістю

помічав і виправляв свою помилку. Ні Так

Я задоволений своєю швидкістю роботи. Ні Так

Під час виконання завдань я відчував себе

цілком впевнено. Ні Так

У будь-який момент часу я розумів, що я

повинен зробити далі. Ні Так

Результати потрібно підраховувати по наступному алгоритму: центральне значення дає нуль балів, крайні значення дають або -2 бали (лівий варіант відповіді), або +2 бали (правий варіант), проміжні значення або -1 або +1 бал відповідно. Сума балів є порівнюваним значенням.

Спостереження за емоційними реакціями

Крім анкетування, можна підраховувати емоційні реакції респондента. Наприклад, респондент посміхнувся - ставимо плюс, лайнув або поморщився - ставимо мінус. Кількість і знак реакцій і складає шукану величину показника.

Тепер, коли - принципові питання в цілому розібрані, можна переходити і до практики. Почати варто з переліку того, що потрібно зібрати в одному місці для проведення тестування (нижче ці пункти будуть описані детальніше). Отже, що нам потрібне:

• респонденти;

• метод тестування;

• тестові сценарії;

• робоче місце для тесту і відлагоджений метод фіксації матеріалу;

• протестований тест.

Загальні вимоги до респондентів:

Перший пункт - чи потрібний респондентам досвід роботи з системою. Загальне правило: якщо оптимізується інтерфейс існуючої системи, половина респондентів повинна мати досвід роботи (на них можна визначити проблеми перенавчання при впровадженні), а половина не має досвіду (на них визначається швидкість навчання). Якщо існують конкуруючі системи, кращою є інша пропорція: третина з досвідом роботи з попередньою версією, інша третина - з досвідом використання конкуруючих систем, третина, що залишилася, - без досвіду роботи з системою.

Другий пункт - рівень комп'ютерної грамотності. При інших рівних умовах переважним вибором є реальний, тобто співпадаючий з досвідом цільової аудиторії, рівень у трьох чвертей респондентів і низький рівень - у чверті, що залишилася (на ній можна визначити більшу кількість проблем).

Рівень комп'ютерної грамотності зручно визначати за наступною шкалою:

1. Високий. Респондент має комп'ютер на роботі і удома, велика частина трудової діяльності виконується на комп'ютері, респондент самостійно використовує комп'ютер як засіб саморозвитку, активно користується сервісами в Інтернеті (наприклад, регулярно купує товари і послуги в онлайнових магазинах).

2. Вище середнього. Респондент має комп'ютер на роботі і удома, велика частина трудової діяльності виконується на комп'ютері, але респондент не використовує комп'ютер для вирішення завдань, що виходять за межі його основної діяльності (працює на комп'ютері «від дзвінка до дзвінка» і не більше).

3. Середній. Робота з комп'ютером є частиною звичайної (трудової або особистої) діяльності протягом двох років або більше.

4. Низький. Або на роботі, або удома є комп'ютер, але досвід роботи з комп'ютером не перевищує двох років і комп'ютер не є значущим інструментом в роботі.

5. Дуже низький. Досвід використання комп'ютера спорадичний, по тривалості не перевищує трьох років. Комп'ютер не використовується ні на роботі, ні удома.

На третьому місці знаходиться вік. Оптимальна пропорція: три чверті респондентів має вік цільової аудиторії системи, чверть, що залишилася, старша (на ній можна визначити більшу кількість проблем).

Менший вплив на результати має стать респондентів - але це не означає, що підбирати респондентів коректної статі необов'язково. Варто збільшити кількість жінок серед респондентів в порівнянні з пропорцією в цільовій аудиторії, оскільки на жінках легко визначати проблеми при впровадженні (жінки, в цілому, повільніше навчаються, але, навчившись, краще працюють).

Остання значуща характеристика - рівень емоційної відвертості респондентів. Чим більш скутий респондент, тим менше він здатний сказати вам цінного. Навіть визначивши наявність проблеми, ви не зможете добитися від нього ніякої інформації про те, що цю проблему викликало. Існує прекрасний спосіб вирішити проблему недостатньої емоційної відвертості - варто мати базу респондентів і використовувати їх повторно. Респондент, що вже знає на досвіді, що в юзабіліті тестуванні немає нічого страшного, значно більш охоче йде на контакт і взагалі балакучіший.

Методи тестування

Основних методів тестування всього три: пасивне спостереження за виконанням тестових завдань, потік свідомості і активне втручання. Перший призначений для збору кількісних даних, останній - якісних:

• Пасивне спостереження за виконанням тестових завдань. Суть методу дуже проста: респондент виконує тестові завдання, його дії аналізуються (під час тесту або після, по протоколах), що дозволяє як знайти проблематичні фрагменти, так і заміряти ергономічні характеристики інтерфейсу.

• Потік свідомості (think aloud). Відповідає перевірці за допомогою пасивного спостереження, але респондента при цьому просять також усно коментувати свої дії. Потім коментарі аналізуються. Метод досить нестабільний, але деколи дає цікаві результати (дуже залежить від балакучості респондента). Великий мінус потоку свідомості - вимірювання ергономічних характеристик інтерфейсу вельми сумнівні.

• Активне втручання. У цьому методі юзабіліті фахівець не чекає милостей від природи в особі респондента, а прагне узяти їх сам. Після кожної дії респондента експериментатор випитує його, чому респондент діє саме так; на кожному екрані експериментатор питає, як саме респондент розуміє призначення і функції цього екрану. Цей метод ближчий до інтерв'ю, що фокусує, чим до власне тестування - наприклад, метод можна використовувати навіть без тестових завдань, лише б був інтерфейс для обговорення. Зрозуміло, що при активному втручанні ніякі вимірювання просто неможливі, та зате об'єм отримуваних якісних даних найбільш великий.

Тестові сценарії

Тестовий сценарій - це тестований аспект системи.

Сценарії складаються з призначеного для користувача завдання і супутніх йому:

• значущих ергономічних метрик;

• тестових завдань респондентам (завдань може бути декілька);

• ознак успішності виконання завдання.

При виборі завдань для тестування слід керуватися двома міркуваннями:

• Всі завдання повинні бути реальними, тобто визначеними з актуальної діяльності користувачів.

• Оскільки протестувати інтерфейс на всіх призначених для користувача завданнях можливо тільки в ідеалі, доводиться обмежувати себе і вибирати тільки важливі завдання. Важливими завданнями є, по-перше, частотні завдання, тобто які виконуються всіма користувачами і/або виконуються часто, по-друге, решта всіх завдань, які, як ви підозрюєте, виконуються в системі погано і, нарешті, завдання, неправильне виконання яких приводить до крупних проблем.

Тестові завдання

Тестове завдання - це те що отримує від вас респондент, завдання, що дозволяє провести респондента через фрагмент інтерфейсу системи і визначити характеристики цього фрагмента. Тестові завдання, крім того, що повинні відповідати призначеним для користувача завданням, повинні мати ще і наступні властивості:

• Однозначність. Завдання повинні бути сформульовані так, щоб виключити їх неправильне тлумачення респондентом. Якщо респондент зрозуміє завдання неправильно, вам, майже напевно, не вдасться по ходу тесту направити його на правильний шлях, не підказавши йому одночасно послідовності виконання завдання.

• Повнота. У тексті завдання повинна бути присутньою вся інформація, необхідна для виконання цього завдання.

• Стислість. Якщо ви вимірюєте швидкість виконання завдань, завдання повинні бути достатньо короткими, щоб тривалість читання завдань респондентами не впливала на тривалість виконання самих завдань (люди читають з різною швидкістю).

• Відсутність підказок. По тексту завдання не повинно бути зрозуміле, як це завдання потрібно виконувати. Наприклад, неприпустимо використовувати термінологію системи - замість кожного терміну потрібно розписувати його значення, інакше респонденти просто натиснуть кнопки з тими ж словами і ви не виявите жодних проблем.

• У завданні повинні бути присутніми точка початку виконання завдання, тобто повинні бути прописані те вікно або екран, на яких респондент повинен знаходитися на початку. Якщо такої інформації представлено не буде, респонденти неминуче переходитимуть до інших фрагментів інтерфейсу, а значить, завдання різними респондентами виконуватиметься по-різному, що робить безглуздими всі статистичні розрахунки. Фіксувати початкову точку завдання потрібно ще в кінці попереднього завдання. Якщо завдання починається з чистого листа, в кінці попереднього завдання повинно бути написано «поверніться на головний екран». Якщо завдання повинне починатися з місця, на якому закінчилося попереднє завдання, попереднє завдання повинно закінчуватися словами «закінчивши, не закривайте поточне вікно(залишайтесь на цьому екрані».

Крім цих загальних вимог потрібно враховувати ще і наступне:

• Можливо, що на одне призначене для користувача завдання потрібно буде написати декілька тестових завдань. Типовий випадок - завдання дуже велике, щоб його можна було вмістити в одне завдання. Крім того, якщо призначене для користувача завдання є частотним, вас не повинно особливо сильно цікавити, як воно виконується вперше - набагато цікаво дізнатися, як користувачі виконуватимуть його в другий, третій, четвертий (і так далі) рази. В цьому випадку в межах тесту на одному респонденті проганяти це завдання потрібно буде кілька разів, кожного разу варіюючи завдання.

• Крім завдань, в яких респондент повинен виконати яку-небудь дію, допустимі і бажані подвійні завдання, в яких респондент повинен спочатку вирішити, чи потрібно йому зараз цю дію виконувати.

• Деколи по ходу завдання потрібно насильницьки змінити стан системи. Наприклад, якщо ви хочете дізнатися, як саме користувачі вирішують певну проблему, вам доведеться цю проблему створити. Переривати для цього виконання тесту неприпустимо, оскільки це відверне респондента. У таких випадках перед відповідним завданням можна вставити інше завдання, в якому респондент повинен створити проблему самостійно. Зрозуміло, ніяких відомостей про інтерфейс таке завдання не надасть.

• Аналіз результатів і підведення статистики сильно спрощуються, якщо робити не мале число тривалих завдань, а велике число завдань коротких, таких, що вимагають переміщення всього на пару екранів або заповнення одної-двох форм.

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

Не забудьте перевірити, чи ваші сценарії можуть бути виконані респондентами за очікуваний час тесту. Ймовірно, список сценаріїв доведеться скорочувати.

Ознаки успішності виконання завдання

Останньою складовою сценарію є ознаки успішності виконання завдань. Справа ось в чому: не завжди одне і те ж завдання

можна виконати єдиним способом. Запускати ж тест, не знаючи всіх цих способів, некоректно, оскільки подальший аналіз вийде сумнівним. Припустимо, респондент А виконав завдання способом А, а респондент Б способом Б. Обидва респонденти справилися із завданням, але один все-таки краще за іншого. Як-не-як різні способи, мабуть, мають різну ефективність, наприклад, число дій, що входять в спосіб Б в півтора рази більше за число дій способу А. Спосіб А в такій ситуації переважний, в ідеальній системі (до якої потрібно прагнути) всі користувачі повинні використовувати тільки його.

Крім того, деколи правильний результат тесту з погляду експериментатора насправді не є правильним, особливо, якщо предметна область складна, а фахівець знає її недостатньо. Щоб переконатися, що правильний результат саме такий, як вважає і тестер, йому необхідно знайти фахівця з системи і предметної області, і запитати. Не знаючи твердо всіх способів виконання завдання, ви просто не зможете впізнати помилки.

Проведення тестування. Отже, тест підготовлений і можна приступати.

Процедура проста. Включивши запис і усадивши респондента за комп'ютер:

1. введіть респондента в завдання;

2. з'ясуйте у нього його очікування від системи;

3. протестуйте інтерфейс;

4. з'ясуйте, наскільки виправдалися очікування респондента;

5. завершіть тест.

Підготовка звіту

Після проведення тестування необхідно передати виявлені відомості замовникові. Як правило, кращим засобом для цього є більш-менш формальний звіт. Щоб звіт вийшов ефективним, крім, власне кажучи, якісно проведеного тестування, потрібно враховувати декілька речей, головною з яких є оптимальна

структура звіту. У загальному вигляді оптимальною структурою звіту є:

1. Резюме

2. Основні проблеми (інтерфейсні проблеми, що виявляються по всьому інтерфейсу)

3. Приватні проблеми (проблеми, що виявляються на окремих екранах)

4. Кількісні дані (якщо вони збиралися)

5. Застосування 1. Методика експерименту і умови тесту

6. Застосування 2. Опис тестових сценаріїв

7. Застосування 3. Опис респондентів

Завдання:

Виконати тестування інтерфейсу користувача власного програмного продукту.

Контрольні запитання:

1. Що називається тестуванням інтерфейсу?

2. Які є методи тестування інтерфейсу?

3. Що називають тестовим сценарієм?

4. Які ознаки успішності виконання тестового завдання вам відомі?

5