אילו מכשירים לבדוק
אי אפשר לבדוק על כל דגם אנדרואיד, וגם אין צורך. בחירה נכונה של 15 עד 25 מכשירים, לפי הנתונים של המשתמשים שלכם, מכסה 85% עד 95% מהקהל.
שלב 1: נתחו את נתוני המשתמשים
שלפו את התפלגות המכשירים מכלי האנליטיקה (Firebase Analytics, Mixpanel, App Store Connect, Google Play Console):
- 10 המכשירים המובילים לפי סשנים פעילים
- 5 היצרנים המובילים באנדרואיד
- התפלגות גרסאות iOS (הגרסה הנוכחית ושתיים לפניה)
- התפלגות גדלי מסך
- התפלגות הזיכרון (RAM) במכשירי אנדרואיד
שלב 2: בנו מטריצת בדיקות
| קטגוריה | מכשירים | למה |
|---|
| ראשיים (חובה) | 5 המכשירים המובילים בנתונים שלכם | מכסים 40% עד 50% מהמשתמשים |
| משניים (מומלץ) | 5 עד 10 המכשירים הבאים בנתונים | מכסים עוד 25% עד 35% |
| מקרי קצה | אנדרואיד עם מעט זיכרון, גרסת iOS הוותיקה ביותר שנתמכת, המסך הגדול והקטן ביותר | תופסים באגים של ביצועים ושל פריסת מסך |
| דגמים חדשים | דגמי הדגל האחרונים של 3 היצרנים המובילים | מוודאים תאימות לחומרה החדשה ביותר |
שלב 3: רעננו כל רבעון
הפופולריות של מכשירים משתנה. Samsung Galaxy S25 יוצא לשוק, ותוך 3 חודשים הוא כבר בין 5 המכשירים המובילים באפליקציות רבות. את מטריצת הבדיקות צריך לעדכן כל רבעון לפי נתוני המשתמשים העדכניים, ולא לפי ההנחות של השנה שעברה.
מטריצת מינימום לשוק הישראלי
לישראלים יש העדפות מכשירים משלהם. לפי נתונים מצטברים מלקוחות המובייל שלנו:
אנדרואיד (8 עד 10 מכשירים):
- Samsung Galaxy S, הדור הנוכחי והקודם (דגמי דגל)
- Samsung Galaxy A5x / A3x, הדור הנוכחי והקודם (דגמי הביניים, פלח האנדרואיד הגדול ביותר בישראל)
- Xiaomi Redmi Note, הדור הנוכחי והקודם (דגמים זולים עם נתח שוק משמעותי)
- Google Pixel, דגם הדגל הנוכחי ודגם ה-a הנוכחי (אנדרואיד נקי, כנקודת ייחוס)
- עוד מכשיר אחד של Oppo או OnePlus
iOS (5 עד 7 מכשירים):
- האייפון Pro והאייפון הבסיסי של הדור הנוכחי
- אייפונים מדור או שניים אחורה
- iPhone SE (המסך הקטן ביותר)
- iPad Pro / Air (אם האפליקציה תומכת בטאבלט)
איזה Framework לבחור
Frameworks נייטיב
| Framework | פלטפורמה | מתאים ל | מגבלות |
|---|
| XCUITest | iOS | אפליקציות iOS נייטיב, בדיקות SwiftUI, האקוסיסטם של Apple | רק iOS, דורש Xcode |
| Espresso | Android | אפליקציות Android נייטיב, הרצה מהירה | רק Android, צמוד מאוד לממשק |
מתי לבחור נייטיב: יש לכם קוד נפרד ל-iOS ול-Android, מהירות הבדיקות קריטית, ואתם צריכים חיבור עמוק לפלטפורמה (התנהגות ברקע, וידג׳טים, הרשאות מערכת).
Frameworks חוצי פלטפורמות
| Framework | פלטפורמות | מתאים ל | מגבלות |
|---|
| Detox | iOS ו-Android | אפליקציות React Native | צריך לבנות את האפליקציה לפני כל הרצה |
| Appium | iOS, Android ו-Web | אפליקציות עם כמה טכנולוגיות, צוותים מעורבים | איטי יותר מ-Frameworks נייטיב, לא יציב אם לא מוגדר נכון |
| Maestro | iOS ו-Android | תהליכי UI פשוטים, הקמה מהירה, בדיקות ב-YAML | מוגבל באינטראקציות מורכבות, אקוסיסטם צעיר |
מתי לבחור חוצה פלטפורמות: יש לכם אפליקציית React Native או Flutter, צוות ה-QA צריך שפה אחת לשתי הפלטפורמות, או שאתם בודקים את אותם תהליכים ב-iOS וב-Android.
מה אנחנו ממליצים
לרוב הצוותים שמתחילים מאפס: Maestro להקמה מהירה ולבדיקות Smoke (עובדים תוך שעות, ולא שבועות), ולצידו Frameworks נייטיב לתהליכים הקריטיים: Espresso לתהליכים ב-Android שרגישים לביצועים, ו-XCUITest להתנהגות שייחודית ל-iOS.
לצוותים בוגרים: Appium עם Page Object Pattern מתוחזק היטב נותן את הגמישות הגבוהה ביותר. ההקמה יקרה יותר, אבל אם משקיעים בארכיטקטורת הבדיקות מההתחלה, התחזוקה לאורך זמן נשארת סבירה.
בדיקות מובייל בתוך ה-CI/CD
CI/CD למובייל קשה יותר מאשר ל-Web. הבנייה לוקחת יותר זמן, צריך לנהל את מכשירי הבדיקה, וההגשה לחנויות מוסיפה עוד שלבים.
מבנה ה-Pipeline
| שלב | מה רץ | משך | תשתית |
|---|
| בדיקת PR | בדיקות יחידה, Lint ובדיקת טיפוסים | פחות מ-3 דקות | שרתי CI רגילים |
| Build | גרסת Debug לשתי הפלטפורמות | 8 עד 15 דקות | שרת macOS (בשביל iOS) |
| בדיקות Smoke | 5 התהליכים המובילים על 3 מכשירים | 10 עד 15 דקות | חוות מכשירים בענן |
| רגרסיה מלאה | כל הבדיקות על המטריצה המלאה | 30 עד 60 דקות | חוות מכשירים בענן |
| לפני שחרור | Smoke, ביצועים ונגישות | 20 דקות | חוות מכשירים בענן |
חוות מכשירים: בענן או אצלכם
בענן (מומלץ לרוב הצוותים):
- BrowserStack (זמינות טובה של מכשירי iOS, אמין)
- Firebase Test Lab (הכיסוי הטוב ביותר ל-Android, באקוסיסטם של Google)
- AWS Device Farm (מתאים לצוותים שכבר עובדים על AWS)
עלות: 100 עד 500 דולר בחודש, לפי מספר ההרצות המקבילות והיקף השימוש.
אצלכם (לצרכים מיוחדים):
- מכשירים פיזיים שמחוברים למחשב הבנייה
- כלים כמו OpenSTF (ל-Android) או ios-deploy
מתי זה הגיוני: כשרגולציה מחייבת לבדוק בתוך הארגון, כשנפח הבדיקות כל כך גבוה שעלות הענן עוברת את מחיר קניית המכשירים, או כשאתם צריכים מכשירים שאין בחוות הענן.
אצלנו יש מעבדה עם יותר מ-130 מכשירים אמיתיים, לפרויקטים שדורשים כיסוי רחב במיוחד. לרוב הלקוחות, חוות ענן עם 15 עד 25 מכשירים מכסה את המטריצה הנדרשת בחלק קטן מעלות התשתית.
באגים שרק מכשיר אמיתי תופס
קריסות בגלל זיכרון
באג שמצאנו באפליקציית איקומרס של לקוח: משתמש שדפדף ביותר מ-50 מוצרים בסשן אחד גרם לאפליקציה לקרוס, במכשירים עם 3 עד 4GB זיכרון. שיטת שמירת התמונות במטמון עבדה מצוין במכשירים עם 8GB ומעלה ובסימולטורים, אבל גמרה את הזיכרון בטלפונים הבינוניים. הבאג פגע ב-35% ממשתמשי האנדרואיד שלהם.
כפתורים קטנים מדי
כפתור שקל ללחוץ עליו ב-iPhone 15 Pro Max, עם מסך של 6.7 אינץ׳, קשה ללחיצה ב-iPhone SE עם מסך של 4.7 אינץ׳. וגודל המסך הוא רק חלק מהסיפור: גם צפיפות הפיקסלים, רגישות המגע והדיוק של האצבע משחקים כאן. הנחיות הממשק של Apple דורשות אזור לחיצה של 44 על 44 נקודות לפחות, וקריטריון גודל המטרה של WCAG 2.1 (רמה AAA) קובע 44 על 44 פיקסלי CSS. אנחנו מוצאים חריגות כאלה באופן קבוע, ובסימולטור הן בלתי נראות.
התנהגות ברשת
בסימולטור החיבור יציב. במכשיר אמיתי האפליקציה פוגשת:
- מעבר מ-WiFi לסלולר באמצע בקשה
- חיבור איטי במעלית
- WiFi עמוס באצטדיון
- אזורים מתים בכיסוי הסלולרי בישראל
מה שהאפליקציה עושה במעברים האלה קובע אם המשתמש יראה מחוון טעינה או מסך שגיאה. בדיקות של תנאי רשת על מכשירים אמיתיים, עם כלים כמו Charles Proxy או Network Link Conditioner, תופסות בעיות שלא רואים בסביבת הפיתוח.
מעבר בין רקע לחזית
משתמש עובר לאפליקציה אחרת באמצע התשלום, חוזר אחרי 5 דקות, והסשן פג. מה קורה? שיחת טלפון קוטעת העלאת קובץ. ההעלאה ממשיכה? מערכת ההפעלה סוגרת את האפליקציה כדי לפנות זיכרון, והמשתמש חוזר. המצב שלו נשמר?
את התרחישים האלה אפשר לבדוק כמו שצריך רק על מכשירים אמיתיים, עם ריבוי משימות אמיתי.
שאלות נפוצות
כמה מכשירים באמת צריך?
לרוב האפליקציות: 15 עד 20 מכשירים שמכסים 90% מהמשתמשים שלכם. אפשר להתחיל ב-5 עד 7 המכשירים המובילים ולהרחיב ככל שהבדיקות מתבגרות. כיסוי מעבר ל-95% מחזיר פחות ופחות, אלא אם אתם בשוק עם פיזור מכשירים קיצוני.
צריך לבדוק כל גרסת iOS?
הגרסה הנוכחית ושתיים לפניה. משתמשי אפל מעדכנים מהר: דף התמיכה של App Store דיווח ביוני 2026 ש-86% מהאייפונים שיצאו בארבע השנים האחרונות רצו על iOS 26. בדיקה על הגרסה הנוכחית ועל שתי הקודמות מכסה כמעט את כל המשתמשים. ודאו את זה מול האנליטיקה שלכם.
בדיקות ב-Flutter שונות מבדיקות ב-React Native?
כן. ל-Flutter יש Framework בדיקות משלו (flutter_test לבדיקות יחידה, integration_test לבדיקות E2E), והוא בשל יותר מכלי הבדיקה של React Native. ב-Flutter התחילו בכלים המובנים, והוסיפו Appium רק אם אתם צריכים סקריפטים משותפים עם ממשק Web שלא כתוב ב-Flutter.
ומה עם PWA?
PWA צריך בדיקות בדפדפני מובייל, ולא בדיקות של אפליקציה. בדקו ב-Chrome ל-Android, ב-Safari ל-iOS, ב-Samsung Internet וב-Firefox ל-Android. ההבדלים בתצוגה בין דפדפני המובייל משמעותיים, בעיקר ב-Safari, שעובד עם WebKit, בזמן שכל הדפדפנים באנדרואיד מבוססים על גרסאות של Chromium. צריכים אסטרטגיית בדיקות מובייל? אנחנו בודקים על יותר מ-130 מכשירים אמיתיים. בואו נדבר.
