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

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

Пам’ятайте про найважливіші етапи тестування документації.

• Швидше за все, ви знаєте про останні зміни, внесені до програми, більше, ніж автор документації, тому перевірте її актуальність.
• Попереджуйте технічного автора про будь-які зміни в програмі.
• Перевірте, чи є в програмі функції, які не описані в документації або описані недостатньо детально.
• Звертаємо Вашу увагу, що співробітники компанії компанії з тестування продуктивності дуже хотіли б зробити вас щасливими, ведучи ваш додаток до успіху.
• Коли ви залучаєте до проекту нового тестувальника, перш за все, доручіть йому протестувати програму за останньою версією керівництва користувача. У більшості випадків нові тестувальники, залучені до середньомасштабних проектів, знаходяться десь між альфа-стадією та фазою заморожування користувацького інтерфейсу.
• Постійно контролюйте хід виконання проекту, звіряючи його результати з очікуваннями, а також з реалістичністю і термінами. Огляд прогресу проекту потрібно проводити щотижня. Які нові завдання стоять перед вами, які вже вирішені? Як вони впливають на виконання плану проекту, скільки часу займають? Чи задовольняють вас часові рамки? Якщо ні, то які заходи можна вжити? Можливо, необхідно зменшити обсяг проекту або повністю виключити певні проектні активності? Чи допоможе справі збільшення кількості тестувальників? А може, програмісти настільки відстають від графіка, що ваше відставання не має значення. Однак останнє міркування не може бути виправданням, і ось чому.
  • Якщо ви працюєте надто повільно, ви знайдете помилки пізніше, ніж це було б зроблено за планом. Таким чином, стара частина програми не буде готова вчасно, тому що ви не змогли знайти в ній помилку в зазначений термін.
  • Намагаючись наздогнати, ви починаєте працювати швидше, роблячи зім’яті і нерозбірливі звіти, вони стають менш корисними для відтворення помилок, і, як наслідок, загальна робота затягується ще більше, а її якість страждає.