תכונות

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

* הצגה של תסריטי בדיקה בצורה גרפית.

* יצוא של תסריטי בדיקות ל-excel, JSON.

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

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

* כלי low-code, ממשקי משתמש המאפשרים שימוש בכלי גם לאלו שלא יודעים לקודד.

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

התקנות

 הוראות התקנה באתר הדוקומנטציה של פרובנגו

כדי להשתמש בפרובנגו נזדקק ל: 

1. Java בגרסה 11 או גרסה מאוחרת יותר. וכן, להוסיף את JAVA_HOME למשתני הסביבה (בדרך כלל תהליך ההתקנה של Java כולל אפשרות לעדכן משתני סביבה, רק צריך לזכור לסמן את הקוביות הנכונות).

2. טרמינל או כלי command line אחר.

3. graphviz לצורך יצירת גרפים.

4. סלניום-סרבר (גריד) ובראוזר-דרייבר לסלניום. זאת לצרכי ביצוע אוטומציות בדפדפן. 

5. המערכת של פרובנגו, כוללת שני קבצים. נשמור אותם באותה התיקייה: 

א. נוריד את הקובץ Provengo ונשנה את שמו כך שיופיע בלי התאריך - Provengo.uber.jar 

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

⬅ נפתח את הטרמינל שלנו מהתיקייה בה שמרנו את הקבצים ונריץ את הפקודה הבאה (תלוי מערכת הפעלה)

 ./provengo.bat   או   ./provengo.sh

 כעת אנו אמורים לראות בטרמינל פלט כלשהו עם המילה פרובנגו.

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

פתיחת פרויקט פרובנגו:

כדי לפתוח פרויקט פרובנגו חדש עלינו להקליד בטרמינל את הפקודה provengo.sh create ולאחריה לתת שם לפרויקט. המערכת תקפיץ לנו כמה שאלות לצורך הגדרות ראשוניות של הפרויקט: שם הפרויקט, האם לאתחל תיקיית גיט, האם להוסיף את קבצי ה-AIי שלנו (שעוזרים בהשלמות אוטומטיות לכלים כמו copilot, tab9). נעבור את כל השאלות עם enter.  

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

נפתח את הפרויקט ב-VSCode, (או בעורך לבחירתכם). הפרויקט מכיל מספר תיקיות וקבצים המהווים איזשהו starter-kit עבור תחילת העבודה עם הכלי. כמו כן, יש גם פרויקט Hello-World לדוגמא. 

מבנה פרויקט:

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

* בתיקיית ה-spec נמצאת תיקיית ה-js, בתוכה נחזיק את הקבצים הרלוונטים להרצה.
* בקובץ ה-data.js, תחת תיקיית data, נוכל למצוא את מערך הברכות האפשריות. 
* תיקיית config עבור הקונפיגורציות של הפרויקט.
* כמו כן יש גם תיקיית lib בה נוכל להוסיף ספריות קוד משלנו.
* תיקיית meta-spec בה נוכל למצוא קבצים המשמשים ליצירת תסריטי בדיקות, ליצירת אופטימיזציות, וכן לייצוא של הבדיקות לסקריפטים ופורמטים שונים (למשל ייצוא ל-python או ל-excel). 
* טיפ: נהוג להוסיף בתיקיית spec תת-תיקיה בשם disabled. כך ניתן להפעיל או לבטל בקלות חלקים   

ממודל הבדיקות על ידי גרירתם אל ומתוך תיקייה זו.

נחזור אל הטרמינל, ובאמצעות הפקודה analyze,

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

הקובץ החדש יווצר לנו תחת תיקיית products ומיד יפתח:

נצלול לדוגמא קצת יותר מעניינת:

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

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

 בתיקיית ה-js שלנו יהיה קובץ שיכיל את תרשים הבסיסי של הפרויקט:

1. להתעורר.

2. להתלבש.

3. לצחצח שיניים.

4. בתנאי שיש זמן, להסתדר.

5. ולבסוף לצאת מהבית.

 ⬅ נחזור אל הטרמינל ונבקש מפרובנגו להפיק לנו את הגרף של מרחב הבדיקות.  

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

וזהו הגרף שהתקבל:

תסריט לא הגיוני: נעילת נעליים לפני גריבת גרביים

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

א) לא הגיוני - אין טעם לבדוק

ב) בדיקה שלילית - צריך לבדוק שהמשתמש לא מצליח לעשות את הפעולה. 

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

 1. נניח כי זה מקרה לא הגיוני ולכן אין בכלל צורך להתייחס אליו. נוסיף קובץ לתוך תיקיית ה-js שלנו שיכיל את הקוד המתאר: חסימה של נעילת נעליים עד לקבלת גריבת גרביים. 

ושוב נריץ את פקודת האנליזה ונקבל גרף חדש.   

⬅ ניתן לראות שהאופציה לנעול נעליים לפני גרביים ירדה לנו מהגרף. וכל שאר האופציות למסלולים נשארו. נגרור את הקובץ לתוך תיקיית disabled ונתקדם לאופציה הבאה. 

 2. נסה לנעול נעליים לפני גרביים והיכשל (בדיקה שלילית / rainy-day)

נוסיף קובץ חדש לתיקיית ה-js המטפל במקרה זה. בקובץ זה, יהיו שני בלוקים. 

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

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

⬅ וניתן לראות בגרף שנוצר שקיבלנו את כל המקרים בהם הוא ינסה, וייכשל.

3. דרישה ״לא הגיונית״

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

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

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

כלי Low-Code

 אלו הם ממשקי משתמש המאפשרים לבודקים ידניים ולאנשי ה-product להשתמש בכלי, מבלי שהם צריכים לכתוב קוד. 
 כעת, נוסיף ל-main-flow של שגרת הבוקר שלנו גם ניהול ארוחת בוקר. 

 נעשה זאת באמצעות תוסף ל-VScode הנקרא Combi. כדי להוריד אותו ניתן למצוא אותו ב-extensions marketplace של  vscode ולהתקין. 

נמלא בקובץ ה-Combi את השדות המגדירים את ניהול ארוחת הבוקר:

1. נמלא מידע על הפרויקט 
2. נמלא את השדות:

* מנה עיקרית יכולה להיות ביצה, דייסה או טוסט.
* משקה - מיץ קפה שניהם או כלום. 
* מנת צד - סלט, צ׳יפס או כלום.

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

נריץ שוב באמצעות פקודת ה-analyze ונקבל תוספת לגרף הקיים:

ייצור תוכנית בדיקות ממודל

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

בדיקות אוטומציה ישירות מהמודל, 

בדיקות אוטומציה דרך מערכות צד שלישי, 

וייצור של תסריטי בדיקות ידניות.

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

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

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

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

על מנת לייצר אוטומציה ישירה, נשתמש באחת (או יותר!) מספריות האוטומציה המגיעות עם הכלי. ספריות אלו כוללות הפעלה של סלניום, REST API, סקריפטים, ואפילו מחשבי mainframe. נוסיף למודל רכיב עם הוראות אוטומציה (לחיצות, כתיבת טקסט, בדיקת ערכים וכו׳) המשתלבות במסגרת המודל הקיים. למשל, כאשר רכיב המודל שאחראי על סדר הפעולות - הרכיב אותו ראינו עד כה - מחליט שכעת לובשים מכנסים, רכיב האוטומציה יבצע את הפעולות המתאימות, למשל לחיצה על כפתורים ספציפיים ובדיקה שאלמנט החולצה מופיע על המסך.

הרצה של הבדיקות עצמן מתבצעת על ידי פקודת provengo run - ניתן לבחור הרצה של תסריט אקראי, או של חבילת בדיקות. על מנת לבצע אוטומציות של מערכות web, ידרש שרת selenium grid זמין. אלה יכולים לרוץ מקומית על המחשב, או על מחשב מרוחק.

באוטומציה דרך מערכות צד שלישי, אנו משתמשים בכלי על מנת לייצר בדיקות שיבוצעו על ידי מערכות אחרות. למשל, אנחנו יכולים לקחת חבילת בדיקות שפיתחנו ב-provengo, ולהפוך אותה לקבוצת סקריפטים בפייתון, לקובץ Java שיופעל על ידי JUnit, לקובץ xaml עבור UiPath, ובעצם לכל פורמט טקסטואלי אחר (כולל כמובן JSON ו-XML). שיטה זו מאפשרת לנו ליהנות מהיתרונות של provengo ולנצל את תשתית הבדיקות הקיימות בארגון. לצורך כך נשתמש בפקודת provengo gen-scripts עם הפרמטרים המתאימים. בפרוייקט עצמו נכתוב פונקציה הממירה בין תסריט בדיקה של הכלי לבין תסריט של מערכת היעד. פרוייקט יכול להכיל כמה פונקציות כאלו, כך שניתן בקלות להפעיל תשתיות שונות בעזרת אותו מודל.

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

היתרונות

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

החסרונות

* תחזוקת הטסטים יורדת למינימום. המודל מייצר עבורנו את הטסטים מחדש בכל שינוי או עדכון של המודל.
* יש לא מעט התקנות שצריך לבצע לפני שמתחילים לעבוד עם הכלי. (בקרוב יטופל עם installers). 
* הכלי הוא כלי command-line, אין כרגע ממשק גרפי למשתמש (למעט כלי ה-low code).
* כדי לעבוד עם הכלי בצורה יעילה, צריך ללמוד את ״השפה של פרובנגו״. השפה כאמור מבוססת על javascript, אבל עם כל מני תוספות של פרובנגו עצמה, כגון DSLs ו- libraries. צריך להבין איך ומתי הכי נכון להשתמש בהן והגעה למצב של שליטה מלאה בכלי יכול לקחת קצת זמן.


עוד על המודל מאחורי פרובנגו.

ציון:

מענה צרכים של החברה 9/10

נותן למשתמש חווית שימוש 7/10

תמיכה וקהילה 6/10

סה"כ 7.3