Введение в нефункциональное тестирование

В то время как функциональное тестирование отвечает на вопрос “Работает ли?”, нефункциональное тестирование отвечает на не менее важные вопросы: “Хорошо ли оно работает? Удобно ли оно? Доступно ли оно? Работает ли оно везде?”

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

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

Понимание нефункционального тестирования

Что такое нефункциональное тестирование?

Нефункциональное тестирование оценивает как работает система, а не что она делает (в отличие от функционального тестирования, которое фокусируется на том, что система делает). Оно фокусируется на атрибутах качества, включая:

  • Юзабилити: Насколько легко и приятно использовать систему?
  • Производительность: Насколько она быстра и отзывчива?
  • Надёжность: Насколько она стабильна и надёжна?
  • Совместимость: Работает ли она в разных окружениях?
  • Безопасность: Насколько хорошо она защищена?
  • Доступность: Могут ли все пользователи, включая людей с ограниченными возможностями, использовать её?
  • Локализация: Адаптируется ли она к разным языкам и культурам?

Почему важно нефункциональное тестирование

Влияние на бизнес:

  • Удержание пользователей: 88% пользователей не вернутся после плохого пользовательского опыта
  • Юридическое соответствие: Недостатки доступности могут привести к судебным искам
  • Охват рынка: Плохая локализация ограничивает глобальную экспансию
  • Репутация бренда: Проблемы совместимости наносят ущерб доверию
  • Конкурентное преимущество: Превосходный UX дифференцирует продукты

Реальные последствия пренебрежения нефункциональным тестированием:

Пример 1: E-commerce сайт
- 1 секунда задержки загрузки страницы = 7% снижение конверсий
- Плохая мобильная совместимость = 50% потенциальных клиентов потеряно
- Недоступный checkout = Нарушение ADA регуляций

Пример 2: SaaS приложение
- Сложный UI = Более высокие затраты на поддержку и отток пользователей
- Нет поддержки RTL языков = Рынок Ближнего Востока недоступен
- Несовместимость браузеров = Потеря корпоративных контрактов

Пример 3: Мобильное приложение
- Высокое использование памяти = Отзывы с 1 звездой и удаления
- Плохая локализация = Плохие рейтинги в международных маркетах
- Недостатки доступности = Исключение 15% потенциальных пользователей

Usability Testing: обеспечение качества, ориентированное на человека

Понимание юзабилити

Определение: Юзабилити измеряет, насколько эффективно, результативно и с удовлетворением пользователи могут достигать своих целей, используя систему.

Пять качественных компонентов юзабилити (Якоб Нильсен):

  1. Обучаемость: Насколько легко новым пользователям выполнять задачи?
  2. Эффективность: Насколько быстро опытные пользователи могут выполнять задачи?
  3. Запоминаемость: Могут ли пользователи вспомнить, как использовать систему после перерыва?
  4. Ошибки: Сколько ошибок делают пользователи и могут ли они восстановиться?
  5. Удовлетворение: Насколько приятен опыт?

Методы usability testing

1. Модерируемое usability testing

Что: Фасилитатор ведёт пользователей через задачи, наблюдая и задавая вопросы.

Когда использовать:

  • Ранняя валидация дизайна
  • Сложные рабочие процессы
  • Когда нужны глубокие инсайты
  • Медицинские, финансовые или критические системы

Процесс:

1. Подготовка:
   - Определить цели
   - Создать тестовые сценарии
   - Нанять участников (5-8 пользователей на раунд)
   - Подготовить тестовое окружение
   - Создать скрипт фасилитатора

2. Выполнение:
   - Приветствие и согласие
   - Объяснить протокол "думай вслух"
   - Представить сценарии
   - Наблюдать и делать заметки
   - Задавать уточняющие вопросы
   - Анкета после теста

3. Анализ:
   - Идентифицировать паттерны между пользователями
   - Категоризировать проблемы по серьёзности
   - Вычислить показатели успеха и время на задачу
   - Документировать инсайты и рекомендации

Лучшие практики:

  • Использовать реалистичные сценарии, а не “Нажмите кнопку входа”
  • Избегать наводящих вопросов
  • Оставаться нейтральным—не помогать, если не необходимо
  • Записывать сессии (с разрешением)
  • Тестировать с представительными пользователями
  • Фокусироваться на задачах, не на функциях

Пример сценария (хороший):

"Вы только что закончили тренировку и хотите зарегистрировать её в приложении.
Зарегистрируйте вашу 30-минутную пробежку этим утром."

Пример сценария (плохой):

"Нажмите кнопку 'Добавить тренировку' и заполните форму."

2. Немодерируемое удалённое тестирование

Что: Пользователи выполняют задачи самостоятельно, пока их взаимодействия записываются.

Когда использовать:

  • Нужны большие выборки
  • Распределённая база пользователей
  • Бюджетные ограничения
  • Нужна быстрая обратная связь

Инструменты:

  • UserTesting
  • Lookback
  • Maze
  • UsabilityHub

Плюсы:

  • Экономически эффективно
  • Более быстрые результаты
  • Естественная среда
  • Большие размеры выборки

Минусы:

  • Нет уточнений в реальном времени
  • Нельзя задать уточняющие вопросы
  • Может пропустить контекст
  • Технические проблемы сложнее решить

3. A/B тестирование

Что: Сравнение двух версий для определения, какая работает лучше.

Когда использовать:

  • Оптимизация конкретных элементов
  • Дизайн-решения на основе данных
  • Высокотрафиковые приложения
  • Инкрементальные улучшения

Что A/B тестировать:

  • Кнопки призыва к действию (цвет, текст, расположение)
  • Заголовки и копирайтинг
  • Структура навигации
  • Макеты форм
  • Представление цен
  • Изображения vs видео контент

Лучшие практики:

✓ Тестировать одну переменную за раз
✓ Обеспечить статистическую значимость
✓ Запускать тесты достаточно долго (обычно минимум 1-2 недели)
✓ Сегментировать результаты по типу пользователя
✓ Учитывать внешние факторы (сезонность, кампании)
✓ Документировать и делиться выводами

Пример A/B теста:

Гипотеза: Изменение CTA с "Отправить" на "Получить бесплатную пробную версию"
увеличит конверсии

Метрика: Коэффициент конверсии (отправки формы / просмотры страницы)
Размер выборки: Минимум 1000 конверсий на вариант
Продолжительность: 2 недели
Результат: Версия B увеличила конверсии на 23%

4. Эвристическая оценка

Что: Эксперты оценивают интерфейс на соответствие установленным принципам юзабилити.

10 эвристик юзабилити Нильсена:

  1. Видимость системного статуса: Держать пользователей информированными о том, что происходит

    • Пример: Прогресс-бары, индикаторы загрузки, подтверждающие сообщения

  2. Соответствие между системой и реальным миром: Использовать знакомый язык и концепции

    • Пример: Иконка корзины для удаления, иконка корзины покупок для покупок

  3. Контроль и свобода пользователя: Предоставить отмену/повтор

    • Пример: “Отменить отправку” в email, опции редактирования/удаления

  4. Согласованность и стандарты: Следовать конвенциям платформы

    • Пример: Логотип вверху слева, поиск вверху справа, согласованные стили кнопок

  5. Предотвращение ошибок: Лучше, чем хорошие сообщения об ошибках

    • Пример: Отключение недопустимых опций, подтверждение разрушительных действий

  6. Распознавание, а не вспоминание: Минимизировать нагрузку на память

    • Пример: Выпадающие меню, недавно использованные элементы, автозаполнение

  7. Гибкость и эффективность: Горячие клавиши для опытных пользователей

    • Пример: Клавиатурные сокращения, шаблоны, массовые действия

  8. Эстетичный и минималистичный дизайн: Никакой нерелевантной информации

    • Пример: Прогрессивное раскрытие, чистые макеты, чёткая иерархия

  9. Помогать пользователям распознавать, диагностировать и восстанавливаться от ошибок: Чёткие сообщения об ошибках

    • Пример: “Пароль должен быть 8+ символов” вместо “Неверный ввод”

  10. Помощь и документация: Поисковая, ориентированная на задачи, краткая

    • Пример: Контекстная помощь, всплывающие подсказки, поисковая база знаний

Проведение эвристической оценки:

1. Подготовка:
   - Выбрать 3-5 оценщиков
   - Определить область (всё приложение или конкретные функции)
   - Предоставить чек-лист эвристик

2. Оценка:
   - Каждый оценщик независимо проверяет интерфейс
   - Документировать нарушения с:
     * Какая эвристика нарушена
     * Серьёзность (косметическая, незначительная, major, катастрофическая)
     * Местоположение (скриншот, страница, функция)
     * Описание проблемы
     * Предлагаемое исправление

3. Дебрифинг:
   - Консолидировать находки
   - Удалить дубликаты
   - Приоритизировать проблемы
   - Создать план действий

Метрики юзабилити

Количественные метрики:

  1. Показатель успеха задачи: % пользователей, успешно выполнивших задачу

    Формула: (Успешные завершения / Всего попыток) × 100
Хорошо: >78%

  2. Время на задачу: Сколько времени занимает выполнение

    Измерение: Среднее время, медианное время
Сравнение: С бенчмарками или предыдущими версиями

  3. Частота ошибок: Ошибки, сделанные во время задач

    Формула: (Количество ошибок / Всего попыток задачи) × 100
Отслеживание: Тип ошибок и восстановление

  4. Клики/тапы до завершения: Мера эффективности

    Лучшая практика: Минимизировать шаги до цели
Правило 3 кликов: Критическая информация доступна в пределах 3 кликов

Качественные метрики:

  1. System Usability Scale (SUS): Стандартизированный опрос из 10 вопросов

    Диапазон оценок: 0-100
Выше 68: Выше среднего
Выше 80: Отлично

  2. Net Promoter Score (NPS): “Насколько вероятно порекомендуете?”

    Шкала: 0-10
Промоутеры: 9-10
Пассивные: 7-8
Детракторы: 0-6
NPS = % Промоутеров - % Детракторов

  3. Customer Satisfaction (CSAT): “Насколько вы удовлетворены?”

    Шкала: 1-5 или 1-7
Хорошо: >80% удовлетворены (4-5 по 5-балльной шкале)

Чек-лист usability testing

Навигация и информационная архитектура:

  • Пользователи могут быстро найти то, что ищут
  • Навигация согласована между страницами
  • Хлебные крошки помогают пользователям понять местоположение
  • Функция поиска работает хорошо
  • Метки меню чёткие и описательные

Формы и ввод:

  • Формы максимально короткие
  • Метки чёткие и правильно расположены
  • Обязательные поля чётко отмечены
  • Валидация ввода полезная, не фрустрирующая
  • Сообщения об ошибках конкретные и действенные
  • Форма запоминает введённые данные при ошибке

Контент и читаемость:

  • Текст легко сканируется (заголовки, маркеры, короткие параграфы)
  • Размер шрифта читаем (минимум 16px для основного текста)
  • Коэффициент контрастности соответствует стандартам (минимум 4.5:1)
  • Важные действия визуально выделены
  • Контент использует простой язык

Мобильная юзабилити:

  • Сенсорные цели минимум 44×44px
  • Текст читаем без зума
  • Горизонтальная прокрутка не требуется
  • Формы оптимизированы для мобильных
  • Навигация дружественна для большого пальца

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

  • Загрузка страницы ощущается быстрой (<3 секунды)
  • Действия предоставляют немедленную обратную связь
  • Состояния загрузки предотвращают замешательство
  • Ошибки предотвращаются, где возможно
  • Подтверждения успеха чёткие

Compatibility Testing: обеспечение универсального доступа

Понимание compatibility testing

Определение: Compatibility testing проверяет, что программное обеспечение работает корректно в разных окружениях, включая браузеры, устройства, операционные системы и сети.

Типы совместимости:

  • Совместимость браузеров: Chrome, Firefox, Safari, Edge и т.д.
  • Совместимость устройств: Desktop, планшет, мобильный, разные размеры экрана
  • Совместимость ОС: Windows, macOS, Linux, iOS, Android
  • Сетевая совместимость: Разные скорости, сценарии offline
  • Совместимость баз данных: Разные системы баз данных
  • Обратная совместимость: Работает со старыми версиями

Browser compatibility testing

Доля рынка определяет приоритеты (по состоянию на 2025):

Desktop:
- Chrome: ~65% (Приоритет 1)
- Safari: ~15% (Приоритет 1)
- Edge: ~10% (Приоритет 2)
- Firefox: ~7% (Приоритет 2)
- Другие: ~3% (Приоритет 3 или пропустить)

Mobile:
- Chrome Mobile: ~65% (Приоритет 1)
- Safari iOS: ~25% (Приоритет 1)
- Samsung Internet: ~6% (Приоритет 2)
- Другие: ~4% (Приоритет 3 или пропустить)

Подход к тестированию:

1. Идентифицировать целевые браузеры:

Анализировать вашу аналитику:
- Какие браузеры используют ваши пользователи?
- Какие версии?
- Какой процент трафика?

Определить уровни поддержки:
Уровень 1: Полностью поддерживается, все функции работают (90% пользователей)
Уровень 2: Поддерживается, критические функции работают (9% пользователей)
Уровень 3: Best effort, контент доступен (1% пользователей)

2. Создать тестовую матрицу:

Браузер    | Версии        | Операционные системы | Приоритет
-----------|---------------|----------------------|----------
Chrome     | Latest, N-1   | Windows, Mac         | P0
Safari     | Latest, N-1   | Mac, iOS             | P0
Edge       | Latest        | Windows              | P1
Firefox    | Latest        | Windows, Mac         | P1
Samsung    | Latest        | Android              | P2

3. Распространённые проблемы совместимости:

CSS проблемы:

/* Поддержка Flexbox */
.container {
  display: -webkit-box;      /* Старый Safari */
  display: -webkit-flex;     /* Safari 6.1+ */
  display: -ms-flexbox;      /* IE 10 */
  display: flex;             /* Современные браузеры */
}

/* Поддержка Grid - проверить caniuse.com */
@supports (display: grid) {
  .grid-container {
    display: grid;
  }
}

/* Вендорные префиксы */
.element {
  -webkit-transform: rotate(45deg);
  -ms-transform: rotate(45deg);
  transform: rotate(45deg);
}

JavaScript проблемы:

// Функции ES6 могут требовать полифиллы для старых браузеров
// Проверить совместимость: caniuse.com

// Стрелочные функции
const multiply = (a, b) => a * b;  // Может потребоваться Babel

// Promises
fetch('/api/data')  // Может потребоваться полифилл для IE11
  .then(response => response.json())
  .then(data => console.log(data));

// Использовать обнаружение функций
if ('IntersectionObserver' in window) {
  // Использовать IntersectionObserver
} else {
  // Fallback подход
}

4. Инструменты тестирования:

Платформы кросс-браузерного тестирования:

  • BrowserStack: Реальные устройства и браузеры в облаке
  • Sauce Labs: Автоматизированное и ручное тестирование
  • LambdaTest: Живое и автоматизированное тестирование
  • CrossBrowserTesting: Тестирование реальных браузеров

Локальное тестирование:

  • BrowserStack Local: Тестирование localhost на реальных браузерах
  • Виртуальные машины: Тестирование на разных ОС
  • Device lab: Физические устройства для тестирования

Автоматизированное тестирование:

// Selenium WebDriver - кросс-браузерная автоматизация
const { Builder, By, Key, until } = require('selenium-webdriver');

async function testCrossBrowser(browserName) {
  let driver = await new Builder()
    .forBrowser(browserName)
    .build();

  try {
    await driver.get('http://yoursite.com');
    await driver.findElement(By.name('q')).sendKeys('webdriver', Key.RETURN);
    await driver.wait(until.titleIs('webdriver - Google Search'), 1000);
  } finally {
    await driver.quit();
  }
}

// Тестирование в браузерах
testCrossBrowser('chrome');
testCrossBrowser('firefox');
testCrossBrowser('safari');

Тестирование устройств и отзывчивости

Стратегия тестирования:

1. Определить матрицу устройств:

Категория       | Устройства                        | Приоритет
----------------|-----------------------------------|----------
Мобильный - Маленький | iPhone SE (375×667)         | P0
Мобильный - Средний   | iPhone 14 (390×844)         | P0
Мобильный - Большой   | iPhone 14 Pro Max (430×932) | P1
Планшет               | iPad (810×1080)             | P1
Desktop - Маленький   | 1366×768                    | P0
Desktop - Средний     | 1920×1080                   | P0
Desktop - Большой     | 2560×1440                   | P2

2. Responsive breakpoints:

/* Mobile first подход */
/* Базовые стили: Мобильный (320px+) */
.container {
  padding: 1rem;
}

/* Планшет (768px+) */
@media (min-width: 768px) {
  .container {
    padding: 2rem;
    max-width: 720px;
  }
}

/* Desktop (1024px+) */
@media (min-width: 1024px) {
  .container {
    padding: 3rem;
    max-width: 960px;
  }
}

/* Большой desktop (1280px+) */
@media (min-width: 1280px) {
  .container {
    max-width: 1200px;
  }
}

3. Чек-лист тестирования:

Макет:

  • Нет горизонтальной прокрутки ни в каком viewport
  • Контент читаем без зума
  • Изображения масштабируются соответствующе
  • Текст не выходит за границы контейнеров
  • Grid/flex макеты работают корректно

Сенсорные взаимодействия:

  • Сенсорные цели минимум 44×44px
  • Кнопки имеют адекватное расстояние
  • Свайп-жесты работают (если реализовано)
  • Выпадающие меню дружественны к касаниям
  • Hover состояния имеют сенсорные эквиваленты

Производительность:

  • Изображения оптимизированы для мобильных
  • Реализована ленивая загрузка
  • Минимальный JavaScript на мобильных
  • Быстрая начальная загрузка страницы

4. Инструменты тестирования:

  • Chrome DevTools: Симуляция устройств
  • Firefox Responsive Design Mode: Множественные viewports
  • Реальные устройства: Тестирование физических устройств
  • BrowserStack: Облако реальных устройств
  • Responsively App: Все viewports одновременно

Совместимость операционных систем

Соображения тестирования:

Различия Desktop ОС:

Windows vs macOS:
- Рендеринг шрифтов (Windows: ClearType, Mac: более гладкий)
- Клавиатурные сокращения (Ctrl vs Cmd)
- Пути файлов (обратная косая черта vs прямая косая черта)
- Доступность шрифтов по умолчанию
- Стилизация элементов управления формы

Linux:
- Различные дистрибутивы (Ubuntu, Fedora и т.д.)
- Разные окружения рабочего стола (GNOME, KDE)
- Доступность шрифтов варьируется

Различия Mobile ОС:

iOS vs Android:
- Safari vs Chrome браузер по умолчанию
- Разные выборщики даты/времени
- Различное поведение ввода форм
- Обработка сенсорных событий
- Различия push-уведомлений
- APIs доступа к камере/файлам

Лучшие практики compatibility testing

1. Приоритизировать на основе данных:

✓ Использовать аналитику для идентификации браузеров/устройств пользователей
✓ Тестировать самые распространённые конфигурации первыми
✓ Определить минимальные поддерживаемые версии
✓ Документировать политику поддержки браузеров

2. Автоматизировать где возможно:

✓ Автоматизированные кросс-браузерные тесты в CI/CD
✓ Визуальное регрессионное тестирование
✓ Тесты адаптивного дизайна
✓ Автоматизация доступности

3. Использовать прогрессивное улучшение:

✓ Основная функциональность работает везде
✓ Улучшенные функции для современных браузеров
✓ Изящная деградация для старых браузеров
✓ Обнаружение функций вместо обнаружения браузера

4. Документировать совместимость:

✓ Поддерживать матрицу поддержки браузеров
✓ Документировать известные проблемы
✓ Предоставлять обходные пути, если доступны
✓ Регулярно обновлять

Локализация и интернационализация Testing

Понимание L10n и I18n

Интернационализация (i18n): Проектирование программного обеспечения так, чтобы оно могло быть адаптировано к различным языкам и регионам без изменения кода.

Локализация (l10n): Адаптация интернационализированного программного обеспечения для конкретного региона или языка.

Думайте об этом как:

  • i18n = Сделать это возможным
  • l10n = Действительно сделать это

Интернационализация: строительство для глобального охвата

Ключевые требования i18n:

1. Обработка текста:

// НЕТ: Жёстко закодированный текст
<button>Submit</button>

// ДА: Экстернализированные строки
<button>{t('common.submit')}</button>

// Языковые файлы
en.json: { "common": { "submit": "Submit" } }
es.json: { "common": { "submit": "Enviar" } }
ru.json: { "common": { "submit": "Отправить" } }

2. Поддержка Unicode:

✓ Использовать кодировку UTF-8 везде
✓ Поддерживать символы из любого языка
✓ Обрабатывать эмодзи и специальные символы
✓ Правильный расчёт длины строки (кластеры графем, не байты)

Примеры проблем:
"Café" в UTF-8: é может быть 1 или 2 символа в зависимости от нормализации
"👨‍👩‍👧‍👦" (эмодзи семьи): Выглядит как 1 символ, но на самом деле несколько

3. Дата и время:

// НЕТ: Жёстко закодированный формат
const date = "12/01/2025";  // Неоднозначно: Дек 1 или Янв 12?

// ДА: Использовать форматирование, осознающее локаль
const date = new Date('2025-01-12');
const formatted = new Intl.DateTimeFormat('en-US').format(date);
// Вывод: 1/12/2025 (US)

const formattedUK = new Intl.DateTimeFormat('en-GB').format(date);
// Вывод: 12/01/2025 (UK)

const formattedRU = new Intl.DateTimeFormat('ru-RU').format(date);
// Вывод: 12.01.2025 (Россия)

// Часовые пояса
const options = {
  timeZone: 'Europe/Moscow',
  hour: '2-digit',
  minute: '2-digit'
};

4. Числа и валюта:

// Форматирование чисел
const number = 1234567.89;

new Intl.NumberFormat('en-US').format(number);
// Вывод: 1,234,567.89

new Intl.NumberFormat('de-DE').format(number);
// Вывод: 1.234.567,89

new Intl.NumberFormat('ru-RU').format(number);
// Вывод: 1 234 567,89

// Валюта
const amount = 99.99;

new Intl.NumberFormat('en-US', {
  style: 'currency',
  currency: 'USD'
}).format(amount);
// Вывод: $99.99

new Intl.NumberFormat('ru-RU', {
  style: 'currency',
  currency: 'RUB'
}).format(amount);
// Вывод: 99,99 ₽

new Intl.NumberFormat('ja-JP', {
  style: 'currency',
  currency: 'JPY'
}).format(amount);
// Вывод: ¥100 (JPY не использует десятичные знаки)

5. Направление текста:

/* Поддержка RTL (Right-to-Left) языков как арабский, иврит */

/* НЕТ: Фиксированное направление */
.container {
  text-align: left;
  padding-left: 20px;
}

/* ДА: Логические свойства */
.container {
  text-align: start;  /* Адаптируется к направлению текста */
  padding-inline-start: 20px;  /* Слева в LTR, справа в RTL */
}

/* HTML атрибут направления */
<html dir="rtl" lang="ar">

/* RTL-специфические стили */
[dir="rtl"] .icon {
  transform: scaleX(-1);  /* Зеркалить иконки при необходимости */
}

6. Расширение текста:

Длина текста перевода варьируется:

Английский "Account" (7 символов)
→ Немецкий "Benutzerkonto" (14 символов) - на 100% длиннее
→ Французский "Compte d'utilisateur" (20 символов) - на 185% длиннее

Соображения дизайна:
✓ Не устанавливать фиксированные ширины для текста
✓ Позволять тексту переноситься
✓ Тестировать с самым длинным языком
✓ Использовать гибкие макеты (flexbox, grid)
✓ Добавлять 30-40% дополнительного пространства в дизайны

Обычные факторы расширения:
Английский → Немецкий: +30%
Английский → Французский: +15-20%
Английский → Русский: +10-15%

Локализация Testing

Что тестировать:

1. Качество перевода:

Чек-лист:
- [ ] Весь текст переведён (нет английского в русской версии)
- [ ] Переводы контекстуально корректны
- [ ] Нет обрезанного текста
- [ ] Нет переполнения текста
- [ ] Консистентность терминологии
- [ ] Культурная уместность
- [ ] Нет артефактов машинного перевода

2. Лингвистическое тестирование:

Грамматика и орфография:
- [ ] Правильная грамматика
- [ ] Подходящая пунктуация
- [ ] Соответствующий уровень формальности (формальный vs неформальный)
- [ ] Согласование родов (языки с родовыми существительными)
- [ ] Множественные формы (некоторые языки имеют множественные формы множественного числа)

Пример: Русские множественные числа
1 файл (1 file)
2 файла (2 files)
5 файлов (5 files)
Разные окончания для 1, 2-4, и 5+ элементов

3. Форматирование:

- [ ] Форматы дат корректны для локали
- [ ] Форматы времени (12 vs 24 часа)
- [ ] Форматы чисел (десятичный разделитель)
- [ ] Символы валюты и размещение
- [ ] Форматы телефонных номеров
- [ ] Форматы адресов
- [ ] Порядок имени (имя сначала vs фамилия сначала)

4. Культурная адаптация:

- [ ] Изображения уместны для культуры
- [ ] Цвета имеют правильное культурное значение
- [ ] Иконки понятны в целевой культуре
- [ ] Примеры релевантны региону
- [ ] Нет оскорбительного контента
- [ ] Праздники и празднования локализованы

Примеры:
- ❌ Эмодзи поднятого большого пальца: Оскорбительно в некоторых странах Ближнего Востока
- ❌ Красный: Удача в Китае, опасность в западных странах
- ❌ Сова: Мудрость на Западе, неудача в некоторых азиатских культурах
- ❌ Примеры адресов: Использовать местный формат и реальные названия городов

5. Функциональность, специфичная для локали:

- [ ] Локальные способы оплаты поддерживаются
- [ ] Доступны локальные варианты доставки
- [ ] Расчёт местных налогов
- [ ] Локальное юридическое соответствие (GDPR, CCPA и т.д.)
- [ ] Местная контактная информация
- [ ] Часы работы местной поддержки клиентов

6. RTL (Right-to-Left) тестирование:

Для арабского, иврита, персидского:
- [ ] Текст течёт справа налево
- [ ] Макет правильно зеркалируется
- [ ] Иконки зеркалируются где уместно
- [ ] Формы выравниваются корректно
- [ ] Таблицы читаются справа налево
- [ ] Скроллбары на правильной стороне
- [ ] Меню навигации перевёрнуто

Инструменты тестирования:

  • Псевдолокализация: Тестирование i18n без реальных переводов

    Английский: "Save Changes"
Псевдо: "[§Śàvè Çĥàñĝèś Ţèśţ Éẋţŕà Çĥàට]"

Преимущества:
- Показывает непереведённые строки
- Тестирует расширение текста
- Находит проблемы кодирования
- Не нужно знать целевой язык

  • Управление переводом: Crowdin, Lokalise, Phrase

  • Автоматизированное тестирование: Проверка отсутствующих переводов, консистентности ключей

  • Носители языка: Всегда вовлекать для финальной валидации

Лучшие практики локализации

✓ Планировать i18n с первого дня
✓ Экстернализировать все строки
✓ Использовать ICU MessageFormat для сложных строк
✓ Тестировать с реальными носителями языка
✓ Избегать текста в изображениях
✓ Использовать библиотеки, осознающие локаль
✓ Документировать контекст перевода
✓ Внедрять непрерывную локализацию
✓ Тестировать рано и часто
✓ Учитывать культурные различия помимо языка

Accessibility Testing: инклюзивный дизайн

Понимание доступности

Определение: Доступность обеспечивает, чтобы люди с ограниченными возможностями могли воспринимать, понимать, навигировать и взаимодействовать с программным обеспечением.

Кто получает пользу от доступности:

  • 15% мировой популяции имеет какую-либо форму инвалидности
  • Постоянные инвалидности: Слепота, глухота, моторные нарушения
  • Временные инвалидности: Сломанная рука, глазная инфекция
  • Ситуационные ограничения: Яркий солнечный свет, шумная среда, занятые руки

Юридический и бизнес-кейс:

Юридические требования:
- ADA (Americans with Disabilities Act)
- Раздел 508 (правительство США)
- EN 301 549 (ЕС)
- Потенциальные судебные иски за несоответствие

Бизнес-выгоды:
- Больший охват рынка
- Лучший SEO (доступность пересекается с SEO)
- Улучшенная юзабилити для всех пользователей
- Корпоративная социальная ответственность
- Драйвер инноваций

Руководства WCAG 2.1

Web Content Accessibility Guidelines (WCAG) 2.1 организованы вокруг четырёх принципов:

1. Воспринимаемый

Информация должна быть представлена пользователям способами, которые они могут воспринять.

1.1 Текстовые альтернативы:

<!-- Изображения -->
<img src="chart.png" alt="Продажи увеличились на 25% в Q4">

<!-- Декоративные изображения -->
<img src="decorative-line.png" alt="">

<!-- Сложные изображения -->
<img src="complex-chart.png"
     alt="Гистограмма, показывающая квартальные продажи"
     longdesc="sales-data.html">

<!-- Иконки с текстом -->
<button>
  <svg aria-hidden="true">...</svg>
  <span>Удалить</span>
</button>

<!-- Иконки без текста -->
<button aria-label="Удалить элемент">
  <svg aria-hidden="true">...</svg>
</button>

1.2 Медиа, основанные на времени:

Видеоконтент:
- [ ] Субтитры для глухих пользователей
- [ ] Аудиоописания для слепых пользователей
- [ ] Доступна транскрипция

Аудиоконтент:
- [ ] Доступна транскрипция

1.3 Адаптируемый:

<!-- Правильная структура заголовков -->
<h1>Главный заголовок</h1>
  <h2>Раздел 1</h2>
    <h3>Подраздел 1.1</h3>
  <h2>Раздел 2</h2>

<!-- Семантический HTML -->
<nav>...</nav>
<main>...</main>
<aside>...</aside>
<footer>...</footer>

<!-- Списки -->
<ul><!-- Неупорядоченный список --></ul>
<ol><!-- Упорядоченный список --></ol>

<!-- Таблицы -->
<table>
  <thead>
    <tr>
      <th scope="col">Имя</th>
      <th scope="col">Возраст</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Иван</td>
      <td>30</td>
    </tr>
  </tbody>
</table>

1.4 Различимый:

Цветовой контраст:
- Обычный текст: Минимальное соотношение 4.5:1
- Большой текст (18pt+): Минимальное соотношение 3:1
- UI компоненты: Минимальное соотношение 3:1

Тестирование контраста:
- Chrome DevTools
- WebAIM Contrast Checker
- Плагин Stark для Figma

Не использовать только цвет:
❌ "Обязательные поля красные"
✓ "Обязательные поля помечены звёздочкой (*)"

Изменение размера текста:
- [ ] Текст может быть изменён до 200% без потери функциональности
- [ ] Использовать относительные единицы (rem, em), а не фиксированные пиксели

2. Управляемый

Компоненты пользовательского интерфейса должны быть управляемыми.

2.1 Доступность с клавиатуры:

<!-- Все интерактивные элементы должны быть доступны с клавиатуры -->

<!-- Нативные элементы доступны с клавиатуры по умолчанию -->
<button>Нажми меня</button>
<a href="/page">Ссылка</a>
<input type="text">

<!-- Пользовательские элементы нуждаются в tabindex -->
<div role="button" tabindex="0" onKeyPress={handleKey}>
  Пользовательская кнопка
</div>

<!-- Ссылка перехода к основному контенту -->
<a href="#main-content" class="skip-link">
  Перейти к основному контенту
</a>

<main id="main-content">
  ...
</main>

<!-- Предотвращение клавиатурной ловушки -->
<!-- Пользователи должны быть способны уйти от любого компонента -->

Тестирование клавиатурной навигации:

- [ ] Tab через все интерактивные элементы
- [ ] Shift+Tab навигирует назад
- [ ] Enter активирует кнопки/ссылки
- [ ] Пробел активирует кнопки/чекбоксы
- [ ] Стрелки работают в dropdown/radio группах
- [ ] Escape закрывает модалы/dropdown
- [ ] Фокус виден на всех элементах
- [ ] Логический порядок табуляции
- [ ] Нет клавиатурных ловушек

2.2 Достаточно времени:

Время регулируемо:
- [ ] Пользователь может продлить временные ограничения
- [ ] Пользователь может отключить временные ограничения (где возможно)
- [ ] Пользователь предупреждён перед таймаутом
- [ ] Как минимум 20 секунд для продления

Автовоспроизводящийся контент:
- [ ] Пользователь может поставить на паузу/остановить/скрыть автообновляющийся контент
- [ ] Нет автовоспроизведения, если только пользователь не может контролировать

2.3 Судороги:

- [ ] Ничего не мигает более 3 раз в секунду
- [ ] Нет больших мигающих областей
- [ ] Параллакс-эффекты могут быть отключены

2.4 Навигируемый:

<!-- Заголовки страниц -->
<title>Название страницы - Название сайта</title>

<!-- Ориентиры -->
<header role="banner">...</header>
<nav role="navigation" aria-label="Главная">...</nav>
<main role="main">...</main>
<aside role="complementary">...</aside>
<footer role="contentinfo">...</footer>

<!-- Порядок фокуса -->
<!-- Визуальный порядок должен соответствовать DOM порядку -->

<!-- Цель ссылки -->
❌ <a href="/products">Нажмите здесь</a>
✓ <a href="/products">Посмотреть наши продукты</a>

<!-- Множественные способы найти страницы -->
- Поиск
- Карта сайта
- Меню навигации
- Хлебные крошки

3. Понятный

Информация и операция должны быть понятными.

3.1 Читаемый:

<!-- Язык страницы -->
<html lang="ru">

<!-- Язык частей -->
<p>Французское слово <span lang="fr">bonjour</span> означает привет.</p>

<!-- Ясный язык -->
- Использовать простой язык
- Определять жаргон
- Расшифровывать аббревиатуры
- Предоставлять контент соответствующего уровня чтения

3.2 Предсказуемый:

Консистентная навигация:
- [ ] Навигация в том же месте на каждой странице
- [ ] Одинаковые компоненты имеют одинаковые метки

Консистентная идентификация:
- [ ] Иконки имеют консистентные значения
- [ ] Одинаковая функциональность = одинаковые метки

При фокусировке:
- [ ] Фокус не запускает неожиданные изменения
- [ ] Модал не открывается при фокусировке

При вводе:
- [ ] Отправка формы требует явного действия
- [ ] Нет автоматической навигации при выборе

3.3 Помощь ввода:

<!-- Идентификация ошибок -->
<label for="email">Email *</label>
<input
  type="email"
  id="email"
  aria-invalid="true"
  aria-describedby="email-error"
>
<span id="email-error" role="alert">
  Пожалуйста, введите валидный email адрес
</span>

<!-- Метки и инструкции -->
<label for="password">
  Пароль (минимум 8 символов)
</label>
<input type="password" id="password">

<!-- Предотвращение ошибок -->
- Подтверждение для деструктивных действий
- Возможность просмотра перед отправкой
- Возможность отмены отправки

4. Надёжный

Контент должен быть достаточно надёжным для работы с вспомогательными технологиями.

4.1 Совместимый:

<!-- Валидный HTML -->
- Нет дублирующихся ID
- Правильная вложенность
- Закрытые теги

<!-- ARIA (Accessible Rich Internet Applications) -->
<!-- Имя, Роль, Значение должны определяться программно -->

<button
  role="button"
  aria-label="Закрыть диалог"
  aria-pressed="false"
>
  ×
</button>

<div
  role="progressbar"
  aria-valuenow="25"
  aria-valuemin="0"
  aria-valuemax="100"
  aria-label="Прогресс загрузки"
>
  25% завершено
</div>

Методы accessibility testing

1. Автоматизированное тестирование:

Инструменты:
- axe DevTools (расширение браузера)
- Lighthouse (Chrome DevTools)
- WAVE (WebAIM)
- Pa11y (командная строка)

Улавливает ~30-40% проблем:
✓ Отсутствующий alt текст
✓ Цветовой контраст
✓ Отсутствующие метки
✓ Невалидный ARIA
✓ Структура заголовков

Не улавливает:
✗ Качество порядка фокуса
✗ Качество alt текста
✗ Поток клавиатурной навигации
✗ Опыт программы чтения с экрана
✗ Контекст и значение

2. Ручное тестирование:

Клавиатурная навигация:
1. Отключить мышь
2. Навигировать используя только клавиатуру
3. Проверить доступность всей функциональности
4. Проверить индикаторы фокуса
5. Проверить логический порядок табуляции

Тестирование программы чтения с экрана:
- NVDA (Windows, бесплатно)
- JAWS (Windows, платно)
- VoiceOver (Mac/iOS, встроенный)
- TalkBack (Android, встроенный)

Базовый тест программы чтения с экрана:
1. Включить программу чтения с экрана
2. Навигировать с помощью сокращений программы чтения с экрана
3. Проверить, что весь контент объявлен
4. Проверить формы и взаимодействия
5. Проверить качество альтернативного текста

3. User testing:

Тестировать с реальными пользователями с ограниченными возможностями:
- Слепые пользователи (программы чтения с экрана)
- Пользователи с низким зрением (увеличение)
- Пользователи с моторными нарушениями (только клавиатура)
- Глухие пользователи (субтитры)
- Когнитивные инвалидности (ясный язык)

Преимущества:
- Реальные паттерны использования
- Обнаружить проблемы, которые упускают инструменты
- Построение эмпатии
- Инновационные инсайты

Чек-лист доступности

Основа:

  • Валидный, семантический HTML
  • Логическая структура заголовков
  • Определены landmark регионы
  • Предоставлены skip links
  • Заголовок страницы описывает контент

Изображения и медиа:

  • Все изображения имеют alt текст
  • Декоративные изображения имеют пустой alt
  • Сложные изображения имеют длинные описания
  • Видео имеют субтитры
  • Аудио имеют транскрипции

Формы:

  • Все inputs имеют метки
  • Обязательные поля указаны
  • Сообщения об ошибках ясные и конкретные
  • Ошибки ассоциированы с inputs
  • Fieldsets группируют связанные inputs

Клавиатура:

  • Вся функциональность доступна с клавиатуры
  • Индикаторы фокуса видимы
  • Логический порядок табуляции
  • Нет клавиатурных ловушек
  • Ссылки пропуска навигации

Цвет и контраст:

  • 4.5:1 контраст для обычного текста
  • 3:1 контраст для большого текста
  • Цвет не является единственным индикатором
  • Работает в режиме высокого контраста

Вспомогательные технологии:

  • Работает с программами чтения с экрана
  • ARIA используется соответствующе
  • Live регионы для динамического контента
  • Статусные сообщения объявляются

Контент:

  • Используется простой язык
  • Текст ссылки описательный
  • Установлен язык страницы
  • Инструкции не зависят от формы/размера/местоположения

Заключение

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

  • Usability testing гарантирует, что ваше программное обеспечение интуитивно и приятно в использовании
  • Compatibility testing гарантирует доступ через браузеры, устройства и платформы
  • Локализация testing открывает глобальные рынки и показывает культурное уважение
  • Accessibility testing включает всех и часто улучшает опыт для всех пользователей

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

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

Ресурсы

Юзабилити:

  • Nielsen Norman Group: https://www.nngroup.com/
  • Usability.gov
  • “Don’t Make Me Think” Стива Круга
  • “The Design of Everyday Things” Дона Нормана

Совместимость:

  • Can I Use: https://caniuse.com/
  • MDN Web Docs Browser Compatibility
  • BrowserStack, LambdaTest (платформы тестирования)

Локализация:

  • Unicode CLDR (Common Locale Data Repository)
  • ICU (International Components for Unicode)
  • Crowdin, Lokalise (платформы перевода)

Доступность: