באמצעות כלי פיתוח מודרניים, בינה מלאכותית יוצרת (Generative AI) ופרוטוקול Model Context Protocol (MCP), יכולים בודקי תוכנה לחבר בין ניתוח עסקי ברמה גבוהה לבין מערכות טכניות כגון Git, Xray ומערכות ALM נוספות.
במודל העבודה המוצג, ה-AI משמש כעוזר מקצועי מתקדם, אך תהליך העבודה עצמו נשאר דטרמיניסטי, ניתן למעקב ומבוקר. בכל שלב משמעותי, בודק התוכנה הוא זה שמקבל את ההחלטה הסופית.
להלן מחזור החיים המוצע:
התהליך מתחיל בכך שה-AI מנתח את הדרישות ישירות מתוך מערכת ה-ALM ומזהה:
בהמשך מציע ה-AI כיסוי בדיקות מקיף הכולל:
בודק התוכנה עובר על ההמלצות ומחליט אילו מהתרחישים יהפכו למקרי בדיקה רשמיים.
לאחר אישור היקף הבדיקות, הבודק עובר לסביבת עבודה הדומה לזו של מפתח.
נוצר Branch ייעודי עבור חבילת הבדיקות, המספק בידוד מלא ושומר על הקשר לדרישה המתאימה.
מקרי הבדיקה נכתבים כקבצי Markdown (או פורמט מובנה אחר) הכוללים:
קבצים אלו מהווים את מקור האמת (Source of Truth) של חבילת הבדיקות.
כל מקרה בדיקה נשמר ב-Commit נפרד, מה שמאפשר:
לאחר כתיבת הבדיקות מתבצע סנכרון בין המאגר המקומי לבין Xray לצורך שמירה על Traceability.
תהליך הסנכרון:
שמירת מזהה ה-Xray יוצרת חיבור קבוע בין Git לבין מערכת ה-ALM ומבטיחה ששני המאגרים מייצגים את אותה גרסת בדיקות מאושרת.
לפני שהבדיקות הופכות לרשמיות, הן עוברות תהליך אישור מקצועי.
בודק התוכנה מפרסם את ה-Branch ויוצר Pull Request המקושר לדרישה.
הסוקר בוחן את:
הערות ותיקונים מנוהלים דרך ה-Pull Request.
לאחר שכל ההערות טופלו וה-Pull Request אושר, מתבצע Merge אל מאגר הבדיקות הרשמי.
ניהול ההרצות מתבצע באמצעות יומן הרצות מקומי (Execution Journal), הכולל:
קיימות שתי שיטות עבודה:
לאחר כל שלב מתועדים:
כל שלב יכול להסתנכרן ל-Xray בזמן אמת.
הבודק מסיים את כל הבדיקה באופן מקומי, מתעד את כל התוצאות ביומן ההרצה, ורק בסיום מבצע סנכרון אחד מרכזי ל-Xray.
גישה זו חוסכת עדכון ידני של כל שלב דרך ממשק ה-ALM.
בשתי השיטות מתבצע עדכון סטטוס הבדיקה הסופי ב-Xray לאחר השלמת ההרצה.
כאשר בדיקה נכשלת, מתחיל שלב ניתוח התקלה.
מתועדים:
ה-AI מסייע להעריך האם מקור התקלה הוא:
הבודק בוחן את ההמלצות ומקבל את ההחלטה הסופית.
כאשר מאושר שמדובר בתקלה במוצר, נוצר באג הכולל:
הבאג מקושר ישירות אל:
בבוקר, הבודק משתמש ב-IDE ובעוזר AI כדי לנתח דרישה חדשה.
לאחר בחירת התרחישים הרלוונטיים הוא:
בשעות אחר הצהריים הוא מריץ את חבילת הבדיקות באופן מקומי, ולאחר אימות התוצאות מבצע סנכרון מרוכז ל-Xray.
הסוקר פותח Pull Request שנוצר על ידי בודק אחר.
במהלך הסקירה הוא מזהה שחסר תרחיש גבול, מוסיף הערה ישירות לקובץ הבדיקה, והבודק מעדכן את הקובץ, יוצר Commit חדש ומפרסם את השינויים.
לאחר שהבעיה נפתרה, הסוקר מאשר את ה-Pull Request והבדיקות מתמזגות למאגר הרשמי.
מוביל הבדיקות עוקב אחר איכות חבילת הבדיקות באמצעות סקירה של:
שרשרת העקיבות המלאה הופכת להיות:
דרישה → מקרה בדיקה → Commit → Pull Request → הרצה → באג
גישה זו שומרת על המאגר המקומי כמקור האמת (Source of Truth), ובמקביל מבטיחה שמערכת Xray ושאר סביבת ה-ALM נשארות מסונכרנות, עקביות וזמינות לכלל הארגון.
קישור לספריות גיט שהוצגו במהלך הוובינר:
https://github.com/g4-api/qa-tools-demo
https://github.com/g4-api/g4-xray-mcp
קישור לשאלון התעניינות בוובינרים ומיטאפים
