TestIL Podcast

פרק 88 – בדיקות ביצועים ועומסים בעידן ה-AIאורח: נחום דימר, ממייסדי CloudBeatבפרק 88 של הפודקאסט של TestIL מבית ITCB, ניצן גולדנברג ונתנאל הרוש מארחים את נחום דימר, מייסדי CloudBeat ומומחה בעל ניסיון של כ-20 שנה בעולמות ה-QA, בדיקות הביצועים, בדיקות העומסים והאוטומציה.במהלך הפרק אנחנו צוללים לעולם של Performance Testing ו-Load Testing, מבינים מדוע התחום עדיין מהווה אתגר עבור ארגונים רבים, איך נכון לתכנן בדיקות ביצועים ועומסים, כיצד המעבר לענן משנה את כללי המשחק – וכמובן, כיצד AI נכנס לתמונה ומשנה גם את התחום הזה.איך הכול התחיל?נחום מספר על הדרך האישית שלו לעולם ה-QA. לאחר שהחל את הקריירה כמהנדס תוכנה, הוא חיפש תפקיד שישלב בין טכנולוגיה לבין עבודה עם אנשים. המעבר לתפקיד Presales בחברה שפיתחה פתרונות QA הוביל אותו כמעט במקרה לעולם בדיקות העומסים.המוצר המרכזי שבו עסק באותה תקופה היה WebLOAD, וכך החל מסע מקצועי שנמשך כבר כשני עשורים. בשנת 2008 הפך לעצמאי, ובהמשך התפתח עסק הייעוץ לכיוון של פתרונות אוטומציה ובדיקות.בסביבות 2016, עם העלייה בשימוש ב-Selenium והמעבר ההולך וגובר של מערכות לעולם ה-Web, נוצר צורך חדש אצל הלקוחות: לא רק לבצע בדיקות, אלא להפוך את בניית האוטומציה לפשוטה ונגישה יותר.מתוך הצורך הזה נולד פרויקט Oxygen, ובהמשך נבנתה סביבו פלטפורמה רחבה יותר להרצה, ניהול, Reporting וניתוח של בדיקות אוטומטיות. בשנת 2018 הוקמה CloudBeat באופן רשמי.Performance Testing מול Load Testing – מה ההבדל?אחת הנקודות המרכזיות בפרק היא ההבחנה בין בדיקות ביצועים לבין בדיקות עומסים.בדיקות ביצועים הן עולם רחב יותר. גם בדיקה של זמן התגובה של מערכת עבור משתמש בודד היא בדיקת ביצועים. בדיקות עומסים, לעומת זאת, מתמקדות בהתנהגות המערכת כאשר משתמשים רבים או פעולות רבות פועלים במקביל ומייצרים עומס על המערכת.המסר החשוב הוא שלא צריך להמתין לשלב שבו רוצים להפעיל אלפי משתמשים כדי להתחיל לבדוק ביצועים. אם המערכת איטית כבר עבור משתמש בודד, הוספת עומס בוודאי לא תגרום לה לעבוד מהר יותר.לא לחכות לרגע האחרוןאחת הבעיות שחוזרות בארגונים היא שבדיקות ביצועים ועומסים נכנסות לתמונה מאוחר מדי – לעיתים ממש לפני העלייה לייצור.לדברי נחום, התחום דורש תכנון מוקדם, הכנת סביבות, הגדרת יעדים ושיתוף פעולה בין מספר גורמים בארגון. כאשר מתחילים את התהליך מאוחר, גם איתור הבעיות וגם התיקון שלהן הופכים ליקרים ומורכבים יותר.בדיקות ביצועים מוקדמות, אפילו ברמת משתמש בודד, יכולות לזהות בעיות כאשר עדיין קל וזול יחסית לטפל בהן.איך יודעים מה נחשב לביצועים טובים?בפרק עולה החשיבות של הגדרת Performance Criteria כבר בשלבי התכנון של המערכת.במקום להגיע לסוף הפרויקט ולהתחיל להתווכח האם זמן תגובה של חמש או עשר שניות הוא סביר, הארגון צריך להגדיר מראש מהי חוויית המשתמש הרצויה ומהם זמני התגובה המקובלים עבור הפעולות המרכזיות.גם כאן אין מספר אחד שמתאים לכל מערכת. פעולה פשוטה באתר אינטרנט אינה דומה להפקת דוח מורכב. לעיתים גם חוויית המשתמש חשובה לא פחות מהמספר עצמו: משתמש שמקבל חיווי ברור שהמערכת מעבדת דוח עשוי לקבל זמן המתנה ארוך יותר בצורה טובה בהרבה ממשתמש שרואה מסך לבן ולא יודע האם המערכת תקועה.איך מבצעים בדיקות עומסים בפועל?בדיקות עומסים אינן מסתכמות בפתיחת אלפי דפדפנים במקביל. בפרויקטים גדולים משתמשים בדרך כלל בבדיקות ברמת הפרוטוקול והבקשות, משום שגישה זו מאפשרת לייצר עומסים גדולים בצורה יעילה ו-Scalable יותר.בין הכלים שעלו בשיחה נמצאים JMeter ו-K6, לצד פתרונות נוספים הקיימים בשוק.הבדיקה צריכה לייצג תהליכים עסקיים אמיתיים ולא רק לייצר כמות גדולה של בקשות. חשוב להבין מה המשתמש עושה, כמה זמן הוא ממתין בין פעולות ומהי ההתנהגות האמיתית שלו במערכת.אחת הטעויות הנפוצות היא לבנות תסריט ללא זמני המתנה בין הפעולות. משתמש אמיתי אינו מקליק ללא הפסקה – הוא קורא, ממלא טפסים וממתין בין פעולות. התעלמות מכך עלולה ליצור עומס מלאכותי שאינו מייצג את המציאות.המטרה היא לא להפיל את המערכתאחד המשפטים החשובים בפרק הוא שהמטרה של בדיקת עומס אינה להפיל את המערכת.להפיל מערכת באמצעות עומס מלאכותי יכול להיות קל יחסית. האתגר האמיתי הוא לדמות בצורה נכונה את השימוש הצפוי במערכת, לזהות היכן נוצרים צווארי בקבוק ולהבין כיצד המערכת מתנהגת בתנאים שמייצגים את העולם האמיתי.המעבר לענן משנה את עולם הביצועיםהמעבר של ארגונים לענן הופך את נושא הביצועים והעומסים למשמעותי עוד יותר.מערכות מודרניות משתמשות בשירותים מנוהלים, Kubernetes, מנגנוני Scaling ותשתיות דינמיות. מצד אחד ניתן להוסיף משאבים במהירות, אך מצד שני לכל משאב יש עלות ויש צורך לוודא שמנגנוני ההתרחבות אכן עובדים כפי שתוכנן.לכן בדיקות עומסים אינן עוסקות רק בשאלה "האם המערכת נופלת?", אלא גם בשאלות כמו כיצד התשתית מתרחבת, האם מנגנוני ה-Scaling פועלים בזמן ומה המחיר של ההתנהגות הזו.AI נכנס לעולם הבדיקותחלק משמעותי מהשיחה מוקדש להשפעה של Generative AI על עולם ה-QA בכלל ועל אוטומציה ובדיקות ביצועים בפרט.נחום מתאר כיצד CloudBeat משלבת יכולות AI בניתוח הרצות אוטומציה, זיהוי Flaky Tests, בעיות סביבה ותיקון קוד. באמצעות מידע שנאסף גם מהרצות תקינות וגם מהרצות שנכשלו, ניתן לספק למנוע ה-AI הקשר רחב יותר ולשפר את איכות הניתוח והתיקון.כאשר קיימות מאות או אלפי בדיקות אוטומטיות, היכולת להשתמש ב-AI כדי לזהות דפוסים, לסנן רעשים ולהתמקד בכשלים החשובים יכולה לחסוך עבודה ידנית משמעותית.AI ובדיקות עומסיםבתחום בדיקות העומסים, נחום מספר על פלטפורמה חדשה של CloudBeat המשלבת סוכן המסייע ביצירת בדיקות באמצעות JMeter או K6.באמצעות הקלטה של פעילות המשתמש, המערכת יכולה לזהות תהליכים עסקיים, לחלק את התסריט בצורה נכונה וליישם Best Practices של בדיקות עומסים – כולל פרמטרים, זמני המתנה, משתנים דינמיים ומבנה נכון של התסריט.החזון הוא להפוך גם את הגדרת העומס עצמה לחכמה יותר: לשאול את המשתמש שאלות לגבי מספר משתמשים, זמני Session והתנהגות בפועל, ואולי אף להשתמש במידע ממערכות Analytics כדי לסייע בהגדרת תרחיש עומס מציאותי.ומה לגבי Mobile?הפרק עוסק גם בבדיקות ביצועים ועומסים באפליקציות מובייל.כאן חשוב שוב להפריד בין Performance לבין Load. בבדיקות ביצועים של אפליקציית Mobile קיימים מדדים נוספים הקשורים למכשיר עצמו ולשימוש במשאבים וביכולות כגון מיקום ורכיבי חומרה.בבדיקות עומסים, לעומת זאת, המטרה היא בדרך כלל לייצר עומס על השרת ולא על מכשיר הטלפון. לכן ניתן במקרים מסוימים לעבוד ברמת ה-API ואף להשתמש ב-Postman Collection כבסיס, בתנאי שהוא מייצג בצורה מלאה את הבקשות והתהליכים העסקיים של האפליקציה.האם כדאי לאנשי QA ללמוד Performance Testing?לקראת סוף הפרק עולה שאלה חשובה במיוחד עבור אנשי בדיקות שמחפשים דרך לבדל את עצמם בשוק העבודה.לדברי נחום, בדיקות ביצועים ועומסים הן תחום טכני שדורש הבנה של ארכיטקטורת מערכות, תשתיות, ענן, Load Balancing ורכיבים נוספים. איש הביצועים אינו בהכרח המומחה בכל אחת מהטכנולוגיות, אך הוא צריך לדבר בשפה משותפת עם אנשי התשתיות, הפיתוח, ה-DBA וגורמים מקצועיים נוספים.מעבר לצד הטכני, מדובר גם בתפקיד של אורקסטרציה: לחבר בין אנשי המקצוע, להוביל את תהליך החקירה ולסייע להגיע ל-Root Cause של בעיות הביצועים.דווקא מכיוון שמספר אנשי המקצוע המתמחים בתחום אינו גדול, מדובר בתחום שיכול להוות התמחות נוספת עבור אנשי QA שרוצים להרחיב את היכולות שלהם ולבדל את עצמם מקצועית.AI עוזר – אבל האדם עדיין בתמונהלמרות ההתקדמות הגדולה ב-AI, המסר שעולה מהשיחה הוא שהטכנולוגיה אינה מבטלת את הצורך בידע ובניסיון אנושי.AI יכול לסייע ביצירת תסריטים, ניתוח כמויות גדולות של מידע, איתור כשלים ותיקון אוטומטי, אך עולם הביצועים דורש גם הבנה מערכתית, תקשורת בין צוותים, יכולת ניתוח והבנה של ההקשר העסקי והטכנולוגי.השורה התחתונהבדיקות ביצועים ועומסים הן לא משהו שצריך להיזכר בו רגע לפני העלייה לאוויר. הן צריכות להיות חלק מתהליך הפיתוח והתכנון של המערכת כבר בשלבים מוקדמים.המעבר לענן, העלייה במורכבות המערכות והכניסה המהירה של כלי AI הופכים את התחום לרלוונטי מתמיד. הכלים משתנים והאוטומציה הופכת לחכמה יותר, אבל היכולת להבין את המערכת, להגדיר נכון את הבדיקה, לנתח את התוצאות ולחבר בין האנשים הנכונים נשארת קריטית.פרק מקצועי ומעמיק לכל מי שעוסק ב-QA, אוטומציה, Performance, תשתיות וענן – וגם למי שמחפש את ההתמחות הבאה שלו בעולם הבדיקות.קישור לפרופיל לינקדאין של נחום: https://www.linkedin.com/in/ndimer/קישור לפרופיל חברת CloudBeat: https://cloudbeat.ioקישור לפרופיל לינקאין של ניצן: https://www.linkedin.com/in/ngqa/קישור לפרופיל לינקדאין של נתנאל: https://www.linkedin.com/in/netanel-harush/קישור לקבוצת הוואצאפ השקטה של ITCB: https://bit.ly/TestIL_Whatsapp 

פרק 87 – מ-Vibe Coding לאוטומציה חכמה: סיפור מהשטחבפרק 87 של הפודקאסט של TestIL מבית ITCB, ניצן גולדנברג מארח את רם רחמים ולס טל, מפתח אוטומציה ואיש AI, לשיחה מעשית על הדרך שבה כלי AI ו-Vibe Coding משנים את עולם האוטומציה ובדיקות התוכנה.במרכז הפרק עומד Case Study אמיתי מהשטח: ניסיון לבנות מערכת שמאפשרת למשתמשים לכתוב תרחישי בדיקה בשפה טבעית ולהפוך אותם להרצות אוטומטיות – גם ללא ידע משמעותי בכתיבת קוד.רם משתף במסע שהתחיל עם Playwright MCP, בקשיים ובחוסר היציבות שהתגלו בדרך, ובנקודה שבה הבין שצריך לעצור ולא להמשיך "לזרוק פרומפטים" על הבעיה. המחקר אחר חלופה הוביל אותו ל-Stagehand, שאפשר לו להגיע לתוצאות יציבות ומדויקות יותר עבור ה-POC שפיתח.השיחה נוגעת גם באחד העקרונות החשובים ביותר בעבודה עם Vibe Coding: לא להתחיל מהקוד – להתחיל מהתכנון. עבודה ב-Plan Mode, הגדרת ארכיטקטורה, בניית Knowledge Base, כתיבת Rules ומתן הקשר נכון לסוכן יכולים לעשות את ההבדל בין פרויקט שהולך ומסתבך לבין פתרון שניתן להמשיך ולפתח.במהלך הפרק אנחנו מדברים גם על חשיבותם של Logs בעבודה עם סוכני AI, על Prompt Engineering וכלכלת טוקנים, ועל הדרך שבה אפשר לבצע הרצה ראשונית בעזרת LLM ולאחר מכן להפוך את התרחיש לקוד Playwright רגיל שניתן להריץ שוב ללא שימוש נוסף בטוקנים.אבל האם באמת אפשר לתת ל-AI לכתוב לנו את האוטומציה?רם וניצן מדברים על הצורך ב-Human Review וב-Code Review גם בעידן הסוכנים: לבדוק שהקוד עומד בקונבנציות של הפרויקט, שלא נוצרות פונקציות כפולות, שה-Locators יציבים, שאין טסטים מיותרים ושקוד שנוצר על ידי AI לא נכנס אוטומטית ל-Repository בלי בקרה.השיחה ממשיכה גם לעתיד המקצוע: האם בודקים ידניים וג'וניורים יוכלו ליצור אוטומציה באמצעות שפה טבעית? האם בעתיד נכתוב פחות Test Cases ויותר Intentions ו-Prompts? ומה הופך את איש האוטומציה ממי שכותב כל שורת קוד בעצמו למי שמתכנן, מנחה, מבקר ומנהל סוכני AI?בין הנושאים בפרק:Vibe Coding בעולם הבדיקות והאוטומציהPlaywright MCP מול Stagehandבניית אוטומציה באמצעות שפה טבעיתPlan Mode לפני Agent Modeחשיבות הארכיטקטורה גם כש-AI כותב את הקודLogs ככלי מרכזי להבנת התנהגות הסוכןKnowledge Base ו-Rules לסוכני AIPrompt Engineering וחיסכון בטוקניםיצירת קוד Playwright מתרחיש שנוצר באמצעות AICode Review לקוד שנכתב על ידי סוכניםמניעת Flaky Tests ו-Locators לא יציביםשילוב AI בתהליכי Git, Pull Requests ו-Code Reviewשימוש בסוכנים לחקירת תקלות וכישלונות אוטומציההאפשרות לבנות "Super Agent" שמפקח על סוכנים אחריםתפקידו המשתנה של מפתח האוטומציההמיומנויות שבודקי תוכנה צריכים להתחיל לפתח כבר היוםאחד המסרים המרכזיים שעולים מהפרק הוא שה-AI אינו מבטל את הצורך בידע מקצועי – הוא משנה את המקום שבו אנחנו משתמשים בו. במקום להשקיע את רוב הזמן בכתיבת קוד ידנית, אנשי הבדיקות והאוטומציה נדרשים יותר ויותר לדעת לתכנן, לתת הקשר, להגדיר חוקים, לבקר את התוצאה ולזהות מתי ה-AI טועה.והעצה של רם למי שעדיין עומד בצד? אל תנסו לרדוף אחרי כל כלי AI חדש שיוצא. בחרו כלי אחד או שניים, התנסו בהם לעומק, בנו משהו אמיתי ולמדו מתוך העשייה.🎙️ פרק 87 – סיפור מהשטח על AI, Vibe Coding והדור הבא של אוטומציית הבדיקות. קישור לפרופיל לינקדאין של רם: https://www.linkedin.com/in/ram-walas-tal-b1830770/קישור לקבוצת הוואצאפ השקטה של testil: https://bit.ly/TestIL_Whatsapp

🎙️ TestIL Podcast – פרק 86: האם AI יחליף את בודקי התוכנה?הבינה המלאכותית כבר משנה את הדרך שבה אנחנו מפתחים ובודקים תוכנה – אבל האם היא באמת בדרך להחליף את אנשי ה-QA, או דווקא להפוך אותם לאנשי מקצוע חזקים ויעילים יותר?בפרק 86 של פודקאסט TestIL, ניצן גולדנברג ומתנאל הרוש נפגשים לשיחה פתוחה על השינויים שעובר עולם בדיקות התוכנה בעידן ה-AI, ועל הפער שבין הכותרות שמכריזות ש"המקצוע עומד להיעלם" לבין מה שקורה בפועל בשטח.במהלך הפרק אנחנו מדברים על השינוי בתפקידו של הבודק, על השילוב בין בדיקות ידניות, אוטומציה ובינה מלאכותית, ועל הדרך שבה כלים כמו Claude, Cursor, Playwright, MCP ו-CLI מאפשרים לבצע היום בתוך דקות או שעות משימות שבעבר דרשו ימים ואפילו שבועות.אנחנו משתפים בדוגמאות אמיתיות מהעבודה: יצירת תשתיות וטסטים באמצעות AI, תכנון עשרות ומאות מקרי בדיקה, עבודה ישירה מול Jira ו-Xray, יצירת תיעוד ב-Confluence, פתיחת באגים אוטומטית עם לוגים וצילומי מסך ושימוש בסוכני AI לביצוע מספר משימות במקביל.אבל לצד היתרונות, אנחנו עוסקים גם בשאלה החשובה יותר – האם אפשר באמת לסמוך על התוצרים של ה-AI?טסט שעובר לא בהכרח בודק את הדבר הנכון, כמות גדולה של מקרי בדיקה אינה בהכרח כיסוי איכותי, וגם כאשר AI מסוגל לכתוב קוד שעובד – עדיין נדרשת חשיבה מקצועית כדי להבין האם הקוד, הארכיטקטורה והבדיקות באמת נכונים.אנחנו מדברים גם על הסכנה להפוך ל-"Lazy Testers", על החשיבות של שמירת הידע המתודולוגי והחשיבה הביקורתית, ועל הדרך הנכונה להשתמש ב-AI ככלי ללמידה, סקירה והאצת העבודה – ולא כתחליף להבנה המקצועית.ולבסוף אנחנו מסתכלים קדימה: איך ייראה תפקיד ה-QA בעוד חמש שנים? האם הבודק יהפוך יותר ויותר ל-AI Operator שמנהל סוכנים, תהליכים ואורקסטרציה? ואילו יכולות יצטרכו אנשי QA כדי להישאר רלוונטיים בעולם שבו חלק גדול מהעבודה הטכנית כבר יכול להתבצע עבורם?המסר המרכזי שלנו מהפרק פשוט:אל תפחדו מה-AI – תלמדו אותו, תתנסו בו ותשלבו אותו בעבודה. אבל אל תתנו לו להחליף את החשיבה שלכם.ה-AI כנראה לא יסיים את עולם הבדיקות – הוא פשוט משנה את הדרך שבה אנחנו עושים QA.קישור לפרופיל לינקדאין של ניצן: https://www.linkedin.com/in/ngqa/קישור לפרופיל לינקדאין של נתנאל: https://www.linkedin.com/in/netanel-harush/קישור לקבוצת הוואצאפ לעדכונים של ITCB: https://bit.ly/TestIL_Whatsapp 

פרק 85 – איך מכניסים AI לארגון בדיקות?בפרק 85 של הפודקאסט של TestIL מבית ITCB, נתנאל הרוש מארח את גיא דנביץ' לשיחה מעשית על אחת השאלות שמעסיקות כיום כמעט כל צוות QA: איך מכניסים בינה מלאכותית לתהליכי הבדיקות בארגון – ולא רק מדברים עליה?גיא משתף מניסיונו האישי בהטמעת כלי AI בתוך סביבת Enterprise, ומציג את ההזדמנויות הגדולות שמביאה הבינה המלאכותית לעולם הבדיקות, לצד האתגרים האמיתיים של אבטחת מידע, רגולציה, קונטקסט, אמינות ואישורים ארגוניים.מי הוא גיא דנביץ'?גיא נמצא בתחום בדיקות התוכנה למעלה משש שנים, לאחר שעשה הסבה מקצועית מעולם השיווק בתקופת הקורונה.כיום הוא עובד ב-Vonage, שנרכשה על ידי Ericsson, ועוסק בבדיקות של פלטפורמה בתחום התקשורת המשלבת יכולות AI ו-Agentic Workflows.במהלך השיחה הוא מסביר כיצד ניתן לבנות תהליכים וסוכנים המבוססים על LLM, וממחיש זאת באמצעות דוגמה של סוכן AI שיכול לנהל שיחה עם לקוח, להבין את כוונתו, לאסוף פרמטרים ולבצע עבורו פעולה – למשל הזמנת פיצה – במקום נציג אנושי.האם AI כבר יכול להחליף תהליכים שלמים?אחת הנקודות המרכזיות בפרק היא ההבדל בין שימוש ב-AI כדי להאיץ תהליך לבין שימוש בו כדי להחליף לחלוטין את האדם.לדברי גיא, בתחומים מסוימים – במיוחד בתהליכים פשוטים יחסית וב-Happy Flows – סוכני AI כבר מסוגלים לבצע פעולות במהירות וביעילות גבוהה מאוד.השילוב העמוק יותר של LLM במוצר שעליו עובד הצוות שלו אף הצליח לקצר משמעותית את תהליך בניית הסוכנים. תהליכים שבעבר דרשו עשרות Nodes יכולים כיום להיבנות באמצעות מספר קטן משמעותית של רכיבים.עם זאת, ככל שהתרחיש מורכב יותר ודורש הבנה של חריגים, הקשר עסקי, שיקול דעת או טיפול במקרה ייחודי של לקוח – הצורך באדם עדיין משמעותי.האתגר הגדול: קונטקסטנושא שחוזר לאורך הפרק הוא Context.LLM יכול לספק תשובה מצוינת – אבל רק בהתאם למידע שהוא מכיר. כאשר המודל אינו מכיר את המערכת, ה-Codebase, הארכיטקטורה, הדרישות העסקיות וההיסטוריה של המוצר, הוא עלול לספק תשובות שנשמעות משכנעות אך אינן נכונות.גיא משתף בדוגמאות משימוש ב-AI לצורך Debugging. במקרה אחד, לאחר שסיפק למודל מספיק רקע על המערכת וה-Backend, ה-AI הציע כיוון שהצוות לא חשב עליו – והוא אכן הוביל לפתרון הבעיה.במקרה אחר, ה-AI הציע הסבר שנשמע הגיוני לחלוטין, אך המפתחים מיד זיהו שהוא אינו רלוונטי כלל לאופן שבו המערכת שלהם עובדת.המסקנה: AI הוא כלי מצוין להצעת כיוונים, רעיונות ופתרונות – אבל הוא עדיין אינו תחליף לאדם שמכיר לעומק את המערכת, את הצד הטכני ואת הצד העסקי. איך AI כבר עוזר לבודקי תוכנה?בפרק מוצגים מספר שימושים מעשיים שכבר יכולים לקצר את עבודת הבודק:הבנה וסיכום של מסמכי דרישות ו-FRD מורכבים.הפקת סיכומים, אודיו, וידאו ואינפוגרפיקות ממסמכים באמצעות כלים כמו NotebookLM.סיוע בתכנון בדיקות וביצירת Test Cases.כתיבת SDD ראשוני.Debugging וניתוח תקלות.הצעת כיווני חקירה שלא בהכרח היו עולים מיד אצל הבודק או המפתח.בנייה ותחזוקה של בדיקות API.יצירת Collections וטסטים ב-Postman.יצירת תיעוד ל-API.שימוש ב-Agent Mode וב-MCP לצורך חיבור תהליכים וכלים.עם זאת, גיא מדגיש כי כל תוצר של AI עדיין דורש Human Review. ככל שהמערכת או הפיצ'ר מורכבים יותר, כך גדלה החשיבות של אימות התוצאה.Security, רגולציה והבעיה של ארגוני Enterpriseאחד החלקים המשמעותיים בפרק עוסק בפער שבין הרצון לתת ל-AI כמה שיותר קונטקסט לבין הצורך של הארגון להגן על המידע שלו.מצד אחד, ככל שנותנים למודל יותר מידע על המערכת, הוא מסוגל לספק תשובות מדויקות יותר.מצד שני, ארגון לא יכול בהכרח להעביר ל-LLM את כל ה-Codebase, מידע עסקי, מידע של לקוחות או נתונים רגישים.האתגר משמעותי במיוחד בארגונים גדולים ובתחומים מפוקחים כמו בנקאות, פיננסים וביטוח.לכן הכנסת כלי AI לארגון אינה החלטה טכנולוגית בלבד. היא דורשת התייחסות לשאלות של Security, Privacy, רגולציה, הרשאות וחשיפת מידע.איך גיא הצליח להכניס את יכולות ה-AI של Postman לארגון?אחד הסיפורים המרכזיים בפרק הוא התהליך שגיא עבר כדי לקבל אישור לשימוש ביכולות ה-AI של Postman.לאחר שגילה את יכולות ה-Agent Mode של Postman והבין שהן יכולות לסייע ב-Debugging, בבניית Tests ו-Collections, ביצירת Documentation ובאינטגרציות, הוא הציג את הרעיון לראש הצוות וקיבל תמיכה להתקדם.אלא שאז הגיע המחסום הארגוני: הכלי לא היה מאושר לשימוש.במקום לוותר, גיא החל לקדם תהליך אישור מסודר. הוא עבד מול הגורמים הרלוונטיים בארגון ומול אנשי Postman, אסף מסמכי אבטחה, השתתף בשיחות והציג גם את הערך העסקי והמקצועי של הכלי וגם את האופן שבו נשמר המידע.תהליך אישור מסוג זה יכול לדבריו להימשך כחצי שנה ואף יותר. במקרה שלו, בזכות עבודה אינטנסיבית וקידום הנושא מול הגורמים השונים, התהליך הסתיים בתוך כחודש.זהו גם אחד המסרים המרכזיים של הפרק: כדי להכניס AI לארגון לא מספיק למצוא כלי טוב – צריך לדעת להוכיח את הערך שלו ולתת מענה לחששות הארגוניים. האם AI באמת חוסך זמן בבדיקות?כן – אבל לא בצורה מוחלטת.גיא מתאר קיצור משמעותי בתהליכים כמו קריאה והבנה של מסמכי דרישות, מחקר ו-Debugging. פעולות שבעבר דרשו זמן רב ופינג-פונג בין אנשים יכולות כיום להתבצע מהר יותר.להערכתו, בחלק מהפעילויות מדובר בחיסכון של עשרות אחוזים.עם זאת, אנחנו עדיין לא נמצאים בשלב שבו ניתן לתת לסוכן AI את המשימה, ללכת לשתות קפה ולחזור כשהכול מוכן.האדם עדיין נדרש לבחון את התוצאות, להבין את הקונטקסט, לזהות טעויות ולקבל החלטות.לכן בשלב הנוכחי AI מקצר תהליכים יותר משהוא מבטל אותם.תשתית ה-AI בבדיקותגיא משתף גם בכלים ובתשתיות שבהם הצוות עושה שימוש כיום.אחד הכלים המרכזיים הוא Postman AI, שמשתלב בתשתית אוטומציית API קיימת ומאפשר לסייע ביצירת בדיקות, Collections, Debugging, Documentation ואינטגרציות.בנוסף, הצוות עושה שימוש ב-GitHub Copilot ומתחיל לעבוד עם Playwright ויכולות Agentic הקשורות אליו.עם זאת, גיא מדגיש שהם עדיין נמצאים בתהליך. אין עדיין סוכן אחד שמכיר את כל המערכת ומבצע את כל תהליך הבדיקות מקצה לקצה באופן אוטונומי.ה-Killer Feature: שילוב עמוק יותר של LLMבצד המוצר, גיא מספר על גרסת V3, שבה בוצעה אינטגרציה עמוקה יותר עם LLM.השילוב מאפשר למערכת להבין בצורה טובה ומהירה יותר את כוונת המשתמש ולפשט משמעותית את בניית ה-Workflow של הסוכן.לדוגמה, תהליך שבעבר היה דורש כ-30 Nodes עשוי כעת להיבנות באמצעות כ-15 בלבד – קיצור של כ-50%.בצד הבדיקות, אחת היכולות הבולטות מבחינתו היא Agent Mode של Postman, שמאפשר באמצעות הנחיות בשפה טבעית לבנות Collections, ליצור Tests, לבצע Debugging, לכתוב Documentation ואף לעבוד עם MCP וכלים חיצוניים.אז האם אנחנו בדרך ל-Autopilot של QA?עדיין לא.לדברי גיא, כדי שסוכן AI יוכל באמת לבצע חלק גדול מתהליך הבדיקות באופן עצמאי, הוא יצטרך להכיר את כל האקוסיסטם: המוצר, הארכיטקטורה, ה-Codebase, הדרישות, ההיגיון העסקי וההקשרים הטכניים.מבחינה טכנולוגית אנחנו מתקדמים לשם, אבל בארגוני Enterprise קיימת בעיה נוספת: גם אם ניתן לתת ל-AI את כל המידע הזה – לא בטוח שהארגון יסכים לעשות זאת.לכן בשלב הנוכחי AI חזק במיוחד ב- Research, Analysis, Assistance ו-Acceleration, אך עדיין פחות מתאים לקבלת אחריות מלאה על תהליך הבדיקות.המסר לבודקים ולמנהליםלקראת סיום הפרק גיא מעביר מסר ברור לבודקי תוכנה:אל תפחדו לנסות.אם אתם מאמינים שכלי או טכנולוגיה יכולים לשפר את העבודה שלכם – חקרו אותם, הציגו אותם בארגון והסבירו מדוע הם יכולים לייצר ערך.גם אם התשובה הראשונית היא "לא", נסו להבין מדוע. אם הבעיה היא Security, הביאו מסמכים והוכחות. אם הבעיה היא ערך עסקי, הציגו את החיסכון והיתרונות.ולמנהלים המסר הוא להשאיר מקום ליוזמות כאלה: כאשר עובד מגיע עם רעיון שהוא מאמין בו, לא למהר לפסול אותו אלא לאפשר לו לבדוק, לחקור ולהוכיח את הערך.עולם הבדיקות משתנה במהירות. Agents, MCP, יכולות AI ב-Postman, כלי פיתוח מבוססי AI ופתרונות חדשים נוספים נכנסים לעבודה בקצב גבוה – והתפקיד של אנשי QA משתנה יחד איתם.המסר האחרון מהפרקהמסר של גיא חורג בסופו של דבר מעולם ה-AI וה-QA:אל תפחדו להעיז, תאמינו במה שאתם עושים ואל תוותרו רק בגלל שקיבלתם "לא". לפעמים "לא" הוא פשוט השלב הראשון בדרך ל"כן".פרק 85 מציג תמונה מפוכחת ומעשית של שילוב AI בעולם הבדיקות: לא קסם שמחליף את הבודק בלחיצת כפתור, אלא כלי רב-עוצמה שיכול לקצר תהליכים, לשפר מחקר, לסייע ב-Debugging, לייצר בדיקות ולהפוך אנשי QA ליעילים יותר – בתנאי שיודעים להשתמש בו נכון, לספק לו את הקונטקסט המתאים, לבדוק את התוצרים שלו ולשמור על גבולות האבטחה והמידע של הארגון.

ניצן בלי פילטרים - הדרך שלא תכננתי – והקריירה שבניתיבפרק מיוחד ואישי של פודקאסט TestIL מבית ITCB, התפקידים מתחלפים: הפעם נתנאל הרוש יושב בכיסא המראיין, וניצן עובר מהצד שמגיש ושואל את השאלות – אל הצד שמספר את הסיפור שלו.זהו לא פרק שעוסק בטכנולוגיה מסוימת, כלי חדש או מתודולוגיית בדיקות. זהו פרק על דרך. על שינוי קריירה, על משפחה, על החלטות לא פשוטות, על התמדה, על הזדמנויות שמגיעות לפעמים מהמקומות הכי לא צפויים – ובעיקר על האמונה שאין מסלול אחד נכון להצלחה.לפני ה-QA: קריירה של כמעט 20 שנה בעולם המלונאותהרבה לפני עולם בדיקות התוכנה, ניצן בכלל בנה קריירה בעולם אחר לחלוטין – עולם המלונאות והקולינריה.הוא למד בישול ומלונאות, הוסמך כשף והתחיל את דרכו המקצועית מהמטבח. לאורך השנים התקדם מתפקידי בישול וניהול מטבחים אל עולם הפרונט של בתי המלון – קבלה, ניהול מחלקות ובהמשך גם תפקידי ניהול בכירים וניהול בתי מלון.מבחינה מקצועית זו הייתה התקדמות משמעותית, אבל לעולם המלונאות היה מחיר: ימים ארוכים מאוד, משמרות, סופי שבוע וחגים וכמעט אפס הפרדה בין העבודה לבין החיים האישיים.הרגע שהוביל לשינוינקודת המפנה הגיעה לאחר לידת בנו, דניאל.באותה תקופה ניצן עבד שעות ארוכות מאוד. הוא יצא מהבית מוקדם בבוקר, חזר לעיתים בשעות הלילה המאוחרות, ויום אחרי יום מצא את עצמו כמעט לא רואה את המשפחה.כאשר התברר שבנו מתמודד עם עיכוב בהתפתחות הדיבור ונדרש גם לטיפול רפואי, ניצן הבין עד כמה הוא למעשה לא נמצא בבית ולא מעורב מספיק בחיי המשפחה.הוא פנה לבעלת המלון שבו עבד וביקש להפחית את היקף השעות. התגובה שקיבל הפכה לרגע שהוא זוכר עד היום: מבחינתה, הוא נשכר כדי שהיא תוכל "לשבת רגל על רגל".באותו רגע, בלי תוכנית מסודרת לעתיד ובלי עבודה אחרת שמחכה לו, הוא הניח את מפתחות המלון על השולחן והתפטר.לפעמים שינוי משמעותי בחיים אינו מתחיל מתוכנית מפורטת. לפעמים הוא מתחיל בהחלטה אחת ברורה לגבי מה באמת חשוב.מתחילים מחדשאחרי כמעט שני עשורים בתחום שבו כבר צבר ניסיון, ידע ותפקידים בכירים, ניצן מצא את עצמו מתחיל לחשוב על קריירה חדשה לחלוטין.בהתחלה הוא אפילו שקל ללמוד עיצוב גרפי, אבל שיחה עם אדם שהכיר ושעבר בעצמו לתחום בדיקות התוכנה גרמה לו להתחיל לחקור את עולם ה-QA.הוא התחיל לקרוא, לחפש בפורומים ולבדוק מה בעצם עושים בעולם הבדיקות. ככל שנחשף יותר לתחומים כמו SQL, מובייל, אוטומציה וקוד – כך גדלה הסקרנות.תוך זמן קצר הוא נרשם לקורס בדיקות תוכנה מלא, שכלל גם הכנה להסמכת ISTQB, וקיבל החלטה להשקיע בשינוי הזה עד הסוף.לעבוד, ללמוד – ולא לוותרבתקופת הלימודים ניצן חזר זמנית למקום שאותו הכיר היטב: המטבח.הוא החל לעבוד במטבח של אינטל בחיפה, מתוך תקווה שלאחר השלמת הלימודים יוכל אולי להשתלב בתוך החברה בתפקיד טכנולוגי.התקופה הזו הייתה רחוקה מלהיות קלה.בימים שבהם התקיימו הלימודים הוא התחיל לעבוד כבר בארבע לפנות בוקר, סיים אחר הצהריים, עלה על אוטובוס והמשיך ישירות ללימודים עד שעות הערב. לאחר שחזר הביתה המשיך ללמוד עוד שעות, ובסופי השבוע הקדיש זמן נוסף לתרגול.המטרה הייתה ברורה: אם כבר מבצעים שינוי מקצועי משמעותי אחרי כל כך הרבה שנים – צריך לעשות אותו ברצינות.שיעור אחד ב-SQL ששינה את הביטחון העצמיאחד הסיפורים המשמעותיים בפרק מגיע דווקא מתקופת הלימודים.במקביל ללימודי המתודולוגיה וההכנה ל-ISTQB, ניצן למד SQL – ובתחילת הדרך פשוט לא הצליח להבין כיצד לכתוב את השאילתות.במקום להחליט שזה "לא בשבילו", הוא הקדיש שבת שלמה ללימוד.הוא לקח את חומרי הקורס, הסתגר בחדר, עבר מחדש על הנושאים, סיכם כל פעולה במילים שלו ותרגל שוב ושוב את התרגילים.בשיעור הבא המרצה נתן תרגיל נוסף. הפעם ניצן היה הראשון שהרים את היד – ופתר אותו.זה אולי נשמע כמו רגע קטן, אבל מבחינתו זו הייתה נקודת מפנה: אם משהו שאתמול נראה בלתי אפשרי הפך לאפשרי בזכות השקעה ותרגול, אין סיבה שלא יוכל להתמודד גם עם האתגרים הבאים.זו גם אחת התובנות שהוא מעביר כיום לסטודנטים שלו: לתרגל, לנסות, להיכשל, ללמוד ולנסות שוב.הכניסה הראשונה להייטק – דווקא דרך הדלת האחוריתלאחר סיום הלימודים התחיל ניצן לשלוח קורות חיים ולחפש את ההזדמנות הראשונה שלו בעולם הטכנולוגיה.ואז הגיעה משרה שהייתה כמעט אירונית.אחרי שכל כך רצה לצאת מעולם המלונות, החברה שחזרה אליו עבדה על מערכת לניהול בתי מלון.המשרה המקורית כלל לא הייתה תפקיד QA קלאסי, אלא תפקיד שעסק בהטמעת מערכות ותמיכה טכנית. אלא שבדיוק כאן התחברו שני העולמות שלו: מצד אחד כמעט 20 שנות ניסיון במלונאות, ומצד שני הכשרה חדשה בבדיקות תוכנה.במהלך הראיון זיהו בחברה את השילוב הייחודי הזה והציעו לו הזדמנות שלא תוכננה מראש: להקים את תחום הבדיקות של המערכת מאפס.וכך, כבוגר קורס ללא ניסיון קודם בתפקיד QA, ניצן קיבל את ההזדמנות הראשונה שלו.הוא ביצע תמיכה והטמעות בבתי מלון, ובמקביל התחיל לבנות את תהליך הבדיקות: ללמוד את המערכת, לתכנן מקרי בדיקה, לתעד אותם ובהמשך גם להכניס מערכת לניהול בדיקות.דווקא התחום שממנו ניסה להתרחק הפך לגשר שאפשר לו להיכנס לעולם החדש.אין לכם ניסיון ב-QA? אולי יש לכם ניסיון חשוב יותרמתוך הסיפור הזה עולה אחת התובנות החשובות ביותר בפרק עבור אנשים שמנסים להיכנס לתחום.חוסר ניסיון בבדיקות תוכנה אינו אומר שאין לכם ניסיון רלוונטי.אדם שמגיע מבנקאות, ביטוח, רפואה, מסחר, תיירות, מלונאות או כל תחום מקצועי אחר מביא איתו ידע עסקי ו-Domain Knowledge שיכול להיות בעל ערך עצום עבור חברות המפתחות מערכות לאותו עולם תוכן.במקום למחוק את הקריירה הקודמת כאשר עושים הסבה מקצועית, כדאי לחשוב כיצד ניתן להפוך אותה ליתרון.ההשקעה בשנים הראשונותהעבודה הראשונה בתחום לא הייתה נוחה.ניצן התגורר בצפון והמשרה הייתה באזור המרכז, כך שכל יום כלל נסיעות ארוכות מאוד – רכבת מוקדמת בבוקר, המשך באוטובוס וחזרה הביתה בשעות מאוחרות.גם השכר לא היה הסיבה לעשות את המהלך.המטרה האמיתית הייתה לצבור ניסיון ולהוכיח את עצמו בשנה-שנתיים הראשונות.מבחינתו, ההזדמנות לקבל ניסיון אמיתי הייתה השקעה בעתיד המקצועי שלו.להתאהב בבדיקותכאשר נתנאל שואל את ניצן האם אי פעם שקל לעזוב את עולם הבדיקות, התשובה שלו חד-משמעית: לא.כבר בתחילת הדרך הוא התחבר מאוד למקצוע.במשך שנים רבות המיקוד שלו היה בעיקר בבדיקות ידניות והוא אפילו לא התחבר במיוחד לעולם הקוד. רק בשנים האחרונות חזר אליו, התחיל לעסוק יותר בפיתוח וב-Vibe Coding וגילה הערכה חדשה לעולם הזה.אבל החיבור לבדיקות עצמן נשאר לאורך כל הדרך.האם AI הולך להחליף את אנשי הבדיקות?השיחה מגיעה באופן טבעי גם לשאלה שמטרידה כיום לא מעט אנשי QA: מה יקרה למקצוע בעקבות כניסת הבינה המלאכותית?ניצן משתף שגם הוא חווה לאחרונה פיטורים בעקבות צמצומים ושינויים ארגוניים, ואף עבד ביותר מחברה אחת שבה הוחלט להעביר חלק מאחריות הבדיקות לצוותי הפיתוח.למרות זאת, הוא אינו מאמין שה-AI יבטל את מקצוע הבדיקות.לדבריו, העבודה עם כלי AI מראה שהטכנולוגיה מסוגלת להאיץ משמעותית חלקים גדולים מעבודת הבודק: ניתוח דרישות ומסמכים, יצירת רעיונות לבדיקות, כתיבת מקרי בדיקה, יצירת דיווחי באגים, כתיבת קוד ואפילו חיבור לכלים כמו Jira באמצעות MCP.אבל AI עדיין זקוק לאדם שמכוון אותו, בוחן את התוצאות, נותן הקשר מקצועי ומקבל החלטות.בנוסף, קיימים תחומים שבהם האלמנט האנושי ממשיך להיות משמעותי במיוחד – למשל חוויית משתמש, שימושיות, נגישות והיבטים שונים של בדיקות מובייל.ההשוואה שעלתה בפרק היא לאוטומציה: לפני שנים נאמר שאוטומציה תחליף את הבודקים הידניים. בפועל היא לא העלימה אותם – אלא שינתה את אופי העבודה ופינתה זמן לעיסוק במשימות אחרות.כך גם עם AI.המקצוע משתנה, וחלק מהתפקידים משתנים יחד איתו. במקביל נוצרים תפקידים וכיוונים חדשים כמו AI-Driven Test Engineer – אנשי בדיקות שיודעים לעבוד יחד עם AI, לנהל Agents ולהשתמש בהם כחלק מתהליך הבדיקות.הבודק של העתיד מנהל גם את ה-AIאחת התובנות המרכזיות בשיחה היא שה-AI אינו "עובד עצמאי" שמחליף את איש הבדיקות.אפשר לחשוב על Agent כעל עובד נוסף בצוות: הוא יכול לבצע משימות רבות במהירות, אבל מישהו עדיין צריך להגדיר לו מה לעשות, לספק לו את ההקשר, לבקר את העבודה שלו ולהחליט האם התוצאה מספיק טובה.לכן, במקום לפחד מהטכנולוגיה, אנשי בדיקות צריכים ללמוד כיצד להשתמש בה כדי להפוך לאנשי מקצוע טובים ואפקטיביים יותר.מכאן התחילה גם הקהילהעם הזמן האהבה של ניצן למקצוע הפכה למשהו גדול יותר מהעבודה עצמה.באחד הימים הוא ראה פוסט בפורום בדיקות תוכנה שבו קובי הלפרין סיפר על מפגש קטן שקיים עם מספר אנשי בדיקות – מפגש שבו פשוט ישבו ודיברו על המקצוע.ניצן שאל שאלה פשוטה: למה לא מארגנים מפגשים כאלה?התשובה הייתה פשוטה לא פחות: כי אף אחד עדיין לא הרים את הכפפה.אז ניצן החליט להרים אותה.כשבועיים לאחר מכן התקיים אחד המפגשים הראשונים שאירגן. הגיעו אליו כ-15 אנשי בדיקות, והתקיימה הרצאה מקצועית בחדר ישיבות של חברה שאירחה את המשתתפים.במונחים של היום, שבהם מיטאפים יכולים למשוך עשרות ומאות משתתפים, 15 אנשים אולי נשמעים מעט. אבל באותה תקופה זו הייתה התחלה משמעותית.ומשם החל להתפתח מסלול נוסף בקריירה של ניצן – העשייה למען קהילת הבדיקות.מה אפשר לקחת מהסיפור הזה?הפרק הזה הוא הרבה יותר מסיפור קריירה בתחום ה-QA.זהו סיפור על אדם שעזב קריירה של כמעט שני עשורים והתחיל מחדש. על החלטה שהתחילה מהרצון להיות יותר נוכח עבור המשפחה, על כניסה לתחום חדש בלי רקע טכנולוגי משמעותי, על ימים ארוכים של עבודה ולימודים, על נסיעות של שעות כדי לקבל את ההזדמנות הראשונה ועל ההתעקשות להמשיך גם כשנושאים כמו SQL נראו בהתחלה בלתי אפשריים.זה גם סיפור שממחיש שלפעמים הקריירה הקודמת שלנו אינה משהו שצריך להשאיר מאחור – היא יכולה להיות בדיוק הדבר שיפתח עבורנו את הדלת לקריירה הבאה.ובעיקר, זהו סיפור על אהבה למקצוע.אהבה שהתחילה משינוי אישי, הפכה לקריירה, ובהמשך גם לרצון ללמד, לשתף ידע, ליצור מפגשים מקצועיים ולקדם את קהילת בדיקות התוכנה.אם הצלחתי ללמוד משהו שלא ידעתי, להתמודד עם משהו שהיה קשה לי ולבנות לעצמי דרך חדשה – אין סיבה שאחרים לא יוכלו לעשות את זה גם.אם אתם נמצאים היום בתחילת הדרך, שוקלים הסבה מקצועית, מחפשים את ההזדמנות הראשונה שלכם או פשוט נמצאים בנקודה שבה אתם תוהים מה הצעד הבא – הפרק הזה הוא תזכורת חשובה לכך שלא תמיד צריך לדעת מראש איך תיראה כל הדרך.לפעמים צריך פשוט להתחיל ללכת.האזנה נעימה 🎧קישור לפרופיל לינקדאין של ניצן: https://www.linkedin.com/in/ngqa/מייל: [email protected] מס נייד: 052-6718757קישור לקבוצת העדכונים של ITCB בוואצאפ: https://bit.ly/TestIL_Whatsapp