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