Где и как следует тестировать мобильное приложение в процессе контроля качества?

Почему QA следует проводить на реальных устройствах?
Сценарии тестирования на реальных устройствах в TestFlight и стратегии проведения QA до и после выпуска приложения

1. QA не заканчивается на выявлении различий между экранами.

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

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

Перед выпуском приложения мы проверили iOS TestFlight STG на iPhone Pro, изучив не только визуальные несоответствия, но и переходы между экранами, поведение при вводе данных и единообразие компонентов.

QA до выпуска и QA после выпуска имеют разные цели.

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

2. Figma, веб-версия STG и приложение TestFlight — это разные среды проверки.

Figma — это инструмент для проверки спецификаций дизайна. Он удобен для сравнения выравнивания, цветов, свойств компонентов и различных состояний экранов, но не может в точности воспроизвести клавиатуру, системные панели, жесты и другие аспекты реальной среды ОС. Мобильное представление веб-версии STG удобно для проверки адаптивных стилей и поведения веб-страницы, однако нельзя гарантировать, что оно покажет различия, возникающие внутри контейнера приложения, таким же образом.

TestFlight — это средство установки и распространения тестовых версий приложений для iOS. STG — это тестируемая среда и канал, через который доставляется приложение. Различение этих понятий позволяет определить, к какому коду, настройкам и сборке относится результат проверки.

Области проверки, которые становятся понятны только на реальных устройствах

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

То же относится к клавиатуре и сенсорным взаимодействиям. Точнее всего проверять их в реальном контексте использования: открывается ли клавиатура сразу после нажатия на поле ввода, появляется ли подходящая клавиатура для числового ввода, корректно ли реагирует выбранная область во время прокрутки и не закрывает ли клавиатура кнопки в нижней части экрана. По статичному изображению трудно обнаружить, что после перехода между экранами остался предыдущий экран.

Иными словами, элементы, которые можно эффективно проверить в Figma и веб-версии STG, следует проверять в первую очередь, а элементы, определяющие качество поведения на реальном устройстве, необходимо проверять в самом приложении.

3. Сценарии QA, выявленные в TestFlight STG до выпуска
(Проблемы, которые становятся понятны только при проверке на реальном устройстве)

Записи QA на устройствах нельзя объединить в одну категорию, ограничивающуюся простым отличием от дизайна. До начала анализа первопричины или распределения ответственности удобнее разделить проблемы на четыре типа — визуальное представление, ввод и сенсорное взаимодействие, состояние навигации и общие компоненты. Это упрощает определение приоритетов исправлений и выбор элементов для повторной проверки.

Случай 1.) Визуальное несоответствие между нижней частью экрана и системной областью
Это может выглядеть всего лишь как разница в несколько пикселей, но она связана с тем, как различаются прокручиваемое содержимое, закреплённые кнопки и системная Safe Area. Во время проверки следует изучать не только полноэкранные скриншоты, но и то, остаются ли кнопки закреплёнными, сохраняются ли те же правила при отображении нижнего листа или клавиатуры и остаётся ли содержимое согласованным на коротких и длинных экранах.

Случай 2.) Проблемы поведения, выявленные при взаимодействии с вводом и сенсорным экраном

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

04. Даже при одной и той же проблеме сторона, которая её проверяет, и сторона, которая её исправляет, могут различаться.

Общие компоненты и единообразие представления

В документации QA зафиксированы такие проблемы, как размеры кнопок, выглядящие больше указанных в макетах, несоответствия размера и стиля иконок, различия в оформлении областей выбора в выпадающих списках, а также запросы на изменение отображения переносов строк и подчёркиваний. Если существуют общие компоненты или токены стилей, сначала проверьте соответствующие спецификации и путь их применения. Например, если один и тот же выпадающий список выглядит по-разному на нескольких экранах, изменение CSS только одного экрана может быть быстрым, но не станет фундаментальным решением. Сначала проверив, является ли структура реализации общей, нужны ли стили-исключения и актуальны ли спецификации компонента в Figma, легче определить объём последующего регрессионного тестирования.

[Распределение ролей между дизайном, вёрсткой и разработкой]

Минимальная единица документирования проблемы

Наиболее практичный способ документирования в реальных условиях — указать в одном элементе «на каком устройстве и в какой сборке, когда и в каком порядке выполнялись действия, чем ожидаемый результат отличался от фактического». Скриншоты служат визуальным подтверждением, а короткие записи экрана или пошаговые сценарии воспроизведения эффективнее при проблемах с переходами между экранами, вводом данных и прокруткой. Указание типа проблемы, степени серьёзности, ответственной области, статуса исправления и факта завершения повторной проверки помогает избежать ситуации, когда обнаруженные проблемы превращаются в разрозненные простые комментарии.
Иными словами, не рекомендуется вести запросы на доработку экранов и идеи новых UX-улучшений в одном списке ошибок. Разделение несоответствий и дефектов с одной стороны и предложений по улучшению с другой делает планирование и принятие решений о выпуске более понятными.

05. Операционные принципы устойчивого QA

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

06. Операционные принципы неповторяющегося дизайн-QA: критерии, о которых должна договориться операционная команда

Во-первых, чётко управляйте версиями стандартов дизайна. Разделяйте рабочие экраны и предлагаемые улучшения, а также отмечайте финализированные дизайны, на которые должна ориентироваться разработка.

Во-вторых, фиксируйте область проверки для каждой единицы изменения. Даже если изменён только один экран, область влияния может быть шире, если он использует общие компоненты или глобальные стили.

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

В-четвёртых, ведите отдельно отчёт о завершении исправления и фактическом завершении повторной проверки.

В-пятых, не пропускайте проверку основных пользовательских потоков сразу после операционного развёртывания.

[Простой чек-лист QA на реальном устройстве]

Более длинный чек-лист не обязательно приводит к более тщательному QA. Важнее расставить приоритеты для регулярно обнаруживаемых ошибок, действий, существенно влияющих на пользователей, и часто изменяемых общих компонентов, а также обеспечить возможность сравнивать их по одним и тем же критериям до и после выпуска.

Заключение

Экраны, завершённые в Figma, являются отправной точкой для обеспечения качества. Даже экран, который выглядит нормально в веб-версии STG, может вести себя на реальном устройстве не так, как ожидается, из-за системных областей, клавиатуры, сенсорных взаимодействий и навигационных потоков. Разнообразные проблемы, выявленные во время предрелизного QA в TestFlight, демонстрируют необходимость тестирования на реальных устройствах. В то же время решить эти проблемы только посредством финальной проверки со стороны специалиста по дизайну сложно.
После выпуска специалисты по дизайну, публикации и разработке должны сначала проверить каждый свою область, проверить пользовательские потоки на реальном устройстве в STG, а затем связать этот процесс с повторной проверкой исправлений и проверкой рабочего развёртывания. Ценность QA заключается не в том, чтобы в конце найти больше проблем, а в создании структуры проверки, которая предотвращает повторное появление тех же проблем по мере развития продукта.

*Ссылки

Apple. Human Interface Guidelines: Layout. Документация Apple для разработчиков.

Apple. Обзор TestFlight. Справка App Store Connect.

Google. Тестирование разных размеров экранов и окон. Android Developers.

Google. Основы тестирования приложений Android. Android Developers.

ISTQB. Подтверждающее тестирование. Глоссарий ISTQB.

hrg