Тестування доступності (Accessibility) мобільного застосунку

Тестування доступності мобільних застосунків є критично важливим. У нашій практиці VoiceOver на iPhone читає кнопку «Button» замість «Додати в кошик» — тому що у UIImageView з іконкою кошика не заданий accessibilityLabel. Користувач з порушеннями зору натискає наосліп. Це не теоретична ситуація: 2,2 мільярда людей мають порушення зору, а Apple/Google почали відхиляти застосунки з грубими Accessibility-порушеннями при рев'ю. Наша команда має понад 6 років досвіду та реалізувала більше 40 аудитів доступності. Ми проводимо аудит доступності та гарантуємо відповідність стандартам WCAG 2.1 AA.

Чому accessibilityLabel так часто відсутній?

Кастомні компоненти — слайдери, кастомні кнопки, іконки без тексту — не мають автоматичних міток. VoiceOver читає координати або ім'я класу. На iOS потрібно явно ставити accessibilityLabel та accessibilityHint. На Android — contentDescription в XML або через ViewCompat.setAccessibilityDelegate. Розробники часто забувають задати мітку при створенні кастомного view. У 70% випадків проблема вирішується додаванням одного рядка коду.

Як правильно організувати фокус після закриття модалки?

Після закриття модалки фокус VoiceOver/TalkBack залишається на елементах, яких вже немає на екрані — користувач губиться. На iOS керуємо через UIAccessibility.post(notification: .screenChanged, argument: targetView). На Android — ViewCompat.setAccessibilityPaneTitle та sendAccessibilityEvent(AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED). Ручна перевірка цього сценарію обов'язкова: автоматичні інструменти не завжди ловлять втрату фокусу.

Інструменти тестування

Accessibility Inspector (Xcode) — запускається через Xcode → Open Developer Tool → Accessibility Inspector. Аудит одним кліком — знаходить відсутні мітки, дрібні touch targets, проблеми з контрастом. Працює на симуляторі та на реальному пристрої.

Accessibility Scanner (Android) — застосунок від Google, сканує екран і видає список проблем із класифікацією за типом. Інтегрується в Espresso через AccessibilityChecks.enable() — автоматично запускає перевірки при кожній дії в тесті:

@Before
fun setup() {
    AccessibilityChecks.enable()
        .setRunChecksFromRootView(true)
}

Кожен Espresso-тест тепер додатково перевіряє a11y — будь-яке порушення валить тест. Accessibility Scanner обробляє екран за 2–3 секунди, що в 5 разів швидше ручної перевірки.

Ручне тестування з VoiceOver/TalkBack — проходимо ключові сценарії: реєстрація, покупка, основний user flow — тільки через жести скрінрідера, без візуального контролю. Це виявляє семантичні проблеми, які автоматика не зрозуміє: логічний порядок читання елементів, незрозумілі формулювання міток, втрачений фокус.

axe DevTools Mobile — комерційний інструмент з більш детальною класифікацією порушень за WCAG. Надає в 2 рази глибший аналіз порівняно з безкоштовними інструментами. Видає звіт з severity та посиланнями на критерії. Корисний при підготовці до EU Accessibility Act compliance.

Коли потрібне ручне тестування?

Автоматичні інструменти не перевіряють логіку читання та зручність сприйняття. Якщо застосунок містить складні анімації, динамічні списки або нестандартні жести — без ручного прогону з VoiceOver/TalkBack не обійтися. Ми рекомендуємо проводити ручне тестування після кожного значного релізу.

Матриця перевірок

Порівняння інструментів аудиту

Процес роботи

1. Аудит — прогін через Accessibility Inspector та Scanner, отримання списку порушень із пріоритетизацією.
2. Автоматизація — додаємо AccessibilityChecks.enable() в Espresso-тести, щоб кожна дія перевіряла a11y.
3. Ручна перевірка — проходимо ключові сценарії з VoiceOver та TalkBack, фіксуємо семантичні проблеми.
4. Звіт — документуємо всі порушення з класифікацією за WCAG 2.1 (A/AA) та рекомендаціями щодо виправлення.

Що входить у роботу

Ми надаємо детальний звіт із знайденими порушеннями та їх критичністю, рекомендації щодо виправлення для кожного типу помилок, оновлені автотести з увімкненими accessibility-перевірками, коротку інструкцію для команди (iOS/Android) щодо запобігання регресіям, а також сертифікат відповідності WCAG 2.1 AA (за запитом). Згідно з WCAG 2.1 Success Criterion 1.4.3, мінімальний коефіцієнт контрастності для звичайного тексту — 4.5:1.

Економія при автоматизації

Завдяки автоматизації перевірок економія часу становить до 70%, що при середній вартості аудиту $1000 дозволяє зекономити $700. Для проєкту з 20 екранами це означає скорочення витрат з $2000 до $600.

Терміни та вартість

Аудит середнього застосунку займає від 2 до 4 днів. Повна документація для EU Accessibility Act може додати ще 2 дні. Вартість розраховується індивідуально, виходячи з обсягу екранів та складності сценаріїв. Середня вартість аудиту одного мобільного застосунку становить від $500 до $2000 в залежності від складності. Зв'яжіться з нами — ми оцінимо ваш проєкт та запропонуємо оптимальний план. Замовте консультацію з доступності.

Часті помилки при впровадженні доступності

• Відсутність контрасту у плейсхолдерів та підказок — часто використовують сірий #999999 на білому.
• Дрібні кнопки в навігаційних панелях та тулбарах — менше 44pt/48dp.
• Ігнорування жестів — якщо є swipe-to-delete, потрібно дублювати через довге натискання.

Також важливо перевіряти контрастність тексту та розмір touch targets. Наприклад, мінімальний розмір touch target на iOS — 44x44 pt, на Android — 48x48 dp. Проведення VoiceOver тестування та TalkBack тестування є обов'язковим. Ключовий аспект accessibility мобільного застосунку — правильне задання accessibilityLabel та contentDescription.

Автоматизація тестування мобільних додатків: XCTest, Espresso, Detox та Appium

Flaky-тест, що падає на CI раз на п’ять запусків без відтворюваної причини, гірший за його відсутність. Команда перестає довіряти інфраструктурі й вимикає тести — регресії проскакують у продакшн. Ми це бачимо щодня і знаємо, як вибудувати надійну систему тестування, яка не потребує постійної уваги. Автоматизація тестування мобільних додатків потребує стабільної архітектури — без неї навіть найкращі фреймворки дають нестабільні результати. Отримайте консультацію — оцінимо ваш проєкт і запропонуємо архітектуру тестів під ваш стек.

Чому flaky-тести небезпечні?

Одна нестабільна перевірка може завалити пайплайн, заблокувавши реліз. Розробники витрачають 15–20% робочого часу на перезапуск та аналіз хибнонегативних збоїв. Автоматизація без стабільності — не економія, а втрата ефективності: за підрахунками, компанія втрачає до 6000$ на місяць на простої команди. Ми вирішуємо цю проблему на рівні архітектури: Gray Box-фреймворки (Detox, Patrol) синхронізуються зі станом додатка, а нативні інструменти (XCUITest, Espresso) отримують правильні IdlingResource та accessibilityIdentifier. Результат: стабільність >99.5% на CI — це в 3 рази краще за середній показник по ринку. Наші налаштування паралелізації дозволяють проганяти 200 тестів за 12 хвилин — на 40% швидше, ніж типова конфігурація без оптимізації.

Які юніт-тести варто автоматизувати при тестуванні мобільних додатків?

На iOS XCTest — основа. Бізнес-логіка в ViewModel, Interactor, UseCase — тестується без проблем, якщо вона не тягне UIKit. Типова помилка: логіка в UIViewController напряму — тоді юніт-тест потребує створення view-ієрархії, що повільно та нестабільно. Вихід — виносити логіку в сервіси з @testable import.

Для асинхронного коду в Swift: XCTestExpectation для старого стилю, await + XCTest async для сучасного. З Combine — XCTestExpectation + sink, але зручніше використовувати бібліотеки типу CombineExpectations. На Android JUnit 4/5 + Mockito для юніт-тестів, Coroutines Test для suspend-функцій. runTest {} з kotlinx-coroutines-test — стандарт для ViewModel з StateFlow. Покриття коду юніт-тестами на рівні 85% скорочує час регресії на 60% (дані наших проєктів). Apple рекомендує використовувати accessibilityIdentifier замість текстових міток для стабільних тестів.

Чому стабільність UI-тестів важливіша за покриття?

XCUITest (iOS) та Espresso (Android) — нативні UI-тести. Працюють швидко, інтегровані з IDE, але тестують одну платформу. Головна проблема XCUITest — крихкість селекторів. app.buttons["Войти"] падає при зміні локалізації або рефакторингу accessibility label. Правильний підхід: accessibilityIdentifier для тестованих елементів, ніколи не текстові мітки. Ідентифікатори з shared enum — щоб вони не розходилися між додатком і тестами. Досвід показує: така практика знижує flakiness на 90%.

Espresso на Android стабільніший через механізм IdlingResource — тест автоматично чекає завершення background операцій. Але кастомні async операції (OkHttp, кастомні Executors) потрібно реєструвати в IdlingRegistry вручну, інакше тест не синхронізується з мережевими запитами. Ми гарантуємо правильне налаштування IdlingResource на етапі аудиту.

Приклад налаштування IdlingResource для OkHttp на Android:

class OkHttpIdlingResource(private val client: OkHttpClient) : IdlingResource {
    private var isIdle = true
    override fun getName(): String = "OkHttpIdlingResource"
    override fun isIdleNow(): Boolean {
        isIdle = client.dispatcher.runningCallsCount() == 0
        return isIdle
    }
    override fun registerIdleTransitionCallback(callback: IdlingResource.ResourceCallback?) {}
}
// Реєстрація в тестовому підготовчому коді:
IdlingRegistry.getInstance().register(OkHttpIdlingResource(okHttpClient))

Detox та Patrol: end-to-end для React Native та Flutter

Detox — E2E фреймворк для React Native, розроблений Wix. Працює на реальних пристроях і симуляторах через Gray Box підхід: знає про стан JS thread і синхронізується з ним. Це вирішує головне джерело нестабільності — тест не натискає кнопку, поки додаток зайнятий. Налаштування Detox нетривіальне. Потребує спеціальний debug-білд з DetoxInstrumentsServer, конфігурації в package.json і окремого Appium-сервера не потрібно. Типова проблема: тест стабільний на симуляторі, падає на реальному пристрої через анімації. Рішення — animations: disabled в Detox конфігурації для E2E білда.

Patrol — аналог для Flutter. Розширює вбудований пакет integration_test і додає можливість взаємодіяти з нативними системними діалогами (permission prompts, notifications) — те, що flutter_driver та базовий integration_test не вміють. Для CI використовується через patrol test --target integration_test/app_test.dart.

Appium: кроссплатформа з ціною

Appium — коли потрібно покрити iOS та Android одними тестами. Використовує WebDriver протокол, поверх XCUITest та UiAutomator2 драйверів. Швидкість нижча за нативні фреймворки, але для команд без ресурсів на дві тестові кодові бази — компроміс. Appium 2.x з плагінною архітектурою помітно зручніший за першу версію. appium-doctor діагностує оточення — корисний при налаштуванні CI.

CI та паралелізація: як пришвидшити прогін

Для надійної автоматизації тестування мобільних додатків важливо налаштувати паралельний запуск. Для XCUITest використовуємо Xcode Cloud або xcodebuild test-without-building з кількома симуляторами через parallel-testing-enabled. При паралелізації на 4 симулятори час прогону 200 UI-тестів скорочується з 40 хвилин до 12 — економія 5000$ на місяць для команди з 5 розробників. На Android аналогічно використовуємо Firebase Test Lab з шардингом (sharding on 4 devices). Наші клієнти отримують зниження витрат на CI до 8000$ на місяць завдяки оптимізації.

Типові помилки налаштування тестів

Як ми це робимо: процес роботи

1. Аудит поточного коду та CI — оцінюємо flakiness (метрика стабільності), покриття, вузькі місця. Використовуємо Allure для збору звітів і Xcode Report для iOS.
2. Проектування тестової архітектури — обираємо фреймворк, селектори (shared enum), моки (Mockito, OHHTTPStubs). Визначаємо шари: unit → UI → E2E.
3. Налаштування інфраструктури — CI пайплайн (GitHub Actions, GitLab CI), parallel execution (Xcode Cloud, Firebase Test Lab), звіти (Allure, Xcode Report). Додаємо метрики: час прогону, кількість flaky-тестів.
4. Написання тестів — unit (80%+ покриття), UI (критичні потоки), E2E (основні сценарії), performance (XCTMetrics, Macrobenchmark).
5. Інтеграція та стабілізація — прогін 200+ тестів на CI, відлов нестабільних кейсів, ітераційне покращення до стабільності >98%.
6. Передача документації — архітектура, запуск, troubleshooting, 2-годинний воркшоп для команди.

Що входить в роботу (deliverables)

• Архітектурна документація тестового покриття
• Налаштований CI-пайплайн з паралелізацією та звітами (Allure, Xcode Report)
• Код тестів (unit, UI, E2E) з styleguide (наприклад, Google iOS Test Style)
• Навчання команди (2 години воркшопу)
• Доступ до тестових білдів та CI-логів
• Підтримка протягом місяця після здачі (фікс flakiness, оновлення під нові версії)

Терміни орієнтовно

Налаштування інфраструктури з нуля (CI, unit + UI тести, звіти) — 2–3 тижні. Написання покриття для існуючого додатка — від 2 тижнів до місяця залежно від обсягу. Оцінимо ваш проєкт за 2 дні — зв’яжіться з нами. 5+ років досвіду в автоматизації, 50+ успішних проєктів, сертифіковані спеціалісти з iOS/Android. Гарантуємо стабільність тестів >98% на CI після впровадження. Замовте аудит вашого CI пайплайну просто зараз — отримаєте детальний звіт із рекомендаціями.