אני חושב שהשיחה על AI בעולם הבדיקות קצת פספסה את הנקודה החשובה באמת.
כשמדברים על AI ו-QA, מיד קופצים למקומות כמו אוטומציה, כתיבת קוד, יצירת טסטים אוטומטיים ו-Selenium. אבל בפועל, יש קבוצה שלמה שיכולה להרוויח מה-AI כבר היום, בלי לדעת לכתוב שורת קוד אחת: הבודקים הידניים.
וכאן, לדעתי, לראש צוות הבדיקות יש תפקיד משמעותי.
ראש הצוות לא צריך להיות האדם שמפעיל את ה-AI במקום הבודק. להפך. הוא צריך ללמד את הצוות להשתמש בו כעוזר מקצועי — כזה שמקצר עבודה, מעלה את איכות החשיבה ומאפשר לבודק להשקיע יותר זמן במה שבאמת דורש ניסיון ושיקול דעת.
AI לא אמור להחליף את הבודק
זו הנקודה הראשונה שהייתי שם על השולחן מול כל צוות QA.
AI יודע לייצר רעיונות, לסכם מידע, להציע תרחישים, לנתח טקסט ולמצוא דברים שאולי פספסנו.
אבל הוא לא באמת מכיר את המוצר כמו הבודק.
הוא לא ישב עם מנהל המוצר.
הוא לא שמע את הלקוח מתלונן.
הוא לא מכיר את כל ההיסטוריה של הבאגים במערכת.
והוא לא תמיד מבין למה תהליך מסוים, שנראה תקין לחלוטין מבחינה טכנית, פשוט "מרגיש לא נכון".
לכן מבחינתי המשוואה היא פשוטה:
AI מגדיל את היכולת של הבודק — הוא לא מחליף את שיקול הדעת שלו.
וזה בדיוק המקום שבו ראש הצוות צריך להוביל.
1. להשתמש ב-AI כדי לייצר רעיונות לתרחישי בדיקה
אחד השימושים הפשוטים והאפקטיביים ביותר הוא לקחת דרישה ולבקש מה-AI לחשוב כמו בודק.
לדוגמה, קיבלנו דרישה:
משתמש יכול לשנות את כתובת המייל שלו באזור האישי.
במקום שהבודק יתחיל מיד לכתוב Test Cases, אפשר לתת ל-AI את הדרישה ולבקש ממנו לחשוב על:
- תרחישים חיוביים
- תרחישים שליליים
- ערכים חריגים
- הרשאות
- מקרי קצה
- בעיות אבטחה
- בעיות UI
- בעיות תאימות
- מצבים של משתמשים שונים
- מצבים שבהם המערכת או השירות החיצוני אינם זמינים
פתאום דרישה פשוטה הופכת לרשימה הרבה יותר רחבה של שאלות.
אבל כאן חשוב לעצור.
לא מעתיקים את הרשימה ומסיימים את הבדיקה.
הבודק עובר עליה ושואל:
מה רלוונטי למוצר שלנו?
מה חסר?
מה AI לא הבין?
איזה תרחיש הוא בעל הסיכון הגבוה ביותר?
דווקא השיחה הזאת היא המקום שבו הידע המקצועי של הבודק הופך להיות משמעותי יותר.
2. להשתמש ב-AI כדי לאתגר את החשיבה של הבודק
זה שימוש שאני מאוד אוהב.
במקום לשאול את ה-AI:
"כתוב לי Test Cases"
אפשר לשאול:
"אני בודק את הפיצ'ר הבא. נסה למצוא לי הנחות שגויות שאני עלול לעשות כבודק."
זו שאלה הרבה יותר מעניינת.
אפשר גם לבקש:
"חשוב כמו משתמש מתוסכל."
"חשוב כמו משתמש שמנסה לשבור את המערכת."
"חשוב כמו מנהל מוצר."
"חשוב כמו תוקף."
"מה יכול להשתבש בתהליך הזה שלא חשבתי עליו?"
כאן AI הופך ממכונת כתיבה ל־שותף לחשיבה.
וזה בעיניי אחד השימושים החשובים ביותר עבור בודק ידני.
3. יצירת Test Cases במהירות
אין סיבה שבודק מנוסה יבזבז שעה על ניסוח ידני של עשרות Test Cases פשוטים.
אפשר לתת ל-AI את הדרישה ולבקש ממנו להציע מבנה הכולל:
- ID
- שם הבדיקה
- Preconditions
- Steps
- Expected Result
- Priority
- סוג הבדיקה
אחר כך הבודק עובר על התוצאה.
הוא מוחק מה שלא רלוונטי, משנה ניסוחים, מוסיף תרחישים ומוודא שהבדיקות באמת משקפות את המערכת.
התוצאה היא לא "AI כתב את הבדיקות".
התוצאה היא:
הבודק השקיע את הזמן שלו בעריכה מקצועית במקום בהקלדה.
זה הבדל גדול.
4. ניתוח דרישות לפני שמתחילים לבדוק
אחד הדברים שאני רואה הרבה בעולם הבדיקות הוא שבודקים מקבלים דרישה, קוראים אותה, אומרים "הבנתי" ומתחילים לעבוד.
אבל לפעמים הדרישה עצמה בעייתית.
AI יכול לעזור לראש הצוות להכניס שלב נוסף לתהליך:
Requirement Review באמצעות AI.
אפשר לקחת דרישה ולשאול:
- אילו חלקים אינם ברורים?
- אילו תנאים חסרים?
- האם קיימות סתירות?
- אילו שאלות צריך לשאול את מנהל המוצר?
- אילו תרחישים אינם מוגדרים?
- מה קורה במקרה של שגיאה?
- מה קורה כאשר המשתמש מבצע פעולה פעמיים?
- מה קורה כאשר השירות החיצוני אינו זמין?
פתאום הבודק מגיע לפגישת ה-refinement עם שאלות הרבה יותר טובות.
וזה כבר לא רק חיסכון בזמן.
זה שיפור איכות התהליך כולו.
5. יצירת נתוני בדיקה
בודקים ידניים מבזבזים לא מעט זמן על יצירת Test Data.
AI יכול לעזור לייצר נתונים מגוונים בהתאם לצורך:
- שמות
- כתובות
- מספרי טלפון
- תאריכים
- ערכים תקינים
- ערכים לא תקינים
- מחרוזות ארוכות
- תווים מיוחדים
- שילובים חריגים
לדוגמה, אם בודקים שדה שמאפשר שם משתמש, אפשר לבקש מה-AI לחשוב על מגוון רחב של קלטים:
שם קצר, שם ארוך, עברית, אנגלית, רווחים, תווים מיוחדים, מספרים, ערכים ריקים ועוד.
כמובן, לא משתמשים בנתונים אמיתיים או במידע אישי רגיש.
6. סיוע בחקירת באגים
כאן לדעתי יש ל-AI פוטנציאל עצום.
בודק מצא באג.
במקום רק לפתוח Bug ולהעביר אותו הלאה, אפשר להזין ל-AI את המידע שאינו רגיש:
- מה היה ה-Expected Result
- מה קרה בפועל
- צעדי השחזור
- הודעת השגיאה
- סביבת הבדיקה
- לוגים רלוונטיים
ולבקש:
"אילו גורמים יכולים להסביר את ההתנהגות הזאת?"
AI יכול להציע כיווני חקירה.
לא תשובה סופית.
כיווני חקירה.
וזה הבדל חשוב.
אולי הבעיה קשורה להרשאות.
אולי לנתוני קלט.
אולי ל-Time Zone.
אולי ל-API.
אולי ל-Caching.
אולי לבעיה בצד הלקוח.
הבודק עדיין צריך לבדוק.
אבל עכשיו יש לו עוד זוג עיניים שמעלה אפשרויות.
7. שיפור כתיבת באגים
Bug Report טוב הוא מיומנות.
לא כל בודק יודע להסביר בעיה בצורה שמפתח יכול להבין במהירות.
AI יכול לקחת תיאור מבולגן כמו:
"נכנסתי למערכת, שיניתי את הפרטים, עשיתי שמירה ואז משהו לא הסתדר והמסך נשאר אותו דבר."
ולהפוך אותו למבנה ברור יותר:
Title
עדכון פרטי משתמש אינו מוצג לאחר שמירה.
Steps to Reproduce
- התחברות למערכת.
- מעבר לאזור האישי.
- שינוי כתובת.
- לחיצה על שמירה.
- רענון הדף.
Expected Result
הכתובת החדשה מוצגת באזור האישי.
Actual Result
הכתובת הישנה ממשיכה להיות מוצגת.
כמובן שהבודק צריך לוודא שהניסוח אכן מדויק.
אבל שוב — במקום לבזבז זמן על ניסוח, הוא יכול להתמקד באיכות הממצא.
8. סיכום תוצאות בדיקה
בסוף יום בדיקות יש לעיתים הרבה מידע.
20 באגים.
40 Test Cases.
מספר תרחישים שנכשלו.
כמה בדיקות שלא ניתן היה לבצע.
כמה בעיות סביבתיות.
AI יכול לעזור להפוך את כל המידע הזה לסיכום ברור למנהל, למוצר או לצוות הפיתוח.
לדוגמה:
בוצעו: 86 בדיקות
עברו: 72
נכשלו: 9
Blocked: 5
אבל המספרים הם רק ההתחלה.
החלק החשוב יותר הוא להבין:
מה הסיכון המרכזי?
מה עדיין לא נבדק?
מה עלול לעכב Release?
אילו באגים דורשים תשומת לב מיידית?
כאן AI יכול לעזור לראש הצוות להפוך נתונים למידע ניהולי.
9. שימוש ב-AI כדי לחנוך בודקים צעירים
זה שימוש שאני חושב שלא מקבל מספיק תשומת לב.
ראש צוות יכול לבקש מהבודקים הצעירים לעבוד עם AI בצורה מודרכת.
לדוגמה:
בודק חדש מקבל פיצ'ר.
הוא צריך לחשוב בעצמו על תרחישי בדיקה.
רק לאחר מכן הוא פונה ל-AI ושואל:
"מה פספסתי?"
עכשיו אפשר להשוות:
החשיבה של הבודק מול החשיבה של AI.
זה הופך את AI לכלי למידה.
לא לקביים.
וזה הבדל עצום.
10. AI כ"מנטור" לבודק ידני
בודק שלא מבין מושג מסוים לא חייב לעצור את העבודה.
הוא יכול לשאול:
"מה זה API?"
"מה ההבדל בין 401 ל-403?"
"מה זה Race Condition?"
"מה המשמעות של Timeout?"
"איך אפשר לבדוק את התרחיש הזה?"
אבל הייתי מוסיף כלל חשוב:
לא רק לקבל תשובה — לבקש הסבר.
ואפילו יותר מזה:
"למה?"
"מה הדוגמה?"
"איך אני יכול לבדוק את זה בפועל?"
כך הבודק מתחיל לבנות לעצמו בסיס טכני רחב יותר.
וזה בדיוק מה שיכול לעזור לבודק ידני להתפתח מקצועית.
11. שימוש ב-AI לכתיבת SQL בסיסי
בודק ידני לא חייב להפוך ל-Database Developer.
אבל ידע בסיסי ב-SQL יכול לשדרג אותו משמעותית.
AI יכול לעזור לו לכתוב שאילתות פשוטות:
למצוא רשומות.
לסנן נתונים.
להשוות נתונים.
לבדוק כפילויות.
לבדוק קשרים בין טבלאות.
למצוא נתונים שאינם עומדים בתנאי מסוים.
הבודק עדיין צריך להבין מה השאילתה עושה ולוודא שהיא נכונה.
אבל הוא לא חייב לזכור בעל פה כל פקודת SQL.
12. עזרה בכתיבת Regex
עוד דוגמה קטנה אבל שימושית.
יש שדה שצריך לקבל פורמט מסוים.
הבודק רוצה לבדוק האם הערך תקין.
אפשר לבקש מ-AI להסביר כיצד ליצור Regular Expression שמתאים לדרישה.
אבל שוב — לא לקחת את הביטוי ולהניח שהוא נכון.
מבקשים מה-AI גם:
"מה הביטוי הזה מקבל?"
"מה הוא דוחה?"
"אילו מקרי קצה הוא מפספס?"
כך הבודק לומד תוך כדי העבודה.
ומה התפקיד של ראש הצוות בכל הסיפור הזה?
לדעתי זה החלק החשוב ביותר.
ראש צוות לא צריך להגיד:
"מהיום כולם משתמשים ב-AI."
זו לא אסטרטגיה.
צריך להתחיל קטן.
לבחור כמה פעולות שחוזרות על עצמן ומבזבזות זמן:
כתיבת Test Cases.
שיפור Bug Reports.
ניתוח דרישות.
יצירת Test Data.
סיכום תוצאות.
חקירת תקלות.
ואז לבדוק:
כמה זמן חסכנו?
האם איכות הבדיקות עלתה?
האם הבודקים מצאו יותר תרחישים?
האם מספר הבאגים שנפתחו בצורה לא ברורה ירד?
האם הבודקים לומדים יותר?
ויש גם צד מסוכן שראש הצוות חייב להכיר
אני דווקא לא ממליץ לתת לצוות להשתמש ב-AI בלי גבולות.
הבעיה הגדולה ביותר היא לא ש-AI "יטעה".
הבעיה היא שהבודק יאמין לו בלי לבדוק.
אסור להפוך את התהליך ל:
דרישה → AI → Test Cases → בדיקה → סיום.
כי אז איבדנו את הדבר הכי חשוב שיש לבודק:
שיקול דעת.
צריך גם להיזהר מאוד מהכנסת מידע רגיש למערכות AI:
- מידע אישי של לקוחות
- סיסמאות
- Tokens
- נתוני Production
- מידע עסקי חסוי
- קוד שאינו מאושר לשיתוף
- לוגים המכילים מידע רגיש
לכל ארגון צריכה להיות מדיניות ברורה לגבי השימוש בכלי AI.
אני חושב שהשינוי האמיתי יגיע בכלל ממקום אחר
בעיניי, AI לא יהפוך את הבודק הידני למיותר.
הוא הולך לשנות את ההגדרה של מהו בודק ידני טוב.
פעם היה אפשר להיות בודק טוב אם ידעת לבצע Test Case בצורה מדויקת.
היום זה כבר לא מספיק.
בודק טוב צריך לדעת לשאול שאלות.
להבין סיכונים.
להכיר את המוצר.
לחשוב על משתמשים.
להבין טכנולוגיה.
לחקור תקלות.
ולהשתמש בכלים חכמים כדי להרחיב את היכולת שלו.
והדבר המעניין הוא שדווקא בודק ידני עם ניסיון יכול להרוויח מהשינוי הזה מאוד.
כי AI יכול לייצר רעיונות.
אבל הוא עדיין לא מחליף ניסיון של שנים.
הוא לא יודע איזה באג קטן הולך להפוך מחר לבעיה ענקית אצל הלקוח.
הוא לא תמיד מזהה שההתנהגות של המערכת "לא מרגישה נכונה".
והוא לא מכיר את כל הניואנסים של המוצר כמו האדם שחי אותו יום אחרי יום.
לסיכום: לא להפוך את הבודקים למפעילי AI
אם הייתי ראש צוות בדיקות היום, הייתי שם לעצמי מטרה פשוטה:
לא לגרום לצוות לעבוד פחות — לגרום לו לעבוד חכם יותר.
הייתי מלמד את הבודקים להשתמש ב-AI כדי לחסוך זמן במשימות טכניות וחזרתיות.
אבל במקביל הייתי דורש מהם לחשוב יותר.
לשאול יותר שאלות.
לחקור יותר.
להבין יותר את המוצר.
ולהטיל ספק גם בתשובה של AI.
כי בסופו של דבר, המטרה היא לא ליצור צוות QA שיודע להשתמש ב-AI.
המטרה היא ליצור צוות QA טוב יותר בזכות AI.
וזה הבדל קטן במשפט, אבל הבדל עצום בניהול.
מי שראש הצוות שלו יצליח לעשות את המעבר הזה נכון, יגלה שה-AI לא לקח מהבודקים את העבודה.
הוא דווקא פינה להם זמן לעשות את החלקים בעבודה שבגללם בכלל צריך בודקים אנושיים.
לקרוא מאמרים זה נחמד אבל לא יביא אותך לתוצאה שאתה רוצה, בדיוק בשביל זה הכנו עבורך את הקורס הדיגיטלי המהיר, תוך שעתיים וחצי תלמד את תחום הבדיקות ידניות, תוכל להתחיל לעבוד מהבית דרך FIVERR או ולהתכונן נכון לראיונות עבודה שיעזרו לך לצלוח אותם. כנס כאן הקורס ממוקד בבדיקות תוכנה ידניות הנותן בסיס חזק לתחום.
לעבוד מהבית כבודק תוכנה עם FIVERR >> לחץ כאן
