Превратите один возрастной значок в проверяемую карту покрытия при работе приложения

Сначала зафиксируйте, что именно контролирует возрастной рейтинг

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

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

Создайте по одной строке для каждой области контента и направления передачи данных. Обязательные столбцы: область контента; направление — входящее, исходящее, сгенерированное, загруженное или рекомендованное; тестовый аккаунт и возрастной статус; устройство и сборка; наблюдаемый статус; значение по умолчанию; кто может изменить; где находится элемент управления; поведение при сбое; способ отправки жалобы; подтверждение; триггер следующей повторной проверки. Используйте только пять меток статуса: заблокировано, предупреждение, размыто, разрешено и доступно для жалобы. Это не шкала качества. Размытое изображение также может быть доступно для жалобы, а разрешенная ссылка может по-прежнему вызывать предупреждение. Если возникают два исхода, зафиксируйте два наблюдения вместо их объединения в статус «отфильтровано». Явно отмечайте непротестированные и недоступные элементы; ни один из этих статусов не означает «разрешено».

Разделяйте ответы ИИ и ввод пользователя

Выделите отдельные строки для сгенерированного текста, сгенерированных изображений, сгенерированного голоса, подсказок и уведомлений. Затем протестируйте текстовые запросы, загрузки файлов, голосовой ввод, поля профиля и импортированный контекст в качестве строк пользовательского ввода. Система может отклонить загрузку файла, но при этом сгенерировать неподобающую подсказку из обычного текста, либо отфильтровать основную беседу, оставив превью уведомлений без изменений. Используйте нейтральные, четко размеченные тестовые сценарии, проверяющие маршрутизацию, не подвергая специалистов проверке недопустимыми материалами. Фиксируйте, когда происходит вмешательство: до генерации, до отображения, после отображения или только после отправки жалобы. Также отмечайте, меняется ли результат при повторной генерации, редактировании, отправке другим пользователям или переключении модели и режима. Статуса «ИИ-фильтр включен» недостаточно в качестве подтверждения, поскольку для путей ввода и вывода могут применяться разные элементы управления.

Составьте карту путей перехода в сообщество, к контактам и внешним ссылкам

Укажите профили, имена пользователей, комментарии, публичные публикации, приглашения в группы, поиск контактов, личные сообщения, вложения и предварительный просмотр сообщений как отдельные области. Для каждой из них проверьте отображение со стороны отправителя и получателя, а также результат после блокировки, отключения звука или жалобы. Для внешних ссылок требуются отдельные строки: кликабельные URL, скопированный текст, QR-коды, встроенные браузеры, опубликованные ответы ИИ, рекламные объявления и страницы поддержки. Фиксируйте, блокирует ли приложение конечный ресурс, предупреждает ли перед переходом, открывает ли встроенный браузер или выполняет переход без уведомления. Настройка, действующая для публичных публикаций, может не распространяться на личные сообщения, а предупреждение о ссылке в чате может не применяться к рекламной карточке.

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

Для изображений разделяйте съемку камерой, загрузку из галереи, генерацию ИИ, полученные вложения, миниатюры, полноэкранный просмотр, сохранение и отправку другим пользователям. Для голоса разделяйте прямой ввод, сохраненную запись, транскрипцию, синтезированный ответ, автовоспроизведение, уведомления и экспорт. В строке должно быть указано, заблокирован ли объект, показано ли предупреждение, размыт ли он, разрешен или доступен для жалобы до и после того, как пользователь откроет его. Проверяйте вывод в наушники и предварительный просмотр на экране блокировки, где это применимо. Если элемент управления зависит от анализа на сервере, протестируйте запрос в автономном режиме или при истечении времени ожидания и запишите видимое состояние сбоя. Безопасное поведение должно быть явным; индикатор загрузки, пустая панель или незаметный обход фильтра — это неизвестный результат, а не доказательство работы фильтрации.

Включайте рекламу и покупки в общую карту покрытия

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

Повторно проверяйте настройки по умолчанию после каждого существенного изменения

Проверяйте каждую строку сначала с новым аккаунтом и исходными настройками, затем после того, как уполномоченный пользователь изменит параметр, на втором устройстве или в веб-клиенте, а также после выхода из аккаунта и повторного входа. Повторяйте проверку после обновления приложения, добавления новой модели или медиарежима, изменения политики либо появления новой области взаимодействия. Руководство eSafety по расширению возможностей пользователей подчеркивает важность строгих настроек безопасности по умолчанию, параметров с учетом возраста, фильтрации, предупреждений, размытия, скрытия, управления контактами, отправки жалоб и пересмотра параметров при изменении сервисов. Используйте это как контрольный ориентир при аудите: сохранило ли обновление выбранный параметр, вернуло ли его к более безопасным настройкам по умолчанию, добавило ли новую непроверенную строку или незаметно расширило доступ? Указывайте дату для каждого результата, чтобы старая успешная проверка не принималась за актуальное покрытие.

Формулируйте итоговый вывод строго в границах полученных доказательств

Завершите аудит тремя списками: подтвержденное покрытие, выявленные пробелы и запланированные повторные проверки. Рейтинг может быть корректным при неполном охвате фильтрацией во время работы; рабочий фильтр может функционировать на одном пути, пока данные в магазине устарели. Ни один из этих выводов не отменяет другой. Обоснованное заключение называет конкретную протестированную сборку и области контента, содержит снимки или записи экрана без конфиденциальных данных и фиксирует все неизвестные параметры. Не выставляйте единую общую оценку «безопасно» и не сравнивайте продукты только по значкам рейтингов. Практическое решение более конкретно: имеют ли определенные области, которые планирует использовать семья, подходящие настройки по умолчанию, понятные элементы управления, наглядное поведение при сбоях и работающий механизм отправки жалоб, сохраняющийся после обновления.

Продолжить изучение темы