מהו מודל?
מודל הוא ייצוג מופשט ושימושי של מערכת מורכבת. ״מופשט״, כי הוא כולל רק את הפרטים המעניינים במערכת המתוארת. ו-״שימושי״, כי ניתן לבצע עליו פעולות בעזרת מחשב. בעולם הבדיקות, מודלים מסייעים בהבנת התנהגות המערכת הנדרשת, ואת הקשרים והאינטראקציות בין רכיביה השונים. תיאור זה צריך להיות פשוט מספיק בשביל שניתן יהיה לעבוד ולהבין אותו, ועם זאת מפורט מספיק על מנת שהתוצרים המופקים ממנו יהיו שימושיים.
לדוגמא, ניתן לבנות מודל המתאר איך המערכת אמורה להתנהג כאשר משתמשים מבצעים בה פעולות מסוימות. ממודל כזה ניתן להפיק ייצוג ויזואלי פשוט של ההתנהגות הרצויה של מערכת תחת בדיקה, וכך לעזור לבודקים להבין, לנתח ולחזות את התנהגותה של המערכת. בנוסף, אפשר לייצר ממנו תוכנית בדיקות, ואפילו לבדוק אם יש התנגשות בין הדרישות השונות.
כדי להמחיש טוב יותר את הקונספט של מודלים בבדיקות תוכנה, נתייחס לדוגמא המוכרת לכולנו מחיי היום יום - התמצאות בעיר. דמיינו שמישהו עוצר אתכם ברחוב ושואל איך מגיעים לתחנת הרכבת הקרובה. ישנן שתי גישות אפשריות להכווין אותו לשם:
גישה ראשונה - אתם מתארים לו מהם הצעדים שעליו לבצע על מנת להגיע לשם (המשך ישר במשך 200 מ׳, פנה שמאלה בכיכר, תמשיך עוד 500 מ׳, פנה ימינה וכו׳..).
גישה זו מייצגת גישה תכנותית, היא מתמקדת בריצה אחת, ברשימת הוראות ספציפית. גישה זו משקפת את שיטת הבדיקות הרווחת היום - בדיקות מבוססות תסריטים (scenario-based).
גישה שנייה - אתם מראים לו מפה של רחובות העיר ומסמנים לו את מיקומו הנוכחי ואת מיקום תחנת הרכבת. המפה מייצגת מודל המספק מבט כולל על רחובות העיר, הצמתים ונקודות הציון השונות. היא מאפשרת לכל אחד לראות את כל המסלולים האפשריים, לתכנן את המסלול שלו, לחקור מסלולים אלטרנטיביים (ואולי אפילו תחנות רכבת אלטרנטיביות) ולהבין טוב יותר את מבנה העיר הכולל.
גישה זו משקפת את שיטת בדיקות מבוססות מודל (model-based testing ובראשי תיבות MBT).
שיטת MBT מתבססת על בניית מודל בדיקות - מעין ״מפה״ של כל הבדיקות האפשריות של המערכת. באמצעות בחינת מסלולים שונים בשילובים שונים, נוכל להבין את המערכת בצורה רחבה וטובה יותר ולבדוק יותר תסריטים, כולל כאלו שאולי לא היינו מודעים אליהם אפילו ללא המודל. אבל, לא תמיד יש לנו מפה שנוכל להעביר, וגם כשיש, כנראה שיש גם הרבה מסלולים לבחור. ואולי בכלל רחובות העיר עברו בנייה אינטנסיבית לאחרונה והמפה כבר אינה מעודכנת?
ניקח את הדוגמא צעד קדימה, תארו לעצמכם אפליקציית ניווט, כזו שאנו מתארים לה את ההנחיות שלנו והיא בוחרת לנו מסלול באופן אוטומטי (למשל, Waze). אם נזין לאפליקציה את ההנחיות הבאות: ״היעד הוא תחנת רכבת, נרצה להגיע ליעד בדרך הכי קצרה, שאינה כוללת תשלומי אגרה״. האפליקציה תבנה לנו מסלולים פוטנציאליים שונים ותייצר לנו אותם על המפה כדי שנוכל לבחור. ניתן גם לעדכן את המפה, למשל כאשר רחוב נחסם או כאשר דרך חדשה נפתחת. במקרה כזה האפליקציה יכולה לייצר מסלולים חדשים וטובים יותר עבור אותה דרישה (למשל, כאשר פותחים תחנת רכבת קרובה יותר או כאשר רחוב חסום נפתח לתנועה).
כלי המידול הוא מעיין אפליקציית ניווט בין כל הבדיקות האפשריות של המערכת (כן, יכולות להיות הרבה כאלו). ככל שאנו מתקדמים בבנייה והבנה של המערכת הנבדקת, אנו מוסיפים למודל הנחיות ודרישות. המודל, מצידו, מעדכן את ״מפת הבדיקות״ האפשריות, ויודע לייצר לנו באופן אוטומטי תסריטי בדיקה חדשים, המייצגים את המסלולים החדשים שנוצרו והשילובים ביניהם.
בעולם ה-QA אנחנו בדרך כלל לא מעוניינים בבדיקה אחת, אלא בחבילת בדיקות המכסה חלקים במערכת הנבדקת. אם נמתח את הדוגמא קצת, זה יהיה כמו לבקש מאפליקציית הניווט שלנו לייצר ״חבילת מסלולים, העוברים בתחנת רכבת, תחנת אוטובוס, ועמדות טעינה לרכב חשמלי, כאשר חלק מהמסלולים משתמשים בכבישי אגרה וחלק לא״. אבל זה באמת כבר קצת למתוח את הדוגמא יותר מדי. בואו נחזור לעולם הבדיקות.
איך מודלי בדיקת תוכנה משפרים את התקשורת בארגון?
מודלים משמשים כשפה משותפת בין המחלקות השונות המעורבות בתהליך פיתוח התוכנה. זאת משום שהם מאפשרים ייצוג ויזואלי של התהליכים וההתנהגויות השונות של המערכת. בגדול, מודלים לוקחים דרישות מערכת ומתארים אותן בשרטוטים שניתן להבין בקלות גם ללא ידע בקוד או במידול.
למשל - וכולנו מכירים זאת היטב - לא תמיד אנחנו מבינים בדיוק למה התכוון איש הפרודקט בדרישה א׳ או ב׳. האם איש הביזנס כיסה את כל המקרים החשובים במסמך הדרישות שלו? האם יש בכלל מסמך דרישות או שפתחו issue ב-Jira עם כותרת בלבד? וכמובן, ייתכן שבשלב מאוחר יותר מגלים שיש התנגשות בין דרישות מסוימות ואחרות לבין הפיתוח ואולי אפילו גם לדרישת הלקוח.
מודלים עוזרים לנו להתמודד עם אתגרים אלו בכך שהם מספקים לנו ״תמונת-על״ של המערכת. תמונה זו ניתנת לייצוג על ידי שרטוטים שכל הגורמים המעורבים בפיתוח יודעים לקרוא. כך כל הגורמים מבינים בדיוק את התנהגות המערכת המתוכננת, ויכולים להצביע על שגיאות ואי התאמות מול התנהגות המערכת הרצויה, כפי שהלקוח או מנהלי המוצר מבינים אותה.
במילים אחרות, המודל הוא נקודת ייחוס מרכזית בארגון ליצירת מקרי בדיקה, להרצה, או הערכה של המערכת. בצורה זו, כל הגורמים בארגון מבינים טוב יותר את מבנה המערכת, ואיך כל אחד מצפה שהיא תתנהג. השימוש במודל אחד מבטיח שכולם ״על אותו הגל״, מדברים באותה שפה למען מטרה משותפת - מוצרי תוכנה באיכות גבוהה.
אם כן, אנו מתחילים להבין את חשיבותו ואת כוחו של המודל בעולמות של תהליכי פיתוח תוכנה.
מודלים מפשטים את מורכבות המערכת על ידי אבסטרקציה של הפיצ'רים וההתנהגויות ההכרחיות, והם בעלי יכולת
אדפטציה לאספקטים השונים של דרישות המערכת.
מה מודל צריך להכיל?
לכל מערכת יש את הטבע שלה והדרישות שלה. באופן כללי, נרצה שהמודל ידע ללכוד:
· התנהגויות פונקציונליות; ייצוג של רצף הפעולות, התלויות והמעברים בתוך המערכת.
· ניהול של שגיאות וחריגות. סנכרון בין רכיבים ומשאבים שונים וניהול של race conditions.
· הגבלות של משאבים שונים במערכת ושינויים ב-business flow.
· על המודל לתאר את מגוון התוצאות התקינות.
· התנהגות מול העולם החיצון; לקוח, פרוטוקולים, זרמי דאטה, הודעות..
מהי רמת הפירוט הנדרשת?
נשאלת השאלה כמה מפורטים עלינו להיות בתיאור המודל על מנת שהוא יהיה יעיל. מסתבר שלא חייבים להיות מאד מפורטים. ניתן להתחיל מסט התחלתי מצומצם של דרישות הכרחיות ולהוסיף פירוט בהדרגה ככל שנדע טוב יותר מהם צרכי המערכת ואילוצי הבדיקה. בנוסף, רמת הפירוט של המודל לא חייבת להיות אחידה. למשל, אם אנחנו רוצים לבדוק מסך ספציפי במערכת, מודל הבדיקות יתאר את המסך
בפירוט, אבל את הדרך בה המשתמש מגיע אל המסך הזה ברמה המינימלית ההכרחית.
אז מה זה בעצם MBT?
MBT היא שיטת בדיקות בה הטסטים נוצרים בצורה אוטומטית מתוך מודל המתאר את האספקטים הפונקציונליים של המערכת הנבדקת (ה-SUT).
השוני המרכזי בין שיטות הבדיקה המסורתיות לבין אלו המבוססות מודל, נמצא בשלבי התכנון והיצירה של תסריטי בדיקה. אם עד עכשיו תכנון וביצוע של מקרי הבדיקה התבצע באופן ידני, על בסיס ניתוח של מסמכי דרישות, כעת יצירתם נעשית באופן אוטומטי, מתוך המודל.
כיוון שהמודל מייצג את דרישות המערכת העדכניות, הטסטים הנוצרים ממנו תמיד משקפים דרישות אלו. כך נוצר מצב בו הטסטים תמיד מעודכנים. בנוסף, ניתן למדוד כיסוי פונקציונלי של חבילות בדיקה בצורה מדויקת, וניתן להכווין את ייצור חבילות הבדיקה כך שיכסו פיצ׳רים אותם אנו מעוניינים לבדוק.
למשל, נניח כי אנו רוצים לבדוק אפליקציה בנקאית. ישנם סוגים שונים של משתמשים (נוער, מבוגרים, פנסיונרים).
סוגים שונים של חשבונות (עסקי, פרטי, השקעות) ומנגנוני הזדהות שונים (זיהוי פנים, טביעת אצבע, סיסמא חד פעמית, וסיסמא קבועה). בשביל לסבך עוד טיפה - ולבטל את האופציה הפשוטה של מכפלה קרטזית בין האופציות האלו - נניח שחשבון עסקי יכול להיות רק למבוגר (לא לנוער ולא לפנסיונרים), שפנסיונרים לא עובדים עם סיסמא חד פעמית, ושחשבון עסקי דורש הזדהות ביומטרית כלשהי (זיהוי פנים או טביעת אצבע). המודל יכיל את כל השילובים האפשריים של הפרמטרים לעיל, ואת ההתנהגויות הרצויות של המערכת המוכתבות על ידי פרמטרים אלו (לדוגמא - בהזדהות עם סיסמא קבועה צריך להכניס שם משתמש וסיסמא, כאשר נוער נכנס למסך הראשי מציעים לו כרטיסים לטיילור סוויפט, וכד׳).
עכשיו, כשהמודל מוכן, ניתן לייצר חבילות בדיקה שונות. חבילת בדיקות מהירה תכלול טסטים בהם כל ערכי הפרמטרים מופיעים, אבל לא כל השילובים שלהם (נניח, יהיה לנו משתמש בוגר עם חשבון השקעות, אבל לא משתמש בוגר עם חשבון פרטי). לפני שחרור גרסה, נריץ טסטים מלאים יותר, בהתאם למגבלות הזמן והתקציב. אם בוצע שינוי לחשבונות נוער בלבד, נפיק חבילת בדיקות בה סוג המשתמש הוא תמיד ״נוער״, ושאר הפרמטרים משתנים. יצירת חבילת בדיקות כזו אורכת לרוב פחות מדקה[1].
אחד היתרונות הבולטים של מידול הוא הסיוע בזיהוי של באגים, טעויות או התנגשויות כבר בשלב כתיבת הדרישות במחזורי הפיתוח. כולם מדברים היום על Shift Left, פרדיגמת הזזת הבדיקות לשלב הפיתוח, המאפשרת זיהוי בעיות ופתירתן בשלב מוקדם יחסית של סבב הפיתוח.
מאחר והמודל נבנה ישירות מתוך הדרישות, הבודקים יכולים לזהות כשלים כמו הבנות שגויות, חוסר עקביות, או דרישות חסרות בשלב הראשוני ביותר של סבב הפיתוח - שלב האפיון והגדרת הדרישות העסקיות.
לדוגמא, נניח כי אנו בודקים שירות ענן של בנק המאפשר ללקוחות לקבל את המאזן הנוכחי בחשבונם. נניח רגע כי התקשורת לשירות היא דרך REST API. למערכת כזו ישנן מספר דרישות. ביניהן מופיעות שתי הדרישות הבאות:
1. אם המשתמש שלח מספר חשבון לא קיים, יש להחזיר הודעת שגיאה 404 NOT FOUND
2. אם המשתמש שלח הזדהות לא נכונה, יש להחזיר הודעת שגיאה 401 UNAUTHORIZED
אנשי ה-QA מוסיפים את שתי הדרישות למודל, יחד עם שאר הדרישות. כאשר המודל יבחן את מרחב הבדיקות האפשרי, הוא ימצא מקרה בו המשתמש שולח בקשה עם מספר חשבון לא קיים וגם עם הזדהות לא נכונה. במקרה כזה, המודל יצפה לתשובה שהיא גם 404 (בגלל דרישה 1) וגם 401 (בגלל דרישה 2). זה כמובן בלתי אפשרי, והמודל יציג שגיאה מתאימה, המצביעה על סתירה בין הדרישות. אנשי ה-QA יקחו את העניין לצוות האפיון שיעדכן את הדרישות.
אגב - בדוגמא לעיל הטסטים בכלל לא נגעו במערכת הנבדקת. בדיקות מהסוג הזה יכולות להתבצע לפני שאנשי הפיתוח כתבו אפילו שורת קוד אחת!
שימוש ב-MBT מאפשר לתהליך ה- QA להתחיל כבר בשלב הדרישות. כמובן, שרק מעצם קבלת פידבק בשלב מוקדם זה אנו מאפשרים העברת דרישות הדוקות ואיכותיות יותר לפיתוח. ברור כי דרישות טובות ומסודרות חוסכות משמעותית בעלויות ובזמן הפיתוח, וב-time to market.
כך, שימוש ב-MBT מאפשר לשפר את איכות המוצר, ולהוריד את זמן ואת עלויות הפיתוח - שלושת ה-KPIs לפיהם, על פי רוב, צוותי פיתוח נבחנים.
MBT, אוטומציה, ובדיקות ידניות
בדיקת דרישות היא יכולת ייחודית לגישת ה-MBT, אבל כמובן שגם ניתן לייצר בעזרתה בדיקות רגילות. ייצור בדיקות כאלו יתבצע בדרך כלל על ידי הוספת הוראות ביצוע למודל קיים. למשל, נניח שיש לנו מודל המתאר מסע לקוח באתר בנק. המודל הבסיסי יתאר תהליך בסגנון ״המשתמש פותח את מסך הזדהות, משם עובר לעמוד הראשי, ומשם עובר למסך מצב חשבון״. על מנת לאפשר אוטומציה ישירות מהמודל, נוכל להוסיף קוד סלניום שירוץ בכל מסך. אם נרצה לעבור ליצירת ספר בדיקות ידני, נחליף את שכבת ההוראות של הסלניום בשכבה אחרת, המפרטת צעדים באופן המתאים לבודק ידני. כאשר הבנק יציג אפליקציה שמקבילה לאתר, נוכל להשתמש במודל הבסיסי שוב, אבל הפעם להחליף את שכבת הוראות הסלניום בשכבה עם הוראות של Appium.
בשיטות אלו ניתן ליצור חבילות חדשות של בדיקות אוטומציה, או חבילות של בדיקות ידניות. אבל מה עושה מי שכבר יש לו תשתיות בדיקה עשירות? לא חבל לזרוק?
החדשות הטובות הן שלא צריך לזרוק תשתיות קיימות - ניתן להשתמש ב-MBT על מנת לייצר תסריטי בדיקה המתבססים על תשתיות אלו. כך, במקום לתרגם חבילת בדיקות לספר בדיקות ידני, ניתן לתרגם אותה לקבצים ב-Python או Java/JUnit, או לכל פורמט מבוסס טקסט אחר. כולל, כמובן, קבצי JSON ו-XML. שילוב כזה מאפשר לצוות ה-QA גמישות רבה בבניית המודל, כיוון שהם יכולים להחליט אילו פעולות צריכות להיות מפורטות כחלק מהמודל עצמו, ואילו פעולות יכולות להיכנס ל-״קופסאות השחורות״ של ספריית האוטומציה. בנוסף, גישה זו מאפשרת ניצול מיטבי של ספריית האוטומציה, כיוון שייצור תסריטי בדיקה המתבססים עליה מתבצעת באופן אוטומטי.
פיתוח אג׳ילי מאפשר - מעודד אפילו - שינויים תכופים במערכת המפותחת, על מנת להתאים אותה לצרכים המשתנים של הלקוח. שינויים אלו יוצרים דילמה מתמדת בקרב צוותי ה- R&D: אבטחת איכות לעומת תחזוקה. אם נכתוב הרבה טסטים נקבל כיסוי בדיקות יסודי שיבטיח איכות גבוהה. מצד שני, כמות גדולה של טסטים פוגעת באג׳יליות של הצוות, כיוון שכל שינוי בתוכנה דורש בדיקה, עדכון, וכתיבה מחדש של כל הטסטים הקיימים - פעולות הדורשות זמן ועבודה רבה. כאשר מדובר בטסטים אוטומטיים הבעיה מתחדדת. כמובן, אם אנו בוחרים לקצץ בכמות הבדיקות בעיית התחזוקה נפתרת, אולם אנו מסתכנים בפגיעה באיכות המוצר עקב כיסוי בדיקות נמוך.
כך למעשה נולדו שיטות הפירמידה, לפיהן בדיקות מסוג E2E, שהן הבדיקות הכי חשובות, נמצאות בראש הפירמידה ואותן מבצעים הכי מעט.
עם MBT, ברגע שכבר יש לנו מודל בסיסי לעבוד מולו, כל דרישה שנרצה להוריד, להוסיף או לשנות, תדרוש עדכון למודל - לא לטסטים עצמם. אחרי העדכון, נמחק את הטסטים הקיימים, ונייצר באופן אוטומטי חבילות בדיקה חדשות מתוך המודל המעודכן. כך, שינוי דרישות שבשיטות בדיקה רגילות דורש עדכון של אלפי תסריטי בדיקה, ידרוש שינוי בודד במודל כאשר משתמשים בגישה של MBT.
למעשה, MBT מאפשר לנו אוטומציה של יצירת תסריטי בדיקה בודדים ושל חבילות בדיקה המשלבות תסריטי בדיקה מרובים. כך, לא רק שנחסך לנו המון זמן של תכנון, הוצאה לפועל ותחזוקה ידנית, אלא גם מובטח לנו שחבילות הבדיקה יניבו כיסוי פונקציונלי גבוה יותר וישקפו באופן מעודכן ונכון את דרישות המערכת הנבדקת.
אז איך MBT מועיל לאנשי הבדיקות
תפקידו של הבודק משתנה מעט ומשתפר בהרבה. הוא הופך להיות מעין אנליסט, המתמקד בהבנת הדרישות, הלוגיקה, והאפיון של המערכת - במקום ביצירת הסקריפטים ותחזוקתם. מכיוון ש-MBT מאפשר לבצע QA כבר בשלב האפיון, ולוודא את נכונות ואיכות הדרישות עצמן, הבודק עובד צמוד עם מחלקת ה-Product, אולי אפילו לפני כניסתם של המתכנתים לתמונה.
היתרונות
קצב יצירת הסקריפטים האוטומטיים שלכם יעלה פי X10 לפחות.
מאמצי התחזוקה של הסקריפטים יורדים למינימום - המודל הוא ייצוג של הדרישות, ותסריטי בדיקה מיוצרים אוטומטית מתוך המודל. לכן, ברגע שחל שינוי בדרישות, הבודק יעדכן את המודל וזה יג׳נרט לו בצורה אוטומטית את התסריטים החדשים.
מכיוון שיש הפרדה ברורה בין תסריטי הבדיקה למימושם, קוד המודל יהיה ״קוד נקי״ באופן דיפולטיבי (clean code).
מה הקאץ׳?
השימוש מצריך שינוי חשיבתי; עד היום בבדיקות מבוססות תסריטים היינו מתמקדים כל פעם בריצה נכונה אחת של המערכת הנבדקת. עם השימוש ב-MBT עלינו לסגל חשיבה הבוחנת את התנהגות המערכת כמכלול (כאמור - לא ברמת פירוט מלאה). כמו כן, נדרשת השקעה בהכשרות וכלים מתאימים ובביצוע אינטגרציה למערכות הקיימות.
מדוע MBT לא תפס עד עכשיו?
עולם המידול החל להתפתח לכיוונים של בדיקות כבר לקראת סוף שנות ה-90, עם לא מעט כלים שונים לאורך השנים שזכו להצלחה חלקית. מאוד.
כל היתרונות של בדיקות מבוססות מודל תלויים, איך לא - בטיבו של המודל. היכולת לייצר מודל טוב היא כשלעצמה דבר בכלל לא פשוט. בדומה לבניית STD מוצלח, כדי לייצר מודל מוצלח ויעיל דרושה קודם כל מומחיות והבנה מעמיקה בתחום בו המערכת עוסקת. עלינו לעדכן אותו בצורה איטרטיבית, בתגובה לדאטה חדש, לפידבק, ולשינוי בדרישות או בסיפורי המשתמשים. כל אלו דורשים זמן, כסף ולופ של פידבקים בין כל בעלי העניין. יש גם קושי במציאת רמת ההפשטה הנכונה על מנת לייצר מודל שימושי של מערכת מורכבת מהעולם האמיתי. נוסף על כך, ישנם קשיים בלכידת התנהגויות לא דטרמיניסטיות וכן בתחזוקה של המודל. זאת מכיוון ששמירה על בהירות המודל נעשית קשה יותר ככל שמורכבות המערכת גדלה.
אז למה דווקא עכשיו?
ב-2010 פרסם צוות חוקרים ממכון וייצמן - דוד הראל, אסף מרון, וגרא וייס - פרדיגמה חדשה ליצירת מודלים. הם קראו לשיטה Behavioral Programming - BP, כלומר תכנות התנהגותי, והיא מותאמת לאופן בו אנשים בדרך כלל מתארים התנהגות של מערכת. פרדיגמה זו מאפשרת ליצור מודלי בדיקה בצורה הרבה יותר אינטואיטיבית ונוחה בהשוואה לשיטות שקדמו לה.
בגדול, מודל BP מורכב מהרבה התנהגויות קטנות ופשוטות. כל התנהגות כזו מייצגת דרישה או use case המופיע במסמך הדרישות, בעזרת רצף אירועים שהמערכת צריכה, יכולה, או אסור לה להוציא לפועל. התנהגות יכולה להיות עצמאית לגמרי, או מאוד תלויה בהתנהגויות אחרות, או בכל מקום ביניהם. שילוב כל ההתנהגויות הקטנות ביחד יוצר מודל שלם של ההתנהגות הרצויה של המערכת הנבדקת, שהיא - בדרך כלל - התנהגות מורכבת מאוד.
מאז 2010 נעשו שינויים ושיפורים רבים לפרדיגמה זו, ופותחו טכנולוגיות וכלים לעבודה עם מודלים שנבנו על פיה. כיום, באמצעות כלי המידול והבדיקות של חברת Provengo, בודקי תוכנה בעלי ידע בסקריפטינג או תכנות בסיסי יכולים להצטרף לעולם ה-MBT בצורה קלה ואינטואיטיבית. ניתן לפתח ולבדוק מודלים, לייצר דיאגרמות התנהגות, לבנות חבילות בדיקה אופטימליות, ולהריץ את החבילות האלו ידנות, באוטומציה, או על ידי יצירת קוד למערכות בדיקה קיימות.
לסיכום
הצגנו את גישת הבדיקות מבוססת המודלים (MBT). ראינו כי היא מאפשרת למשתמשים בה להנות ממספר יתרונות רב. בין השאר שיפור איכות העבודה והתוצרים, שיפור התקשורת בין ארגונים שונים ובין קבוצות הפיתוח השונות, הוזלת עלויות הפיתוח, והגברת מהירות הפיתוח.
· מיפוי כלל ההתנהגויות במערכת והצגתם באופן ויזואלי שאנשי ה business והפרודקט יוכלו להבין באופן אינטואיטיבי וקל (Validation)
· אפשרות לבדוק איכות כבר בשלב איסוף הדרישות, כלומר מציאת באגים ודרישות סותרות לפני שבניית המערכת הנבדקת עצמה החלה (Verification)
· הפקה אוטומטית של חבילות בדיקה אופטימליות בסנכרון מלא לדרישות המעודכנות, כך שהבדיקות אכן בודקות בדיוק את מה שהצד העסקי ביקש לבדוק
· מעבר קל ואינטואיטיבי בין יצירת בדיקות אוטומטיות לבין יצירת ספרי בדיקות ידניים
·