בדיקות UI: מתודולוגיות, כלים וטיפים

טלפונים, טאבלטים, מחשבים ניידים, מחשבים שולחניים, פאנלים של IoT, קונסולות משחקים, טלוויזיות, מערכות בידור לרכב, מכשירי חשמל, מדפסות, VR, AR, וכמעט כל מכשיר מודרני המשתמש בקלט/פלט צריך להיבדק מבחינת פונקציונליות לפני יציאתו לשוק והגעתו למשתמש הקצה. לצד התוכנה, עלינו לבדוק גם את ממשק המשתמש. 

למה מתייחסת בדיקת UI? 

בדיקות ממשק משתמש עשוי להתייחס הן גרפי (בדיקות GUI) ו בדיקת ממשק שורת פקודה (CLI Testing). בדיקות GUI מתבצע כאשר יש אלמנטים גרפיים המוצגים על המסך. זה ידוע גם כבדיקת front-end של אפליקציה. בדיקות CLI UI מתבצע כאשר יש לך רק תווים ושורת הפקודה המוצגת על המסך ולא אלמנטים גרפיים.  

בפרספקטיבה רחבה יותר, ניתן גם לציין HMI (ממשק אדם-מכונה), המתייחס למסכי מגע, מקלדות, עכברים, ג'ויסטיקים, בקרי משחק, חיישנים המשמשים לקלט מחוות או תנועה, או חיישני שעון חכם לקליטת מצב בריאותי של המשתמש, ספירת צעדים וכדומה, כמו גם אמצעים פרימיטיביים יותר כמו מתגים למכונות או מכשירים. 

חלק מהמכשירים המודרניים ל-VR (מציאות מדומה) או AR (מציאות רבודה) משתמשים בעיקר ב- CUI (Composite User Interface), המפעיל שני חושים או יותר. 

אנו יכולים לקבוע שבדיקות ממשק משתמש (UI Testing), באופן כללי, יכולות להתבצע על כל מכשיר שמסוגל לנהל קלט משתמש, אפילו מחשבון כיס פשוט. במילים אחרות, ניתן לומר שכל קלט שמשתמש מספק למכשיר כדי לקבל תוצאה כלשהי יכול להיחשב כממשק משתמש. במאמר זה, נתמקד בבדיקות ממשק משתמש של יישומים, שזה המוקד שלנו ב-Spyrosoft. 

אילו רכיבי UI נוכל לבדוק? 

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

Buttons הם האלמנטים הניתנים ללחיצה (אם לא מושבתים), לדוגמה, כפתורי "OK" או "Cancel". יכולים להיות כפתורים רבים עם פונקציות שונות בהתאם לאפליקציה או למערכת ההפעלה. 

תיבות סימון הם האלמנטים המלבניים שבהם ניתן לסמן וי. הם מאפשרים בחירה של מספר אפשרויות. 

תיבות טקסט הם מסגרות מלבניות שבהן ניתן להזין נתונים. אם יש צורך להסתיר את הסיסמה שלך, ניתן להתאים אותן בכיוון זה. אלמנטים דומים הם ה- אזורי טקסט. 

תפריטים נפתחים מאפשרים לנו לבחור מבין אפשרויות שונות. 

קישורים הם הטקסטים הכחולים המסומנים בקו תחתון הנושאים את נתוני ה-"URL". אלה הם רכיבי ה-UI הנפוצים ביותר שאני בטוח שאתם מכירים. 

רכיבי ממשק משתמש נוספים כוללים תמונות, תפריטים, סליידרים, לוחות שנה/בוררי תאריכים וכו'. 

בבדיקות ממשק משתמש, יש לבדוק את האלמנטים הללו (ורבים אחרים) כדי להבטיח שהם פועלים כפי שהגדיר אותם מסמך מפרט התוכנה מלכתחילה. 

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

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

כמה מהפקודות הנפוצות ביותר בכלי אוטומציה הן: Click, Wait, Check ו-Type, אולם הן עשויות להשתנות מכלי לכלי. 

בדיקות ה-UI מורכבות מבדיקת פונקציונליות הליבה, מיקום אלמנטי ה-UI, בדיקת גדלים, צבעים, איות ושימושיות ממשק המשתמש. 

אם אנו רוצים לשקול את החוויה הכוללת של משתמש עם יישום, נוכל לדבר על UX (חוויית משתמש). UX טוב גורם למשתמש לחזור. UX גרוע דוחה את המשתמש בדרך כלשהי, ובתרחיש הגרוע ביותר, היישום שלך עלול לגרום לתוצאות לא רצויות. UX גרוע עשוי אף לגרום לאובדן לקוח או לקבלת דירוגים גרועים עבור המוצר שלך. 

באילו מכשירים עלינו לבדוק את ממשק המשתמש? 

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

טלפונים ניידים וטאבלטים מודרניים משתמשים במסכי מגע עם מקלדות וירטואליות, ואין צורך במקלדת פיזית או עכבר. חלק מהמחשבים הניידים משתמשים גם במסכי מגע. קיימים גם שעונים חכמים, פאנלים גדולים להזמנת אוכל ומגוון עצום של מכשירים אחרים עם פונקציית I/O (קלט/פלט). 

מנקודת המבט של התוכנה, קיימות מערכות הפעלה שונות הזמינות כיום לשימוש. הנפוצות ביותר הן Windows, Linux, iOS ו-Android, אך קיימות גם כאלה המותאמות לתעשיות ספציפיות. 

טכנולוגיות הליבה המשמשות לייצור התוכנה הן .NET, Java, JavaScript, PHP, Python, C, C++, C# וכו'. טכנולוגיות פיתוח האינטרנט הן Angular, React JS, Node JS, Vue JS, JavaScript, Ember JS, Kotlin, Groovy, Laravel וכו'. טכנולוגיות פיתוח המובייל כוללות Android, iOS, React Native, QT, Kotlin, Xamarin, Flutter, PhoneGap, Cordova וכו'. טכנולוגיות פיתוח מסדי נתונים הן PLSQL, MySQL, MSSQL, MongoDB, PostgreSQL, Redis וכו'. ספקי טכנולוגיות מחשוב ענן הם AWS, Azure, GoogleCloud וכו'. 

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

מהם סוגי בדיקות ה-UI? 

בדיקות ממשק משתמש יכולות להיות מדריך, אוטומטי, או שילוב של השניים. בעת בחירת שיטת בדיקה, יש לשקול: 

• העמידות והמורכבות של התוכנה, 
• ההשפעה של תכונות חדשות, 
• כמה בודקי QA זמינים, 
• העדיפויות ורמות הסיכון, 
• כמה סביבות יש לבדוק,
• באילו מכשירים/פלטפורמות/דפדפנים ישתמשו,
• אילו כלים ניתן להשתמש בהם וכדומה.

עבור בדיקות ידניות ואוטומטיות כאחד, תזדקקו מקרי בדיקה. ראשית, עליכם להחליט כיצד לכתוב אותם (Step-by-Step, BDD Gherkin וכו') והיכן הם יאוחסנו. תוכלו להשתמש ב-Excel או בכלים מתמחים יותר, כגון Zephyr Scale בתוך Jira, Microfocus ALM Suite או כל כלי אחר. 

ניתן ללחוץ באופן ידני על ממשק המשתמש או לשקול אוטומציה, בהתאם לכלי המשמש. בדיקות אוטומטיות יכולות להתבצע בדומה לבדיקות ידניות, אך עם אפשרות הקלטה שבה ניתן להפעיל את הפעולות המוקלטות בסיום. בדיקות יכולות להיות מאוטומטיות גם ללא אפשרות הקלטה, הודות לסקריפטים. שפות הסקריפטים המשמשות במקרים כאלה הן JavaScript, TypeScript, VBScript וכדומה. שפות התכנות המשמשות לרוב למטרה זו הן Python, Java, C# ו-Ruby. 

מהן המתודולוגיות לבדיקות UI? 

שיטות הבדיקה הנפוצות ביותר של ממשק משתמש הן בדיקת עשן, בדיקת רגרסיה, בדיקת פונקציונליות ובדיקת קבלה. כדי לייעל את הזמן והמשאבים, נסו לשלב בדיקות R/F (בדיקות רגרסיה/פונקציונליות) לקבלת תוצאה מפורטת יותר. אם נדרש רק סקירה מהירה של התנהגות האפליקציה לפני בדיקות R/F, ניתן להריץ בדיקות עשן. 

הבדיקות צריכות לכסות את הפונקציונליות ממסמך מפרט התוכנה. כלומר, עליך לאמת את רכיבי ה-UI, האיות, שדות הקלט, הפורמטים, הצבעים, העקביות וכו'. כמו כן, מומלץ ליצור מקרי בדיקה חיוביים ושליליים. 

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

כאשר אנו מדברים על ממשק (Interface), איננו יכולים לשכוח להזכיר ממשק מכונה-למכונה הנקרא API (Application Programming Interface). ממשק זה מורכב מבקשות ותגובות. בדיקות API הן נושא שונה לחלוטין, שלא אתמקד בו במאמר זה. 

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

בדיקת מסכי ההתחברות 

דף ההתחברות נראה ברובו זהה בכל האפליקציות. לכן נשתמש בו כדוגמה כדי להסביר כיצד בדיקות ממשק משתמש צריכות להיראות. 

ב בדיקות ממשק משתמש בתחום, עליכם לוודא כי: 

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

בדיקה מסוג זה צריכה להיעשות באופן ידני. 

מתוך ה- בדיקות פונקציונליות מבחינה פרספקטיבית, יש עוד הרבה מה לעשות: 

• כאשר דף ההתחברות נפתח, הסמן אמור להיות ממוקם על תיבת הקלט של שם המשתמש,
• כפתור TAB אמור לאפשר קפיצה בין אלמנטים,
• שדה קלט סיסמה צריך להסתיר את התווים שהוזנו, 
• תיבות סיסמה לא צריכות לאפשר העתקה/הדבקה של הסיסמה 
• בדוק את התרחיש החיובי – משתמש אמור להתחבר עם פרטי התחברות תקפים, לנסות את מקש ה"enter" לאישור 
• בדוק את התרחיש השלילי – המשתמש לא אמור להתחבר עם פרטי התחברות חלקיים/לא תקינים
• הודעת אימות אמורה להופיע כאשר אחד משדות הקלט נותר ריק או שמגבלת התווים חרגה
• בדוק במסמך מפרט התוכנה אם מסך הכניסה אמור לכלול את האפשרות/תיבת הסימון "זכור אותי" 
• סגירת הדפדפן לא צריכה להוציא משתמש מאומת מהמערכת 
• אמת את הפונקציונליות של "שכחתי סיסמה" 
• בדיקת התחברות עם אישורים תקפים לאחר ביצוע שינוי הסיסמה
• בדקו אם אותו משתמש יכול להתחבר במקביל במכשירים/פלטפורמות שונים.

בעת בדיקת עמוד התחברות, ישנם גם סוגי בדיקות רבים אחרים שיש לבצע. חלק מאלה הם בדיקות אבטחה, בדיקות חדירה, בדיקות ביצועים, בדיקות תאימות, בדיקות קבלה של משתמשים (UAT), וכו׳. 

אם דף ההתחברות שלך משתמש בספק אימות התחברות חיצוני, כגון Google, Azure AD או אחרים, אין לבדוק אפליקציות צד שלישי אלו. הן אינן בדומיין שלך, אלא אם כן צוין במפורש אחרת. ייתכן שתהיה בעיה עבור חלק מהכלים להתמודד עם פעולות של רכיב התחברות חיצוני. 

לסיכום 

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

יש התוהים אם ניתן לבצע בדיקות ממשק משתמש באופן אוטומטי לחלוטין. 

אשאיר לך את התשובה.