מערכת AI לבדיקה אוטומטית ו-QA למשחקים: פיתוח מקצה לקצה

בדיקות AI למשחקים: איפה נשבר מסלול ה-QA הידני

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

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

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

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

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

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

מה משתנה אחרי ההטמעה: אפקט במספרים מדידים

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

קיצור זמן הרצת הרגרסיה

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

פחות התראות שווא ובדיקות מהבהבות

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

כיסוי הבדיקות ויציבות הבנייה

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

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

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

מתי מספיקים תרחישים מוקלטים

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

מתי נדרש סוכן אוטונומי והיברידי

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

שלבי הטמעת סוכן AI: ביקורת, סכמה, בדיקה, מסירה

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

ביקורת כיסוי והגדרת סכמת הבדיקות

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

הגדרה, בדיקה על סטנד והעברה

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

מה נשאר אצל הצוות: תצורות, דוחות, נהלים

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

תצורות הסוכן ועדיפויות הרצה

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

דוחות, נהלים והוראות

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

מקרה בוחן: איך סוכן אוטונומי סגר רגרסיה לפני שחרור

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

מדדים לפני ואחרי במחזור שחרור

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

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

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

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

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

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

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

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

ספקות טכניים לפני פיילוט: מפרקים לפי סעיפים

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

עד כמה תכופות התראות השווא?

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

איזו גישה לבניות נדרשת?

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

מה קורה עם שינוי ממשק?

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

מי תומך אחרי המסירה ומה הם זמני הפיילוט?

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

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

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

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

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

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