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% з активним моніторингом

Таємниче життя вашого API

#testing #api

З чого все почалося

Цього тижня я проводив експерименти з тим, як працює наша система з блоками різної довжини. Для цього я знайшов вбудований інструмент (Glutton pallet), який дозволяє заповнювати обрати наскільки заповнювати блоки "сміттєвою" інформацією. Конкретно - блоки заповнюються масивами 8-бітних чисел.

Тестування було простим - заповнити блок, скажімо на 2 Mb випадковими бінарними даними й подивитись наскільки швидко він розповсюджується по мережі. Активація інструменту виконується на рівні коду, але ліміти на заповнення можна встановлювати через зручний UI. Встановивши розмір заповнення в 2 Mb, я дивився на моніторинг й робив необхідні вимірювання.

Але для перевірки, я вирішив зробити простий JSON-RPC запит окремого випадкового блоку через Postman. Ось тут почалася магія.

Postman показав мені відповідь від серверу, але розмір body був не 2 Mb, а ...4 Mb. Я спробував декілька інших блоків, але з тим самим результатом.
Я встановив розмір блоку в 1 Mb - response в Postman був розміру 2 Mb. Але ... чому?

Відповідь

Інструмент для замірів працював корректно. Але виявилось, що кожного разу коли ми робимо запит на JSON-RPC то під капотом результат автоматично кодується за допомогою SCALE кодека. Кожен байт в бінарному форматі кодується як два HEX символи. Тобто масив з 1024 байтів на виході буде мати аж 2048 символів. Причому кодування виконується "під капотом" самого вузла.

Висновок

Не завжди дані, які ми бачимо API відповіді від серверу показані саме так, як вони реально зберігаються в системі.

SMURF: Beyond the Test Pyramid

#automation #testing

Цікава ідея: розширений погляд на тестову піраміду від Google.

Автор пропонує виходити за рамки піраміди та оцінювати ваші тести за наступними параметрами:

- Швидкість. Чим швидше зворотній звʼязок тим краще.

- Складність у підтримці. Чим більший рівень тестів - тим більше "під капотом" усього відбувається. Й тим більше часу треба на підтримку.

- Використання ресурсів. Чим менше ресурсів використує тест, тим швидше він виконується.

- Надійність. Надійний тест падає тоді й тільки тоді, коли є проблема.

- Реалістичність. Реалістичні тести перевіряють систему в умовах максимально наближених до реальних.

There is no single winner: Selenium AND Playwright

#testing #automation

Сьогодні говоримо про UI тести.

Marcus Merrell порівнює можливості Selenium та Playwright.

А ще - автор росказує в чому, на його думку, є реальна проблема масової міграції проектів на стильний й модний Playwright.

🔖 Software Testing and Quality Report - 4th Edition

#testing

Тут Test Rail випустив чергове дослідження щодо поточного стану та трендів розвитку тестування. В опитуванні прийняли участь 2500+ спеціалістів, більшість з яких - саме тест інженери. Респонденти були з різних компаній за масштабом та процесами.

Головні інсайти:

👉 Метрики. Найбільше трекають test pass / fail rate (70%) та кількість багів у продакшені (60%). Але більш складні метрики мало використовуються
👉 35% команд зосереджені на збільшенні тестового покриття та автоматизації. Лише 20% працюють над зменшенням багів на проді (Автоматизація, тільки автоматизація!)
👉 33% страждають від надмірної складності UI тестів та рішень з автоматизації
👉 Чим більше у команд автоматизації та інтеграції в CICD процеси, тим швидше релізні цикли та ... менше дефектів опиняється на стороні клієнта. (Хм, неочікувано ...)
👉 Багато команд все ще мають обмежені бюджети на QA, а разом із тим - відсутність часу на тестування
👉 Незважаючи на малі бюджети, менеджери скаржаться на те, що QA мають недостатню експертизу в автоматизації, AI, CI/CD. (Тобто вимоги підвищуються, а зп знижується)
👉 Більшість команд користується стандартами ISO 9001 (27%) та ISO / IEC 27001 (18%)
👉 Selenium (39%) все ще розповсюджений серед тестерів. Playwright - на другому місці (19%), Cypress - на третьому (16%) (А як же Playwright is the king?)
👉 Jenkins в топі серед CI/CD інструментів - 45%
👉 41% респондентів запускає до 100 автотестів на день. 33% оперує вже більшими обʼємами (до 1000 тестів)
👉 Найчастіші проблеми з автотестами - нестабільність тестів через часті зміни в UI, погані тестові дані, відсутність знань та вмінь в інженерів (Може краще рухатись на нижчі, більш стабільні рівні?)
👉 Більшість інженерів користується Chat GPT / Github Copilot. Але 36% людей все ще не бачать, як ШІ може допомогти їм у роботі
👉 Проблеми із застосуванням інструментів ШІ: безпека даних, відсутність експертизи в команді та складність інтеграції
👉 Розвиток ШІ в тестуванні незмінний: люди все ще думають, що ШІ чарівним чином буде фіксити автотести та писати код за них. (Та чи так це насправді?)

🧪Про науковий метод й дослідницьке тестування

#testing

Побачив я якось пояснення наукового методу в книжці. Мені одразу спало на думку, що цей метод має багато спільного із тестуванням (особливо exploratory).

👉 Question. В тестуванні ми також вирішуємо ЩО САМЕ тестувати.
👉 Hypothesis. Ми формуємо гіпотези про поведінку продукту, які перевіряємо.
👉 Experiment and analyze data. Ми тестуємо та аналізуємо отримані результати.
👉 Refine. Ми робимо retesting, якщо треба перевірити нову гіпотезу чи білд.
👉 Peer-review. Ревʼю тестів, багів та код-ревʼю від колег.

Додаткова вимога, як до тестування так і до наукових дослідів - це відтворюваність результатів експерименту (тесту).

🚀То ж коли ми тестуємо, ми, як науковці, ставимо експерименти та доводимо правдивість (чи хибність) наших гіпотез.

📚 Несподівана знахідка зі світу тестування

#testing #books

Не так давно я розповідав про навчання. Хоча зараз я не так тісно повʼязаний із тестуванням, мені завжди цікаво шукати цікаві теми та підходи у світі якості. То ж я читаю й проглядаю книжки з тестування.

Деякі книжки хороші для новачків. Деякі - безнадійно застарілі й містять мало нового. Наприклад, "Mobile Testing" Рекса Блека хоч й цінна його коментарями підходів та інструментів, але нічого кардинально нового не дає. Книга від Daniel Knott більш практична.

😱Але деякі книжки виявляються справжньою несподіванкою (в хорошому сенсі). Яскравий приклад - це "Foundations of Software Testing" від Aditya P. Mathur.

Наче книга - з основ тестування. Але глибина матеріалу мене приємно вразила. Теми й приклади книги більш хардкорні, ніж у відомій "Advanced Software Testing - Vol. 1" (не ту книгу назвали Advanced 😀).

🕶 Як дочитаю - з мене огляд!

P.S. Для тих, хто не любить читати, можна подивитись архів слайдів на основі книги. (Всього 722 слайди!)

Три кроки для боротьби з рутиною в тестуванні, які допомогли мені

#testing #career

- "Нічого нового в тестуванні"
- "Все вже й так зрозуміло"
- "Таски всі однакові, доповіді всі однакові"
- "Тестування та АйТі перестало бути цікавим"
- "Booooring!"

Саме такі питання виникають в мене час від часу.

Що допомагає мені в такому випадку?

1️⃣ Розширьте коло інтересів: розробка, менеджмент (в тому числі й продуктовий), девопс, безпека, перфоманс, ШІ й інші технології. Знайдіть те, що зможе дати той самий "вогник цікавості" знову
2️⃣ Займіться хоббі (бажано не звʼязаному з АйТі). Погрузіться в нього з головою.
3️⃣ Візміть відпустку. Читайте й дивіться тільки контент не звʼязаний з роботою.

Я застосував усі три способи. То ж зараз маю трохи інший погляд на те, що мені цікаво в тестуванні. А також декілька інших інженерних (й не тільки) тем та хоббі.

А що допомагає Вам?

Тестування безпеки LLM систем

#ai #llm #security #testing

Багато хто користується LLM системами, такими як ChatGPT, Claude, Gemini та інші. Дехто - тестує інтеграцію таких систем з власними продуктами. А хтось навіть розробляє свої власні LLM системи для внутрішнього користування.

Але що там з безпекою LLM-ок? Виявляється, prompt injection атаки то не вигадка, а реальна загроза. Бо ШІ може погано розрізняти системні запити та користувацькі запити. В такому випадку зловмисник може відносно легко обійти авторизацію, закинути SQL інʼєкцію чи навіть виконати команди віддалено.

Деякі корисні ресурси з теми:
- Гайд по вразливостям від OWASP
- Обмеження в тестуванні LLM систем
- Як саме виконувати prompt injection

Тренуватись можна тут: Portswigger Web LLM attacks

🥳 З Днем Тестувальника!

#testing

Сьогодні 9 вересня - то ж вітаю усіх тест інженерів із професійним святом. 

Хочеться побажати бути інженерами, а не просто тестерами. 

Тестер просто перевіряє софт по тест кейсам та репортить результат. "Немає білду - сидимо тихо."

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

Тестери (як і кодери) можуть бути легко замінені ШІ. Інженери ще мають час. А там - подивимось.