אקסל מעל ומעבר

באחרונה אני שומע רבות על גישות חדשניות לבניה/פיתוח של בדיקות אוטומטיות. הבאזוורד הרווח היום הוא KDT-KeyWord Driven Test

ראשית, מהו הKDT הזה?

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

להלן סיכום מקוצר של עקרון הKDT:

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

ממליץ בחום לעיין במסמך הנ"ל.

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

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

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

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

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

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

כמו כן, יש נקודות נוספות שחשוב להתיחס אליהן:

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

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

TRACSPRO

יש לציין ששמתי את הTRACSPRO במקום ראשון כי אני משוחד.

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

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

QC+QTP => BPT

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

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

הBPT הינו Frame Work לאינטגרציה ברמות גירעון שונות, החל מרכיב בודד המייצג תסריט תהליכי שלם המשך ברמת הגירעון ה"מומלצת" של HP – מסך בדיד, וכלה ברמת האוביקט במסך.

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

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

כמו כן, שימוש בBPT מצמצם את העלויות ב50% ומציג יחס עלות תועלת משופר בהרבה – גם צפי ל3 סבבי הרצה יחזיר את ההשקעה באוטומציה!

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

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

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

ותודה לאסף האוזר שעזר לי במאמר זה