BDD מאת דן נורת'

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

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

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

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

ככל שעבר הזמן, BDD התרחב והקיף תמונה רחבה יותר של ניתוח אג'ילי ובדיקות קבלה אוטומטיות.

שמות של מתודות חייבות להיות משפטים

ההארה הראשונה שלי הופיעה בזמן שהתוועדתי לתוכנית-עזר פשוטה לכאורה ששמה agiledox שנכתבה על ידי קולגה שלי בשם כריס סטיבנסון. התוכנית לוקחת test-class של JUNIT ומדפיסה את שמות הפונקציות בצורת משפטים קריאים. למשל test case הנראה כך:

public class CustomerLookupTest extends TestCase {

testFindsCustomerById() {

}

testFailsForDuplicateCustomers() {

}

}

יוצג באמצעות התוכנית בצורה כזאת:

CustomerLookup

– finds customer by id

– fails for duplicate customers

– …

המילה test הושמטה הן משם הclass והן משמות המתודות, כמו כן צורת האותיות הפכה מצורת camel-case (הכוונה לצורה שבה אות גדולה בראשית כל מילה, המתרגם) לטקסט רגיל. זה כל מה שזה עושה, אבל האפקט הוא מדהים.

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

כתיבת משפטים פשוטים שומרת על מתודות הבדיקה ממוקדות

ואז במקרה התחלתי להשתמש בקונבנציה שבה מתחילים מתודת בדיקה במילה אמור (should). התבנית של: class זה אמור (should) לעשות משהו – משמעותה שאתה יכול להגדיר טסט רק לclass  הספציפי הזה. זה שומר עליך ממוקד. אם אתה מוצא את עצמך כותב טסט שלא ניתן להגדיר את שמו באמצעות התבנית הזאת זה כנראה מעיד על כך שההתנהגות הצפויה שייכת למקום אחר.

למשל, כתבתי class שעושה ולידציה על קלט מהמסך. רוב השדות הינם פרטי משתמש רגילים – שם פרטי, שם משפחה וכדו', אבל אז היו שם גם שדות של תאריך לידה וגיל. התחלתי לכתוב את ה – ClientDetailsValidatorTest שהיו בו מתודות כמו למשל: testShouldFailForMissingSurname ו – testShouldFailForMissingTitle..

ואז התחלתי לחשב את הגיל ונכנסתי לעולם של חוקים לוגיים מציקים: מה אם התאריך לידה והגיל שהוזנו אינם תואמים? מה עושים כשהיום זה יום ההולדת? איך מחשבים גיל כשיש לי רק תאריך לידה? התחלתי לכתוב מתודות בדיקה מסורבלות בצורה הולכת וגדילה כדי לתאר התנהגות זאת. עד שהחלטתי להחליף את זה למשהו אחר. זה הוביל אותי לחשוב על class חדש שקראתי לו AgeCalculator שלו היה  AgeCalculatorTest משל עצמו. כל התנהגויות חישובי הגיל הועברו לתוך המחשבון, כך שה – validator היה צריך רק טסט אחד לטובת חישוב הגיל לוודא שהוא פועל נכון עם המחשבון.

אם ה-class עושה יותר מדבר אחד, הייתי לוקח זאת בד"כ כאינדיקציה שאני צריך להוסיף עוד classes לעשות חלק מהעבודה. הגדרתי service חדש בתור interface שמתאר מה הוא עושה והעברתי את השירות כפרמטר ל – constructor של אותו class:

public class ClientDetailsValidator {

private final AgeCalculator ageCalc;

public ClientDetailsValidator(AgeCalculator ageCalc) {

this.ageCalc = ageCalc;

}

}

סגנון זה של שרשור אובייקטים יחד הידוע בתור: dependency injection הוא שימושי במיוחד בשימוש יחד עם mocks.

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

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

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

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

היבט עדין יותר של המילה אמור (should) הופיע כשהשוויתי אותו עם אלטרנטיבות אחרות כמו: will  או shall.  Shouldבמרומז מאתגר אותך עם הנחת היסוד: האם זה אמור להיות כך (should it)? באמת? זה עושה זאת קל יותר להחליט אם הבדיקה נפלה בגלל באג שנמצא או פשוט בגלל שהנחות העבודה הקודמות שלך אודות התנהגות המערכת כבר אינם נכונות.

JBEHAVE מדגישה את ההתנהגות מעבר לבדיקות גרידא

בסוף 2003, החלטתי שהגיע הזמן לקיים "נאה דורש – נאה מקיים" התחלתי לכתוב תחליף לJUNIT שנקרא JBEHAVE, שהסיר כל התייחסות לבדיקות תוכנה והחליף אותו באוצר מילים שנבנה סביב הנושא של וידוא התנהגויות. עשיתי זאת כדי לראות איך framework מסוג זה יכול להתפתח אם אכווין אותו ישירות למנטרות החדשות של פיתוח-מונחה-התנהגות. גם חשבתי שהוא יכול להיות בעל ערך בתור כלי לימודי כדי ללמד TDD ו – BDD ובלי ההסחות של אוצר המילים המבוסס על בדיקות תוכנה.

כדי להגדיר את ההתנהגות של class היפותטי בשם CustomerLookup אני אכתוב behavior class ששמו לדוגמא יהיה CustomerLookupBehavior. הוא יכיל מספר מתודות שיתחילו במילה should. ה- behavior runner ייצור את האובייקט של ה – behavior class ויפעיל את כל ה – behavior methods לפי התור, כמו הדרך ש-JUNIT מבצעת במתודות הבדיקה שלה. בזמן הריצה יודפסו התוצאות לפי ההתקדמות ולבסוף יצא דו"ח סיכום. אבן הדרך הראשונה שלי הייתה להפוך את JBehave בעלת יכולת בדיקה עצמית. רק הוספתי את ההתנהגות שמאפשרת לרוץ בעצמה. הייתי יכול לבצע הגירה של כל הבדיקות של ה-JUNIT ל-תרחישי JBEHAVE ולקבל את אותו משוב מהיר כמו ב-JUNIT.

ההחלטה על ההתנהגות החשובה ביותר הבאה

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

בהינתן שהייתה לי מטרה מודעת להפוך את JBehve להיות self-hosting, גיליתי שהדרך המאוד שימושית להישאר ממוקד הייתה לשאול: מהו הדבר הבא החשוב ביותר שהמערכת איננה מבצעת?

השאלה הזאת מכריחה אותך לזהות את הערך של התכונות שטרם מימשת ולתעדף אותם. היא גם עוזרת לך לנסח את השם של ה- behavior method: המערכת לא מבצעת את X (כש-X הוא התנהגות כלשהיא בעלת משמעות), ו – X היא חשובה, מה שאומר שהמערכת אמורה לדעת לבצע את X; כך שה-behavior method הבאה שלך היא פשוט:

public void shouldDoX() {

// ...

}

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

דרישות הם גם התנהגויות

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

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

 BDD יוצרת שפה שימושית לאנליזה

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

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

 BDD יוצרת שפה שימושית לאנליזה

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

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

בתור [X]

אני רוצה [Y]

כך ש [Z]

כש- Y משמעותו פיצ'ר מסוים, Z הוא הרווח או הערך של אותו פיצ'ר, ו – X הוא האדם (או התפקיד) שירוויח מאותו פיצ'ר. העוצמה היא בכך שזה מכריח אותך לזהות את הערך של מימוש סיפור מיד כשאתה מגדיר אותו. ברגע שאין לסיפור שום ערך עסקי, לעיתים קרובות, יוצא משהו כזה:

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

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

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

בהינתן (given) מצב התחלתי מסוים

בזמן (when) שאירוע מתרחש

אז (then) וודא התוצאות הנדרשות

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

כותרת: לקוח מושך כסף

בתור לקוח

אני מעונין למשוך כסף מהכספומט

כך שלא אצטרך לחכות בתור בבנק

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

באמצעות התבנית של given-when-then שני התרחישים הראשונים עשויים להיכתב כך:

+תרחיש א: החשבון נמצא בעודף+

בהינתן (given) שהחשבון נמצא בעודף

והכרטיס תקף

והמכונה מכילה כסף

בזמן ש(given) הלקוח מבקש מזומנים

אז (then) וודא שהחשבון מחויב

והמזומנים נמשכו

והכרטיס הוחזר

שים לב לשימוש ב-"ו" החיבור (and) לחבר מספר תנאי פתיחה (given) או מספר תוצאות צפויות בדרך טבעית.

+תרחיש ב: החשבון נמצא במשיכת יתר מעל המסגרת+

בהינתן שהחשבון נמצא במשיכת יתר

והכרטיס תקף

בזמן שהלקוח מבקש מזומן

אז וודא שהודעת דחיה מופיעה

ושהכסף אינו נמשך

והכרטיס מוחזר

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

קריטריון הקבלה צריך להיות בר-ביצוע

המרכיבים של התרחיש – תנאי הפתיחה, האירוע והתוצאות – הינם מפורטים דים כדי להיות מיוצגים ישירות בקוד. JBehave מגדיר object model שמאפשר לנו למפות ישירות את מרכיבי הקוד ל- Jave Classes.

עליך לכתוב class שמייצג כל תנאי פתיחה:

public class AccountIsInCredit implements Given { public void setup(World world) { ... } } public class CardIsValid implements Given { public void setup(World world) { ... } }

and one for the event:

public class CustomerRequestsCash implements Event { public void occurIn(World world) { ... } }

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

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

ההווה והעתיד של BDD

לאחר הפסקה קצרה, JBehave חזרה להיות בפיתוח. הליבה די מושלמת ורובוסטית. הצעד הבא הוא אינטגרציה עם IDE פופולריים של Java כמו IntelliJ IDEA ו – Eclipse.

 דייב אסטלס מקדם בצורה אקטיבית את BDD, הבלוג ומאמרים שונים שפרסם עוררו פרץ של פעילות. בצורה בולטת במיוחד – פרויקט ה-rspec למימוש framework של BDD בשפת רובי. אני התחלתי עבודה על rbehave שתהיה מימוש של JBehave בשפת רובי.

מספר שותפים שלי משתמשים בטכניקות BDD במגוון של פרויקטים בעולם האמתי ומצאו את הטכניקות הללו מאוד מוצלחות. ה-JBehave story runner  – החלק שאחראי על אימות קריטריון הקבלה – נמצא בפיתוח אקטיבי.

החזון הוא שיהיה עורך שבו מנתחי מערכת ובודקים יוכלו ללכוד סיפורים בעורך טקסט רגיל שיוכל לחולל stubs לטובת ה- behavior class כל זה בשפה של ה – business domain. BDD  התפתח בעזרתם של הרבה אנשים ואני אסיר תודה לכולם.

הרצאת ליז קיית' – עשר שנות BDD או איך הבנו שטעינו

תקציר

הרצאה נמסרה ב2014 בכנס בנורבגיה , בחלק הראשון והעיקרי של הרצאה זאת קיית' סוקרת את האבולוציה של עולם הBDD בעשר השנים הראשונות 2004 – 2014, בחלק השני קיית' משתפת במה היה צריך להיעשות (מובא תקציר חלק זה)

חלק א' – מה עשינו?

Extreme Programming TimeLine

2003

ליז קיית התחילה את מסעה בBDD כמתכנתת בלי הרבה ניסיון (7 שנים) למזלה היא נכנסה לחברת thoughts works  יחד עם דן וקריס, ושם החלה ההיכרות שלה עם נושאים אלו.

BDD הומצא ע"י דן נורת' בתור דרך להסביר מה זה TDD. הוא לקח טסטים של JUNIT והחליף אותה ב JBEHAVE. העיקרון להחליף את המילה TEST ב SHOULD ולהסביר מה הבדיקה אמורה לעשות, זאת היתה דרך טובה לגרום למפתחים לומר מה הקוד שלהם עושה. הכל עדיין נשאר ברמת בדיקות יחידה וברמת המחלקות (Class).

2004

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

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

הTEMPLATE עדיין לא משתנה. GIVEN-WHEN-THAN

דוגמא לBDD

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

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

לקראת סוף 2014 קיית הצטרפה לToughtWorks. נקודת ציון משמעותית.

דן הציג לקבוצה את JBEHAVE והסביר

ליז היתה שם שבוע בלימוד של TDD באמצעות כתיבת משחק TETRIS

זה היה נשמע לה די הגיוני איך להחליף את הTEST בSHOULD כדי להבין את התפקידים של הקוד יותר טוב. והיא החליפה את הJUNIT בJBEHAVE שהיה לה.

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

כך נכנסתי לעניין ואח"כ ישבנו יחד במשרד והייתי שומעת את השיחות עם כריס מייתס.

2005

יצא מאמר ראשון של DAVE בהקשר של BDD לאחר ששמע מדן

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

דן החזיר לה מייל

דן – אני מעדיף should  כי זה מעודד דיון ושאלות על הנחת העבודה של התוכנה שאתה מפתח.

קייט קיבלה וסברה שהניסוח should מעודד אנשים להקשות על הנחה היסוד המוצעת ולשאול עליה שאלות.

2006

דן מפרסם את המאמר שלו על BDD. ההחלפה של המילה TEST ב – SHOULD מעביר את הקורא מעולם הפתרון לעולם הבעיה.

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

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

2007

JBEHAVE יצא לאור. מה היה בו?

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

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

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

באותו זמן נכתב מוקיטו שהתאים לBDD סטייל.

2008

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

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

 באותו זמן התחיל נושא ה-feature injection שקודם ע"י קריס מייתס וכך החלה התבנית:

הוא אמר שאם אין לך את המטרה הנ"ל – אל תממש את הפיצ'ר.

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

באותם ימים שוחררה הגרסה החדשה של JBEHAVE

2009

דן הגדיר את הBDD

ייקח שעה לדבר על ההגדרות.

Second Generation – כי זה ההמשך של TDD

Outside-in –  מתחילים מזווית הראיה של המשתמש ופנימה למימוש

 Pull-based – עושים רק מה שצריך

Multiple-stakeholder  – יש הרבה אנשים בתמונה מעורבים

Multiple scale – מלמטה (בדיקות יחידה) עד לfeatute injection

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

High automation ו גם well defined output התבררו בהמשך כמקור לטעויות. ועל זה ליז תדבר בשיחת המשך.

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

לא לדאוג איך מממשים אלא לדאוג איך אנחנו רוצים להתשמש בזה.

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

באותו זמן קריס מייתס כתב את ספרו real options – כדאי לשלם כדי לדחות מחויבויות – ועדיף לדחות עד שתוכל להתחייב באמת או לקחת את האופציה שעליה המחויבות הכי נמוכה.

2010

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

JBehave 3.0  משתחרר. לאחר מכן העברתי את זה לאנשים אחרים שימשיכו לפתח את זה.

מאמר של דן – deliberate discovery – דומה קצת ל real options  צריך לקבל את המידע המקיף ביותר על מנת לבצע את ההחלטות הנכונות. ובו הוא מדבר על כך שהלמידה היא האילוץ שלנו.

עפ"י תורת האילוצים אם יש חוליה חלשה היא קובעת את כל הקצב של הייצור. בהקשר של פיתוח החוליה החדשה היא הידע. הבעיה שאנחנו לא יודעים מה שאנחנו לא יודעים. ולכן ההגדרה של BDD כ – well defined output איננה מתאימה. ויש פה אי הבנה של התהליך הנכון של BDD

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

2011

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

בRSPEC השתמשו בחלון LOGIN בתור תרחיש לדוגמא ובcucumber  במחשבון. נדבר על כך בהמשך.

באותם ימים – ליז ודן קיימו שיחה משותפת מבוססת על הבלוגים שלהם – שמה היה deliberate discovery – step away from the tools. בשיחה הם דיברו על הצורך בשיחות ומיגור הלא נודע. ולזרוק דוגמאות לא נכונות כי הם פשוט שגויות.

2012

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

בRSPEC השתמשו בחלון LOGIN בתור תרחיש לדוגמא ובcucumber  במחשבון. נדבר על כך בהמשך.

באותם ימים – ליז ודן קיימו שיחה משותפת מבוססת על הבלוגים שלהם – שמה היה deliberate discovery – step away from the tools. בשיחה הם דיברו על הצורך בשיחות ומיגור הלא נודע. ולזרוק דוגמאות לא נכונות כי הם פשוט שגויות.

2013

דן אומר שלדעתו אין הבדל באמת בין ביטוי מפורש (declarative) למרומז (imperative), הכל תלוי באיזו רמת אבסטרקציה משתמשים ועם מי מדברים

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

פוסט בשם "capability based planning" המוטיבציה לדעת מהם הדברים שאינני עושה בצורה נכונה

2014

קיית' כתבה שני פוסטים בנושא

Bdd for legacy systems

Bdd for Ops

וההגדרה העדכנית  האולטימטיבית לBDD –

אם התוכנה לא משנה – או שBDD מוטעה או שאתה מבצע זאת לא נכון

אבל האמת שכולם עושים זאת לא נכון וכמו שדן נורס חוזר ואומר

מה היינו צריכים לעשות – חלק ב'(תקציר)

הדברים הבאים אינם רק לגבי BDD אלא לגבי פיתוח תוכנה באופן כללי

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

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

ואם משקיעים יותר ויותר זמן חוזרים לWATERFALL – והעובדה היא שתמיד מתגלים דברים תוך כדי.

ארצה לשוחח על תשתית שמטרתה שיחה על גילוי הלא ידוע/וודאי

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

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

ניתוח של סוג הפרויקט: מסובך, קאוטי, טריוויאלי, וX

BDD זאת גישה להציף את הדברים שאינם ידועים. BDD  מיותר במקרים שהדברים ברורים לכולם (LOGIN) אא"כ מסתתרת שם מורכבות. ושם גם נמצא הדבר שעושה את ההבדל.

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

אסלק הלסוי – מיפוי דוגמאות

מתוך קיוקפסט 2018-לונדון

תקציר

על המרצה: אסלק הינו אחד מדמויות המפתח היום בעולם ה-BDD, והינו מייסד שותף של כלי ה-BDD המוביל כיום CUCUMBER, למיסוד תהליך BDD בעולם הJS. אסלק מעביר הרצאות שונות בנושא, הרצאותיו רהוטות ובהירות.

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

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

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

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

סיכום ההרצאה

חלק ראשון – תיאור הבעיה

רואים שתרחיש זה נכתב ע"י מישהו שנזכר ברגע האחרון בכל מיני דברים

על ידי מישהו שהוא בודק ידני

המון המון פרטים טכניים: טבלאות גדולות, אלמנטי תצוגה, מידע לא ברור ID/XML/JSON/CSS

מידע לא רציף ומבולבל, לא קוהרנטי

בודק התוכנה מגיב:

הבודק מבין שיש פה בעיית תקשורת כי ה-PM לא יבין את התרחיש אבל זה הדרך היחידה שלו לגרום לבדיקה לעבור.

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

הPM אומר: לא מכין מה אומר הגרקין הזה.

לסיכום:

זה מה שקורה כשהגרקין נכתב לאחר שכבר המערכת בנויה והוא כבר מבוסס על הUI הקיים

חלק שני – ההבנה המשותפת והדרך להגיע אליה

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

בסוף, המטרה היא להגיע להבנה משותפת:

הבעיה העיקרית היא שיש הרבה מעברי מידע בין השותפים:

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

הפתרון הוא:

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

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

אך שוב ניתקל בבעיה:

בסופו של יום מקיימים שיחה של שלושת האמיגוס, אבל לא יודעים כ"כ איך להתחיל בשיחה

חסר להם מבנה מסודר שהם ראו ולמדו מאחרים שעשו זאת בעבר.

לשם כך קיימת הטכניקה של מיפוי דוגמאות או יש המכנים זאת discovery workshop

חלק שלישי- סדנת מיפוי דוגמאות

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

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

להלן תוצר הסדנה:

סיכום

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

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

Extreme Programming, 20 years later הרצאתו של קנת בק

Extreme Programming – מסע בזמן

בהרצאה זאת קנת בק סוקר היסטורית על ציר הזמן את ההתפתחות של עולם הExPROG

מבחינתו זה התחיל ב1980 כשהיה סטודנט באוני' של אורגון כשהיה בן 18, והמרצה אמר להם שהעתיד הוא תכנות מבני (Structured programing)

ולו זה היה כבר אז נשמע לא קביל ו"משעמם".

במהלך שנות השמונים קנת התחיל לעבוד למזלו בשפת small talk

שהייתה חוויה לימודית וחברתית

בשנות התשעים המוקדמות  פנה לייעוץ עצמאי ונכנס לבדיקות אוטומטיות

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

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

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

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

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

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

קנת הציע למנהלת של קרייזר סו משהו לעשות משהו אחר והיא מינתה אותו כאחראי על התוכנית.

במהלך פגישות ההיכרות עם הנהלת הפרויקט למעשה הוא גיבש בצורה מאולתרת את העקרונות של Extreme programming:

  1. מימוש איטרטיבי של סיפורי משתמש לקבלת פידבק מהלקוחות
  2. הגדרת קריטריוני קבלה של כל סיפור וסיפור
  3. עבודה בזוגות – pair programming

קנת אומר שהשראה מגיעה מהכנות מוקדמות יחד עם פאניקה J.

זאת היתה הלידה של XP: פיתוח תוך כדי בדיקה מתמדת של תוצאות הפיתוח

נקודת ציון נוספת בהבנה של תהליכי פיתוח היתה הפיתוח של JUNIT

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

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

באותם ימים, התגורר קנת בשוייץ, ובמהלך נסיעות ברכבת על קו ציריך – מינכן כתב את הטיוטה לספרו Extreme programming explained

שהפך להיות מאוד פופולרי שנתיים לאחמ"כ בתחילת שנות ה2000 קראתי את הספר: Toyota Production System וחוויתי מעין הארה.

דברים שנכתבו בספר כמו משל הסלעים והגובה פני המים:

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

בהמשך קנת השתתף בניסוח המניפסט AGILE.

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

ב2011 קנת הצטרף לפייסבוק, בהם הוא אימן מתכנתים במשך 4.5 שנים.

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

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

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

מפת הלקחים של קנת מXP

דברים שהיה עושה שוב

  1. ניסיון – הספר נכתב מניסיון אמיתי של מפתחים. מפתחים יותר אפקטיבים היו משתמשים ברעיונות אלו.
  2. שילוב של ערכים, עקרונות ופרקטיקות – עיסוק רק בפרקטיקה מוביל לתופעת הכלב הנועץ מבט [אם מכוונים אצבע מול עיני הכלב הוא לא מצליח להסיר את המבט מהאצבע לא משנה אילו דברים מעניינים קורים סביבו] כך מי שקולט רק את הפרקטיקה לא מצליח להתרומם ולהבין את העקרונות והערכים שעומדים בבסיס הפרקטיקות.
  3. אידיאליזם – לקבוע את המטרה הרצויה ולחתור אליה ולא להתקע רק בצעדים הראשונים.

דברים שהיה עושה אחרת

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

דברים שהוא עוסק בהם היום

בעיקר לאור הניסיון בפייסבוק:

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

שאלות מהקהל

ש. אילו שינויים תרבותיים למדת בפייסבוק?

ת. הפוסטר במשרד שלי אומר הכל – "אין שום דבר בפייסבוק שהוא הבעיה של מישהו אחר". בתקופתו הארגון צמח מ2000 איש ל13 אלף איש. ובארגון שכל שינוי משליך על 1.5 מיליארד משתמשים אי אפשר להשליך את הבעיה על מישהו אחר.

להוציא את התמצית מהתרחישים

הרצאתו של ג'ורג' דינוידי (George Dinwiddie)

תקציר מהיוטיוב (google translate)

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

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

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

סיכום ההרצאה

תרחישים יכולים להיות עמוסים בפרטים שאינם קריטיים

בבסיס, צריך לעסוק יותר ב"מה" (DECLARATIVE) ופחות ב"איך" (IMPERATIVE)

אך גם צריך לעסוק ב"נחוץ" (ESSENTIAL) ופחות ב"מיקרי" (INCIDENTAL)

המטרה היא לזהות ולזקק את כוונת כותב התרחיש גם לאחר זמן מה ולאחר שינויים שאינם מהותיים (למשל שינויי GUI)

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

המטרה: שביל האמצע.

דוגמא ראשונה – תרחיש לקבלת הנחה לאחר קניית מספר ספרים.

דוגמא שניה (יותר מובנת לטעמי) – תרחיש להגדרת זמן לטיימר של מטבח (לא כ"כ נפוץ בארץ הקודש)

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

כללי אצבע:

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

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

דוגמא שלישית – החזרי ארוחות לעובד

  • ניתן לראות איך הפרטים החסרים בתמונה קריטיים להבנת התרחיש – קיימים כל מיני חוקים מאחורי הקלעים
  • את החוקים צריך לשים על השולחן בתור פיצ'ר מוקדם – אחרת נצרכים לעשות Reverse Engineering
  • לא נכון לפזר את המגבלות הספיציפיות (עד 15 דולר לא.בוקר וכדו') בתוך התרחישים כי אז צריך כל פעם צריך ל"חפש את ההבדלים", הנכון לשים אותם מקובצים יחד ב-backround

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

שקף סיכום של ההרצאה

השמטת פרטים לא חשובים

הפשטה של פרטים מקריים

לציין בצורה חד משמעית פרטים חשובים

להפריד תרחישים שמבטאים כללים שונים

נתינת שמות משמעותיים לתרחישים

זיהוי תרחישים חסרים

תיעוד החוקים במקום נפרד

כתיבת הרקע המשותף לכל התרחישים

הרחבת היריעה באמצעות טבלת פרמוטציות