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

בעידן שבו בינה מלאכותית (AI) הופכת לחלק בלתי נפרד מתהליכי הפיתוח, עולה שאלה קריטית עבור אנשי ה-QA: האם תוכנה שעברה את כל הבדיקות האוטומטיות שהוגדרו לה היא אכן תוכנה תקינה? במפגש האחרון של Software Testing Live (פרק 7), לקחו ג'יימס לינדזי ובן דואן את הסוגיה הזו צעד אחד קדימה ובחנו בזמן אמת את הגבולות שבין קוד "עובר" לבין מוצר "עובד".

הניסוי: יצירת תוכנה מתוך בדיקות

הבסיס למפגש היה מעניין במיוחד: במקום לכתוב קוד ואז לבדוק אותו, הצוות השתמש בגישה של יצירת תוכנה מתוך מערך בדיקות קיים (Test-Driven Generation). המושא לבדיקה היה כלי לבניית תשבצי "תפזורת" (Word Search).

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

טכניקות של בדיקה חוקרת (Exploratory Testing)

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

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

השקיפות כערך עליון

שם הפרק, "Testing transparently", אינו מקרי. המטרה הייתה לחשוף את תהליך המחשבה של הבודק. במקום להציג רק את התוצאה הסופית ("מצאנו באג"), המנחים שיתפו את הקהל בדרך:

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

כדי להבין איך "בדיקה חוקרת" (Exploratory Testing) נראית בפועל על כלי שנוצר על ידי AI (כמו מחולל התפזורות מהמאמר), בוא נפרק דוגמה מעשית.

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

תרחיש בדיקה: מחולל התפזורות (Word Grid Generator)

1. בדיקת "גבולות ההיגיון" (Boundary Logic)

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

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

2. בדיקת "צפיפות ואלגוריתם" (The Clustering Problem)

ה-AI מוודא שכל מילה נמצאת בטבלה. הוא לא תמיד מוודא שהן מפוזרות בצורה חכמה.

הפעולה: הזינו 10 מילים קצרות מאוד (3 אותיות).
מה מחפשים: האם ה-AI ריכז את כולן בפינה השמאלית העליונה? בבדיקה אוטומטית זה עובר (הן קיימות), אבל עבור משתמש אנושי התפזורת "שבורה" כי היא קלה מדי או לא פרופורציונלית.

3. בדיקת "חפיפות בלתי צפויות" (Semantic Overlap)

זהו השלב שבו השכל האנושי מנצח את הקוד היבש.

הפעולה: הכניסו שתי מילים שיש להן רצף אותיות דומה, למשל: "גלידה" ו"גלידה-חמה" (או באנגלית: TEST ו-TESTING).
מה מחפשים: האם ה-AI השתמש באותן אותיות בטבלה כדי לחסוך מקום? אם כן, האם כשמוחקים מילה אחת בעיגול, זה "דורס" את המילה השנייה? בדיקה אוטומטית תזהה ששתיהן קיימות ב-String, היא לא תבין שהן חופפות בצורה שהורסת את חוויית המשחק.

4. בדיקת "תווים מיוחדים ושפות" (The Encoding Gap)

ה-AI לרוב מתאמן על אנגלית סטנדרטית.

הפעולה: נסו ליצור תפזורת עם מילים שכוללות מקף, רווח, או אותיות עם ניקוד/גרשיים (כמו "צ'יפס").
מה מחפשים: האם המערכת "בולעת" את הגרשיים? האם היא מתייחסת לרווח כאל אות ריקה בטבלה? האוטומציה עשויה לבדוק רק Status: 200 OK, אבל אתם תראו שהגרפיקה של הטבלה התעוותה.

איך מתעדים את זה? (דוגמה לדו"ח קצר)

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

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

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

קורס לבדיקות תוכנה מדויק

לעבוד מהבית כבודק תוכנה עם FIVERR >> לחץ כאן