למה סימולטור לעולם לא יתפוס את הבאג האמיתי

אפליקציה נלווית למוצר חומרה נבדקת אחרת לגמרי מאפליקציה רגילה. אפשר לבדוק מסכים, טפסים ולוגיקה עסקית על סימולטור — אבל בדיקת אפליקציה מול חומרה אמיתית היא הדרך היחידה לגלות את הבאגים שבאמת מגיעים לשטח: צימוד בלוטות' שנכשל בטלפון מסוים, חיבור שנקטע כשהמשתמש מתרחק שני חדרים, עדכון קושחה שנתקע ב-80 אחוז. הבעיות האלה חיות בתפר שבין האפליקציה, מערכת ההפעלה, שבב הרדיו והקושחה — ואף סימולטור לא מדמה את הצירוף הזה.

מעבדת בדיקות: מה צריך שיהיה על השולחן

הבסיס הוא שני מלאים: מלאי מכשירים ומלאי יחידות מוצר.

  • מטריצת מכשירים. כמה מכשירי אנדרואיד מיצרנים שונים וכמה מכשירי iPhone, בדגמים חדשים וישנים. התנהגות הבלוטות' והרשאות הרקע שונות בין יצרנים בצורה מפתיעה.
  • יחידות חומרה בכמה גרסאות. גם גרסת הקושחה האחרונה וגם ישנות יותר — כי בשטח תמיד יהיו מוצרים לא מעודכנים.
  • יחידה עם גישת דיבוג. יחידה אחת שמחוברת למחשב ומדפיסה לוגים מהקושחה, כדי לענות על שאלת הזהב: הבאג באפליקציה או במוצר?

איך התקשורת הזו אמורה לעבוד מלכתחילה — במאמר על איך אפליקציה מתחברת למוצר בבלוטות'.

התרחישים שחייבים להיות בתוכנית הבדיקות

  • צימוד ראשון. עשרות פעמים, במכשירים שונים, כולל מקרי קצה: מוצר כבוי, שני מוצרים זהים בטווח, הרשאות שנדחו. תהליך הצימוד הוא הרושם הראשוני של הלקוח — הרחבנו במאמר על צימוד מוצר לאפליקציה.
  • ניתוקים והתאוששות. יציאה מטווח וחזרה, כיבוי המוצר באמצע פעולה, מעבר האפליקציה לרקע, מצב טיסה. האפליקציה צריכה להתאושש לבד, בלי שהמשתמש יבין שמשהו קרה.
  • עדכון קושחה. התרחיש המסוכן ביותר: ניתוק באמצע עדכון אסור שישאיר מוצר מת. איך זה עובד נכון — במאמר על עדכון קושחת המוצר מהאפליקציה.
  • סוללה חלשה ותנאי קצה. מוצר עם סוללה גוססת, טלפון בחיסכון בסוללה, סביבה רועשת אלחוטית.

כלים שמראים מה באמת קורה באוויר

כשמשהו נכשל, ניחושים לא עוזרים — צריך לראות את התקשורת עצמה. Sniffer לבלוטות' מקליט את התעבורה בין הטלפון למוצר ומראה בדיוק איזו חבילה נשלחה ומה לא נענה; אפליקציות סריקה גנריות מאפשרות לבדוק את שירותי ה-BLE של המוצר בלי האפליקציה שלכם, וכך לבודד את מקור הבעיה; ובצד האפליקציה, מערכת לוגים מסודרת עם רמות חומרה מאפשרת לשחזר תקלה שקרתה אצל בודק לפני שעה. השקעה של כמה מאות דולרים בציוד הזה מחזירה את עצמה בבאג הראשון שהוא פותר.

נקודה שמפתיעה יזמים רבים: האינטגרציה נשברת לא רק כשמעדכנים את האפליקציה, אלא גם כשמעדכנים את הקושחה. כל שינוי בפרוטוקול, בתזמונים או בהתנהגות הפרסום של המוצר יכול לשבור אפליקציה שעבדה מצוין. לכן סבב בדיקות אינטגרציה מקוצר חייב לרוץ על כל שילוב של גרסת אפליקציה וגרסת קושחה שמשוחרר ללקוחות — וטבלת תאימות גרסאות היא מסמך חובה בכל פרויקט כזה.

מה מאטמטים ומה נשאר ידני

בדיקות ממשק ולוגיקה רצות אוטומטית בכל גרסה, ובצד הקושחה קיימות מערכות בדיקה אוטומטיות מול חומרה אמיתית — כפי שמתואר במאמר על בדיקות HIL. את שכבת האינטגרציה המלאה — טלפון אמיתי מול מוצר אמיתי — בודקים בעיקר ידנית לפי תסריטים סדורים, עם דגש על תרחישי הניתוק. חשוב גם לדעת שלספריות קרוס-פלטפורם יש התנהגויות ייחודיות מול חומרה, כמו שהראינו במאמר על React Native עם BLE.

בדיקות בטא: השטח תמיד מפתיע

אחרי שהמעבדה נקייה, מגיעים המשתמשים האמיתיים: קבוצת בטא של עשרות משתמשים עם המוצר בבית, איסוף לוגים ודיווחי קריסות מרחוק, וסבב תיקונים לפני ההשקה. שילוב של מעבדה מסודרת ובטא אמיתית הוא מה שמפריד בין השקה חלקה לגל ביקורות של כוכב אחד. עקרונות הבדיקות המלאים מרוכזים במאמר על בדיקות ואיכות באפליקציה, ועוד על פיתוח אפליקציות למוצרים — באשכול פיתוח אפליקציות. מתכננים מוצר משולב אפליקציה? נשמח לעזור לבנות תוכנית בדיקות שתופסת את הבעיות לפני הלקוחות.

רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.