האנציקלופדיה לבדיקות | קובי יונסי

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

נפתח בפיתוח מונחה התנהגות שבא לתאר מתודולוגיה בהנדסת תוכנה. המונח פורסם לראשונה במאמרו של דן נורת' שפורסם בשנת 2006. מאמר זה  נכתב כתגובה לנושאים שעלו מפיתוח מונחה בדיקות (TDD) כמו :

1. מתי להתחיל לבדוק?
2. מה לבדוק ומה לא לבדוק?
3. כמה בדיקות לבצע בסבב אחד?
4. כיצד לכנות את שמות הבדיקה?
5. כיצד לחקור תרחיש בדיקה שנכשל?

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

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

ביסודה של השיטה מתבצע הסבב הבא:

1. תיאור מדוייק של התנהגות שימוש של לקוח 
2. הגדרת הדרישות מתוך סיפור המשתמש
3. הרצה של בדיקה נכשלת
4. שינוי לקוד ושיפורו
5. הרצה של בדיקה שוב בהצלחה

 עקרונות השיטה:

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

כיצד כותבים בדיקות בשיטה זאת?

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

בכדי להסביר זאת אראה פה דוגמא:

פייסבוק הרשמה לאתר 

Given Nitzan is on Facebook Registration page

When he enters all required registration fields       

Then a Facebook account is Created                

ניתן לראות שיש לנו בכל תסריט בדיקה, 3 אלמנטים:

 (תיאור של ההקשר)        GIVEN

(תיאור של הפעולה)        WHEN

(תיאור של התוצאה)         THEN

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

(תיאור של הקשר)                    GIVEN

(תוספת של הקשר נוסף)              AND

(ארוע / פעולה מתקיימים )        WHEN

(ארוע /פעולה נוספים מתקיימים)  AND

(תוצאה)                                   THEN

(תוצאה נוספת)         AND FURTHER

ובדוגמא שלנו:

Given Nitzan is on Facebook Registration page

When he enters all required registration fields

And he hits "Join Now"

Then a Facebook  account is Created

AND he is directed to the profile creation date

AND his confirmation email is sent

תסריטי בדיקות מונחות התנהגות ומקרי שימוש:

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

במקרה שימוש נשתמש בפורמט:

ובמקרה של הרשמה לאתר פייסבוק:

AS a new user Nitzan 

I can register a new account on the homepage

So that I can access Facebook

את המהלך הזה נוכל לכתוב כבדיקה מונחית התנהגות באופן הבא

Scenario 1: User successfully creates a Facebook Account

Given Nitzan is on Facebook Registration page

When he enters all the required registration information 

And he hits "SIGN UP"

Then his Facebook account is created

AND he is directed to the profile creation page

AND his confirmation email is sent 

במידה ויש לנו מספר תרחישים בפונקציונליות עוקבת ניתן לצרף אותם לתרחיש זה ולייצר שרשרת של בדיקת מערכת מקצה לקצה (End to End Scenario).

לסיכום:

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

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