שיטות שונות לבדיקה

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

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

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

ניתן דוגמא כללית להמחשה.

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

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

White Box Testing - בדיקות קופסא לבנה

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

בפועל, מדובר בבדיקות העוסקות ב- Source Code עצמו. הטסטים יכולים להיות Unit Test של פיסת קוד או Test Application שתבדוק את התוכנה דרך ה- API שלה. מטרת הבדיקות הן בעיקר לבדוק את הערכים המוחזרים מפונקציות וביכולת של הקוד לעמוד בסטנדרטים שהוא מציב לעצמו ביציבות ואמינות.

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

הבדיקות יכללו מניפולציות שונות על הקוד שלרוב יכללו שינוי הערכים הנשלחים לפונקציות ובדיקת הערכים החוזרים מהן תוך כדי שימוש ב- API של התוכנית.

סביר שהבדיקות יהיו אוטומאטיות באופן טבעי כיון שמדובר על תקשורת מול קוד.

Black Box Testing - בדיקות קופסא שחורה

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

בפועל, מדובר בבדיקות שנעשות על המוצר הסופי, לרוב ברמת ה- End User כך שהגישה אל המרכיבים הפנימיים של המוצר מוגבלת. 

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

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

המניפולציות האפשריות הן מוגבלות דרך הממשק שפתוח לטסטר ולכן הבדיקות לרוב יכללו שימוש ב-GUI המשתמש.

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

Grey Box Testing - בדיקות קופסא אפורה

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

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

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

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

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

לסיכום

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

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

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

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

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