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

Звісно, тестувальники - не письменники, але всі документи, які отримують кінцеві користувачі, мають бути максимально зрозумілими та зручними для читання. Як створити документацію, яка буде відповідати всім вимогам користувача? Відповідь у цій статті.

Практичні поради, як створити документацію, яка сподобається всім

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

Правило №1 Робота з пошуком і навігацією

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

Правило №2 Зручна навігація

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

Але як дізнатися, чого хоче користувач? Точної відповіді не може бути. Тим не менш, варто звернути увагу на кілька основних принципів. По-перше, поставте себе на місце клієнта. По-друге, проаналізуйте потенційні труднощі, які можуть виникнути при першому використанні програмного забезпечення. Відповіді на ці питання допоможуть вам структурувати зміст майбутнього посібника.

Правило №3 Вирішення нових викликів

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

Правило №4 Загальність завдань

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

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

Правило №5 Авторський мінімалізм

Рекомендується уникати беззмістовної інформації та нерелевантних даних. Будь-який з доданих (зайвих) блоків буде лише конкурувати за увагу кінцевого користувача. Це вкрай ускладнить пошук потрібної інформації.

Висновки

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