אינטגרציה של Playwright/Selenium עם LLM לבדיקות אוטונומיות

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

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

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

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

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

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

מה משתנה אחרי ההטמעה: כיסוי ומהירות

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

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

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

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

דרכים לשלב בדיקות: השוואת מצבים

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

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

איך מתבצעת ההטמעה: שלבי עבודה הנדסית

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

1. ביקורת תרחישים. מנתחים מערכי רגרסיה ואת מפת המוצר, בוחרים מסלולי משתמש קריטיים ומסמנים מה נסגר בבדיקות אוטונומיות ומה נשאר בכוונה בבדיקה ידנית.
2. סכמת הרצה. קובעים היכן מופעלות הבדיקות, איך מבודדים נתונים ואיך בין תרחישים מוחזר מצב התחלתי: אחרת בדיקה אחת שנכשלה גוררת איתה בדיקות שכנות.
3. הגדרת סביבות. מקימים סביבות בדיקה, חשבונות בדיקה ונתונים, מגדירים Playwright והרצה בדפדפנים שבהם קהל המשתמשים של המוצר באמת משתמש.
4. יצירת בדיקות. המודל, לפי תיאור התרחיש ורמזים על מבנה העמוד, מפיק טיוטת בדיקה; המהנדס מתקן אותה ומשאיר רק את מה שישרוד את שינויי הממשק הקרובים.
5. בדיקת יציבות. מריצים את המערך שוב ושוב על אותו קוד ומנקים שלבים שנותנים תוצאה שונה בלי שינויים במוצר.
6. בדיקת קבלה. משווים הרצה אוטונומית להרצה ידנית בתרחישי בקרה ומוודאים שפגמים שהוכנסו בכוונה אכן נמצאים.
7. מסירה לצוות. מוסרים קונפיגורציות, כללי תחזוקה של הבדיקות והוראות להרחבת המערך — בהמשך הצוות מנהל אותו בעצמו.

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

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

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

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

מקרה בוחן: איך צמצמנו רגרסיה ידנית בזרימת הזמנות

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

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

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

כעבור חודשיים מההפעלה: הרצה מלאה — 35–40 דקות במקום 8–10 שעות, שיעור הבדיקות הידניות ירד מ-100% ל-12% — בעבודה ידנית נשארו הגהה של מיילים ופריסה במכשירים נדירים, פגמים שהוחמצו לשחרור — 0–1 במקום 4–6.

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

במה בדיקות אוטונומיות שונות מבדיקות אוטומטיות קלאסיות

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

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

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

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

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

חששות של מהנדסים: גישות, נתונים, בדיקות לא יציבות

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

האם נדרשים נתוני בדיקה אמיתיים?

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

איך מתמודדים עם בדיקות לא יציבות?

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

מה עם הרשאות גישה ותמיכה לאחר המסירה?

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

נדבר על המשימה: מה יידרש כדי להתחיל בעבודה

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

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

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

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