Shift Left Testing on Mobile apps

#testing #automation #mobile

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

☎️Як Google рекомендує тестувати Android додатки

#testing #mobile #android #automation

🔎 Google поділився рекомендаціями з тестування мобільних застосунків на Android. Ще одна піраміда!

TL;DR:

1. Пропонують зосередитись на таких рівнях тестів, як Unit, Component, Feature, Application, Release Candidate. Навіть розписують стратегію.
2. Описують підхід - screenshot testing. Хоча він має свої переваги, але не рекомендується створювати занадто багато таких тестів.
3. Для тестування навантаження розрізняють local testing (benchmarking в контрольованому середовищі) та field testing - перевірка в максимально наближених до користувача умовах.
4. UI радять тестувати за допомогою behavior ui тестів. Для цього є різні фреймворки - Espresso, Jetpack Compose, UI Automator, Roboelectic.
5. Стабільність тестів (особливо UI) - важлива. То ж треба слідкувати за правильним налаштуванням пристроїв, приділяти увагу можливим помилкам синхронізації та робити перезапуски тестів.
6. Roboelectic фреймворк можна застосовувати як для unit, так і для UI тестів.
7. Не варто забувати також про тестування на екранах різного розміру. Для цього є свої окремі бібліотеки та підходи.

Стратегії мобільного тестування в різних компаніях

#testing #mobile

Знайшов цікавий тред про те, як в різних компаніях (Lyft, Spotify, Uber, RobinHood, Nordstrom, Shopify, Ford, Airbnb) налаштоване мобільне тестування.

Дуже рекомендую почитати!

Android тестування в Netflix, Dropbox, Spotify

#testing #automation #mobile

Вийшли свіжі статті про те, як влаштоване мобільне тестування, автоматизація та релізи у відомих компаніях.

Netflix (~50 інженерів)

- Прийшли від окремої команди SDET інженерів, до автоматизації в кожній окремій фіча команді. QA тестують мануально тільки фінальний smoke test.
- Піраміда виглядає як unit => screenshot => end-to-end => smoke
- Юніт тести за допомогою Strikt, Turbine, Mockito, Hilt, Roboelectric; Screenshot рівень автоматизується з Paparazzi / Espresso accesibility testing.
- UI автоматизація виконується з Espresso / UIAutomator + усілякі фреймворки для створення моків на бекенді
- Тести автоматично промоутяться до стабільних після визначеної кількості успішних запусків
- Unit + smoke тести на кожен PR. Окремі набори тестів - кожного дня чи тижня

Dropbox (~30 інженерів)

- Спочатку мали багато Е2E тестів, але з часом перейшли на рівні нижче
- Покриття юніт тестами стоїть на рівні 80% та виконується Roboelectric
- Девелоперів вчать проектувати тести: E2E тести включені в definition of done кожної задачі
- Screenshot тестування також з бібліотекою Paparazzi
- Мануальне тестування деяких кейсів все ще присутнє; тести трекаються в самописній TMS

Spotify

- Мають окрему релізну команду, що будує інструменти для полегшення релізів
- Тижневі релізні цикли - починають у пʼятницю (версія X.Y.Z)
- На окремому дашборді агрегуються усі баги конкретного релізу
- Наступна пʼятниця - релізний бранч для X.Y.Z
- Наступний тиждень - тестування версії X.Y.Z (включно з автотестами), підготовка та відправка в Store / Market
- Поступовий реліз на користувачів - починаючи з 1% та до 100% з активним моніторингом