פוסט זה נכתב על ידי ג'יימי סיין, מחברת uTest Inc.
cc by flickr, blakespot
לא קל לבדוק אפליקציות מובייל, אבל ניתן לפשט את התהליך כל עוד יודעים במה להתמקד. למרות שלא ניתן לכסות את כל התחום הזה בפוסט אחד, אנחנו יכולים לכל הפחות להדגיש עבורכם את האזורים הבעייתיים ביותר היום באפליקציות מובייל ואת חמש הטעויות הנפוצות ביותר בתחום שכדאי להימנע מהן.
טעות מס' 1: לא לבדוק על מגוון מכשירים
מטריצת המובייל, הינה ענקית ומגוונת, היא כוללת חומרה, תוכנה, גרסאות, מפעילות סלולאריות, מיקומים, קישוריות, מסכים בגדלים שונים, RAM ועוד, אבל עצם היותה מאיימת אינה תירוץ להתעלם מהצורך בבדיקות על גבי מגוון רחב של מכשירים (Cross-Device Testing) או שימוש בסימולטרים בלבד. אחת הטעויות הגדולות ביותר שמפתח אפליקציות מובייל יכול לעשות הוא לוותר על בדיקת האפליקציה על גבי מגוון מכשירים, מערכות הפעלה ומפעילות סלולאריות באופן ממשי ולא על ידי סימולטרים.
אם כך, מה עליך לכסות בבדיקות? התחל בזיהוי המכשירים וגרסאות ה-OS השכיחות ביותר שהלקוחות הפוטנציאליים שלך משתמשים בהם. הנה כמה עובדות שיעזרו לך להתחיל:
Android – לפי האתר הרשמי של אנדרואיד, מכשירי אנדרואיד זמינים ב-25 מדינות. 23 יצרנים שונים מייצרים מכשירי אנדרואיד ו-63 מפעילות סלולאריות ברחבי העולם תומכות בהם ברשתות שלהן. באופן גלובאלי, יש בערך כ-250 דגמים שונים של מכשירי אנדרואיד אשר מוכרים באופן רשמי ונמצאים בשוק (מבלי לקחת בחשבון גרסאות פלטפורמה וסקינים בהתאמה אישית). בערך כ-20 מתוך המכשירים הללו כוללים מקלדת פיזית, בעוד שהשאר הינם בעלי מסכי מגע.
למרות היותה הגרסא העדכנית ביותר, "Ice Cream Sandwich 4.0.x" הינה רק הפלטפורמה השלישית הנפוצה ביותר ועדיין לא הותאמה לכל המכשירים. "Gingerbread 2.3.x" ממשיכה לשלוט על שוק מכשירי האנדרואיד עם 64% אחוזי שימוש ו-"Froyo 2.2" מגיעה אל המקום השני עם 19%. Ice Cream Sandwich מגיעה בקושי אל המקום השלישי בהפרש של 1% בלבד מ-Eclar 2.1.
iOS – בעוד שאפל לא תומכת בדגמים מרובים, היא מחזיקה שלושה מכשירים שונים תחת אותה פלטפורמת המובייל שלה, ה-iPhone, ה-iPad וה-iPod Touch. ה-iPhone וה-iPad זמינים לשימוש ביותר מ-100 מפעילות סלולאריות ברחבי העולם, כולל 44 מפעילות שונות באירופה בלבד. מכשירי iOS גם מוצעים עם נפחי אחסון שונים: 8, 16, 32, ו-64 ג'יגה בייט. בדיקות על מכשירים בנפחי אחסון שונים הינן חיוניות, גם אם כבר "בדקת על iPhone". ב-iOS יש להתייחס לכל רמת נפח אחסון כאל מכשיר שונה.
לסיכום נקודה זו: מערכות הפעלה, תוכנות שונות הפועלות במקביל על המכשיר, אורך חיי הסוללה, ושלל גורמים נוספים יכולים להשפיע על האופן בו האפליקציה מתפקדת על מכשיר מסוים. אם אתה בודק רק על מכשיר אחד (או רק באמצעות סימולאטורים או הדמיות) מובטח לך שתחמיץ באגים משמעותיים המתרחשים במכשירים שונים. באמצעות בדיקה על מגוון רחב יותר של מכשירי-עולם אמיתי (Real Life Devices) תוכל לכסות שכבה רחבה יותר ממטריצת הבדיקות ולמצוא באגים ספציפיים הקשורים במכשיר והגרסא.
טעות מס' 2: לבדוק מבלי לחשוב על משתמש הקצה
cc by flickr asripa
איך ניתן לוודא שהאפליקציה שלך הגיונית בעיני משתמשי הקצה האמיתיים שלך? הנה ההסבר הלוגי של ג'ייקוב נילסן, המוכר גם כ"מלך חוויית המשתמש":
"הדבר העיקרי שאני ממליץ עליו הוא ללמוד ולהכיר את המשתמשים האמיתיים שלך: הזמן מקבץ של לקוחות מייצגים אל המשרדים שלכם והעבר איתם מחקר חוויית המשתמש (Usability) על התוכנה שלך. במונחים של לקחים מעשיים, יום אחד במעבדה שווה לשנה באולמי ההרצאות של האוניברסיטה. (וזכור, ש'מעבדת חוויית המשתמש' שלך יכולה להיות משרד רגיל או חדר ישיבות, כל עוד אתה סוגר את הדלת)."
במילים אחרות, כאשר מדובר בעיצוב חוויית משתמש מלאה 'כולם' איננו קהל מטרה נכון. זה בלתי אפשרי לעצב מוצר שיהיה ידידותי למשתמש, מושך וקל לשימוש עבור 'כולם'. התוצאה של מאמץ שכזה עלולה פשוט להיות מוצר אשר אינו קוסם לאף אדם במיוחד, וזה בתמורה עלול להפוך את המוצר לכישלון.
ברגע שאתה מזהה ומתאים את האפליקציה לקהל דמוגרפי ממוקד, זה חיוני לבדוק את האפליקציה עם הקהל הדמוגרפי הזה. בדיקות במיקור-המונים (Crowd-Sourcing) הינן דרך טובה לבדוק עבור משתמש הקצה שלך, מכיוון שאתה יכול לבחור טסטרים (Testers) אשר תואמים את הקבוצה הדמוגרפית של משתמשי המטרה שלך. לדוגמא, אם האפליקציה שלך מיועדת לאמהות עם פעוטות, אזי אתה יכול לבחור נשים עם ילדים קטנים שתהיינה בודקות המוצר שלך. בדיקות שכאלו ייתנו לך משוב בעל ערך גבוה יותר מאשר בדיקות עם קבוצת טסטרים גנרית ולא ממוקדת (שאולי אפילו אין להם ילדים בכלל).
טעות מס' 3: להתעלם מהיבטי אבטחת המידע של האפליקציה
אף אחד אף פעם לא משיק בכוונה אפליקציה אשר פגיעה בפני התקפות אבטחת מידע נפוצות, אבל זה קורה באופן קבוע ומדאיג. בנוסף, נושא פרצות אבטחה עלה לאחרונה לכותרות באמצעי התקשורת והמשתמשים הפכו לפחות סובלניים כלפי אפליקציות שאינן מאובטחות. הצעד הראשון בבדיקות אבטחת המידע הוא לוודא שהאפליקציה שלך מטפלת כראוי בנקודות הבאות:
- סודיות: האם האפליקציה שומרת על כך שהמידע הפרטי יישאר פרטי?
- אמינות: האם ניתן לסמוך על המידע שהאפליקציה מציגה ולוודא אותו?
- אותנטיקציה (אימות): האם האפליקציה מאמתת שאתה הוא מי שאתה טוען שאתה?
- הרשאות: האם האפליקציה מגבילה כראוי את ההרשאות שלך?
- זמינות: האם האקר יכול להפיל את האפליקציה?
- Non-Reputation: האם האפליקציה שומרת תיעוד אירועים בשביל אימות מאוחר?
כדאי להיעזר במומחה White Hat לאבטחת מידע (האקר שאינו עוסק בפעילות לא חוקית ו/או זדונית) אשר ינסה להתקיל את המערכת לפחות עם המניפולציות הבסיסיות המאפיינות את הפרצות הנפוצות ביותר באבטחת המוצר, כגון: קבלת גישה למידע בגלל אחסון או תקשורת נתונים לא מאובטחים, פיצוח הצפנות לקויות ופריצת סיסמאות מובנות בתוכנה (HardCoded). אם אפליקציה הינה קלה לפריצה, היא בוודאי תיפרץ.
וודא שהאפליקציה שלך הינה בעלת גישה ל-APIs הנחוצים בלבד. משתמשים יכעסו לגלות שהאפליקציה שלך הינה בעלת גישה למצלמה או לאנשי קשר שלהם אם לאפליקציה אין שום קשר עם הפיצ'רים הללו. לכל הפחות, תוודא שהאפליקציה מתריעה בפני המשתמשים כדי שיעניקו הרשאת גישה למשאבים מבוססי API כאשר האפליקציה מותקנת או מופעלת. גם אם האפליקציה עובדת כראוי והינה מאובטחת, משתמשים לרוב מפרשים גישה בלתי-חיונית ל-API כחדירה לפרטיות וכבעיית אבטחה מטרידה.
טעות מס' 4: תרגום ללא לוקליזציה (התאמת מיקום ותרבות, Localization)
cc by flickr. asrisa
אנו חיים בכלכלה גלובאלית, ולכן צפוי שנראה יותר ויותר אפליקציות הופכות להיות נגישות לשוק הבינלאומי. אם אתה מעוניין שישתמשו באפליקציה שלך ברחבי העולם, אזי חשוב לא רק לתרגם אותה אלא גם להתאים את האפליקציה לתרבות המקומית. בתחרות שערכנו כאן בניוזגיק, הראנו עד כמה טעויות בתרגום ובלוקליזציה יכולות להיות מביכות, ולכן חשוב לחזור על המסר הזה גם בפוסט הנוכחי. אם האפליקציה שלך יוצאת בתפוצה עולמית והיא לא עברה בדיקות לוקליזציה, זוהי טעות שעלולה להכשיל את ההשקה. הנה מספר תחומים מרכזיים שיש להתמקד בהם כאשר מבצעים בדיקות לוקליזציה:
- תוכן: תוכן סטאטי ודינאמי כגון קטלוגים, תוצאות חיפוש, נתונים, metadata ועוד
- תאריכים: האם היום האחרון בשנה הוא 31/12/2012 או 12/31/2012?
- תמיכה במערכי תווים: Différent länguages have ðifferent set∫ θf characters
- מיקוד דואר: במדינות שונות מיקוד מכיל אותיות (חיוני עבור משלוחים)
- מספרי טלפון: לכל שוק יש פורמט שונה של מספרי טלפון
- כיוון: שפות מסוימות נכתבות מימין לשמאל ואחרות משמאל לימין
- המרת מטבע: חשוב במיוחד עבור מסחר אונליין
- חישובי מס: מע"מ, מיסי מכר ועוד משתנים ממדינה למדינה
- התאמה תרבותית: בדקו שנית את התוכן על מנת לוודא שהוא ברור, רלוונטי ולא בטעות מעליב
- התאמה של ממשק המשתמש: וודאו שההבדלים באורכי המילים בין שפת המקור לשפת היעד לא גרמו לשיבושים בממשק
חשוב שבדיקות הלוקליזציה ייעשו על ידי בודקים שהם בני המקום בשוק היעד, המעורים בסטנדרטים והמונחים המקומיים המקובלים ושיהיו מסוגלים 'להציף' את הטעויות והבאגים המביכים ביותר ובכך לוודא שההשקה במדינת היעד תהיה מוצלחת.
טעות מס' 5: פיתוח אפליקציה מבלי לקרוא את ה-UI Guidelines
האנשים שעומדים מאחורי מערכות ההפעלה הראשיות בעולם המובייל הבינו שלא תזיק למפתחים קצת הכוונה בכל הנוגע לאופן בו המשתמשים מצפים שהאפליקציות שלהם ייראו ויפעלו. לפיכך, הופקו ופורסמו ברשת הנחיות רשמיות הזמינות עבור מפתחים. לפני שאתם מתחילים בפיתוח האפליקציה או בהגשתה לאישור עבור השוק המיועד, מומלץ מאוד לעבור על כל ההנחיות הרלוונטיות לאפליקציה שלך אשר זמינות אונליין.
ל-iOS קיימים שני סטים של הנחיות, סקירת הקווים המנחים של האפסטור (The App Store Review Guidelines) והנחיות לממשק המשתמש של מערכת ההפעלה (The iOS Human Interface Guidelines). שניהם, הכרחיים להצלחת אפליקציית iOS. ההנחיות לממשק נועדו על מנת להבטיח שהאפליקציה שלך תואמת את הציפיות של אפל מהפרמטרים הבאים: מאפיינים, עקרונות ממשק המשתמש, אסטרטגיות עיצוב, הנחיות לחוויות משתמש, הנחיות ליצירת אייקונים ותמונות מותאמות, ועוד. הכרת הקווים המנחים של סקירת האפסטור חשובה משום שהם "מספקים כללים ודוגמאות עבור מגוון של נושאי פיתוח, כולל עיצוב ממשק המשתמש, תכונות האפליקציה, תוכן ושימוש בטכנולוגיות ספציפיות". גם אם האפליקציה שלך 'טהורה' ועוברת את כל הבדיקות האפשריות, הרי שבמידה ואיננה עומדת בכל ההנחיות והקווים המנחים הללו שהוצהרו מראש, כל המאמץ היה לחינם. ניתן למצוא את כל ההנחיות הנזכרות לעיל כאן.
המפתחים לאנדרואיד, אשר מכירים באתגרים שגישת הפלטפורמה הפתוחה שלהם יוצרת, החלו לאחרונה להכין יותר דוקומנטציה עבור המפתחים. בין כל המידע החדש הזה, מפתחים יכולים למצוא עקרונות עיצוב; סקירות כלליות של UI; תיעוד אודות פיצ'רים נפוצים של אנדרואיד כגון ערכות נושא (Themes), תצוגות, צבעים, טיפוגרפיה, איקונוגרפיה ועוד מדריכים שונים שהופכים את משימות העיצוב וביצוע הבדיקות על מטריצת האנדרואיד לקלות יותר. בעוד שאפליקציה לא תיפסל על ידי Google Play בגלל שהיא איננה תואמת את ההנחיות, המשתמשים התרגלו למאפיינים מסוימים באפליקציות שלהם. לכן מתן תשומת לב ופעולה לפי התיעוד החינמי הזה יעזור לכם להבטיח שאתם עומדים באותן ציפיות של המשתמשים. ניתן למצוא את המסמכים הללו כאן.
הכרה וידיעה של חמש הטעויות הנפוצות הללו יעזרו לכם ליצור אפליקציית מובייל מעולה אשר תבלוט מעבר לכל המתחרים.
.
פוסט זה בחסות חברת uTest
.
חברת uTest נוסדה בשנת 2007 ומספקת שירותי בדיקות תוכנה בעולם האמיתי עבור אפליקציות Web, Mobile ו-Desktop. כמו כן, uTest עוזרת לחברות לשפר את המוצרים שלהן על ידי שימוש בקהילה של למעלה מ-60,000 בודקים מקצועיים מ-183 מדינות. אלפי חברות, מסטארטאפים בתחילת הדרך ועד תאגידים בינלאומיים כמו גוגל, מייקרוסופט, פייסבוק וזינגה, פונות ל-uTest על מנת להשלים את בדיקות המעבדה שהם עושים ובכדי שנסייע להן להשיק אפליקציות טובות יותר.
השירותים של uTest מקיפים את כל מחזור החיים של פיתוח התוכנה וכוללים בדיקות שמישות (Functional), אבטחת מידע (Security), לוקליזציה (Localization), חוויית המשתמש (Usability) ועומסים (Load). משרדיה הראשיים של uTest ממוקמים בבוסטון עם משרדים נוספים בהרצליה, לונדון, סן-מטאו, סיאטל וניו יורק. uTest גייסה עד כה למעלה מ-37 מיליון דולר ומגדילה בעקביות את נפח הפעילות שלה בשיעור תלת ספרתי מדי שנה. למידע נוסף בקרו באתר שלנו או עקבו אחרי הבלוג שלנו.