TestIL Podcast

Episódios

• 
  פרק מס 87 | מקרה בוחן מהשטח: המעבר מארכיטקטורה כושלת למהפכת ״ווייב קודינג״ 20.09.2026 58min

  פרק 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
• 
  פרק #86: ניצן ונתנאל אחד על אחד: איפה הבודקים בעידן הבינה מלאכותית 05.09.2026 1h 8min

  🎙️ 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 | הטמעת בינה מלאכותית בארגון - מכאוס לתוצאה אמיתית עם גיא דנביץ 23.08.2026 29min

  פרק 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 ליעילים יותר – בתנאי שיודעים להשתמש בו נכון, לספק לו את הקונטקסט המתאים, לבדוק את התוצרים שלו ולשמור על גבולות האבטחה והמידע של הארגון.
• 
  פרק #84 | ניצן בלי פילטרים - הדרך שלא תכננתי – והקריירה שבניתי 08.08.2026 54min

  ניצן בלי פילטרים - הדרך שלא תכננתי – והקריירה שבניתיבפרק מיוחד ואישי של פודקאסט 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
• 
  פרק #83 | בדיקות אבטחה משולבות בינה מלאכותית 25.07.2026 45min

  body { font-family: 'Segoe UI', Arial, sans-serif; background-color: #f4f6f9; color: #333; direction: rtl; text-align: right; margin: 0; padding: 20px; } .container { max-width: 850px; margin: 0 auto; background: #ffffff; padding: 40px; border-radius: 12px; box-shadow: 0 4px 15px rgba(0, 0, 0, 0.05); } header { border-bottom: 3px solid #0d6efd; padding-bottom: 20px; margin-bottom: 30px; text-align: center; } h1 { color: #0d6efd; font-size: 2rem; margin-bottom: 10px; } .subtitle { font-size: 1.1rem; color: #555; margin: 0; } .meta-info { display: flex; justify-content: space-around; flex-wrap: wrap; background-color: #e7f1ff; padding: 15px; border-radius: 8px; margin-bottom: 30px; border-right: 5px solid #0d6efd; } .meta-item { margin: 5px 10px; } .meta-item strong { color: #0b5ed7; } h2 { color: #0b5ed7; border-right: 4px solid #00d2ff; padding-right: 12px; margin-top: 30px; margin-bottom: 15px; font-size: 1.4rem; } p { line-height: 1.8; margin-bottom: 15px; } ul { margin-bottom: 20px; padding-right: 20px; } li { line-height: 1.8; margin-bottom: 8px; } blockquote { background-color: #f8f9fa; border-right: 4px solid #0d6efd; margin: 25px 0; padding: 15px 20px; font-style: italic; border-radius: 0 8px 8px 0; } footer { margin-top: 40px; padding-top: 20px; border-top: 1px solid #dee2e6; text-align: center; font-size: 0.9rem; color: #6c757d; }בדיקות אבטחה משולבות בינה מלאכותית עם אמיר פלס מנחה: נתנאל ארושאורח: אמיר פלס (סגן נשיא בכיר טכנולוגיות ופיתוח, רדואר) חסות: העמותה לקידום מקצוע בדיקות והסמכות בישראל רקע ואודות האורח והחברהאמיר פלס מכהן כסגן נשיא בכיר טכנולוגיות ופיתוח בחברת רדואר. הוא נמצא בחברה כ-30 שנה ומוביל ברמה הגלובלית את כל נושא ההטמעה הטכנולוגית, ארגון פרי-סיילס (טרום-מכירה), הארכיטקטים, הניתוח וההסמכה מול הלקוחותההתפתחות של חברת רדואר לאורך השנים תחום איזון עומסים והנדסת תנועת רשת, שממנו יצאה החברה להנפקה בבורסת נאסד"ק כניסה לעולמות אבטחת הסייבר והגנה על רשתות הגנה עמוקה על יישומים (אפליקציות)אספקת שירותי ענן ותשתיות מרכזי נתונים הגנה על עולם ממשקי התכנות  והלוגיקה העסקית הגנה על מערכות בינה מלאכותית, סוכנים חכמים ועובדים המשתמשים בבינה מלאכותיתהשפעת הבינה המלאכותית על שוק העבודה ופיתוח תוכנהבשיחה הועלו תרחישים עתידיים לגבי השפעת הבינה המלאכותיתחזון מול מציאות: למרות תחזיות קיצוניות (כמו הערכות של מנכ"לים בתעשייה על החלפת רוב מכריע של כותבי הקוד בבינה מלאכותית במציאות היא משמשת כלי עזר עוצמתי ולא תחליף מלא לגורם האנושישיפור תפוקה ועבודה: בצוותים של רדואר, הבינה המלאכותית מבצעת כ-80% מהעבודה ב-20% מהזמן. תהליכים שלקחו בעבר מספר חודשים מתקצרים ליומיים-שלושה באמצעות כלי בינה מלאכותית לאפיון, כתיבת קוד ובדיקותשימושים בארגון: הטכנולוגיה נכנסה לשימוש רחב אצל מפתחים, במחלקות משפטיות, כספים, שיווק וניהול]. כלי סיוע (כדוגמת קו-פיילוט) מסייעים בסיכום שיחות, ניהול דואר אלקטרוני ומשימותמיצוב יחסי: ארצות הברית וסין מובילות בפיתוח מודלי השפה והחומרה, בעוד שישראל מתמקדת בפתרונות אבטחת סייבר ותשתיות חומרה מתקדמותאיומי אבטחה ייחודיים בסביבות בינה מלאכותיתהטמעת הבינה המלאכותית בתוך הארגון ומול בסיסי הנתונים וממשקי התכנות פותחת אפיקי תקיפה וסיכונים חדשים (הדורשים הגנה מעבר למעקבי בטיחות בסיסיים)הזרקת הנחיות ישירה ניסיונות של משתמשים לבצע מניפולציה ישירה על המודל כדי לחלץ מידע חסוי או לעקוף מגבלותהזרקת הנחיות עקיפה איום חמור וסמוי שבו הוראות זדוניות מושתלות בתוך קבצים חיצוניים (טקסט לבן על רקע לבן, תמונות או דואר אלקטרוני). כאשר סוכן הבינה המלאכותית סורק את המידע ממערכות האחסון הארגוניות, הוא מעבד את ההוראות הסמויות ועלול להדליף מידע ארגוני רגישאיומים בזמן ריצה וברמת המודל: הרעלת נתוניםושימוש לרעה בהרשאות של סוכנים אוטומטיים הפועלים במערכת.הפתרון של רדואר: הגנה בזמן ריצה (Runtime Protection)אמיר פלס מבהיר כי כלים לאיתור חולשות בקוד מסייעים במניעת באגים מראש אך רוב ההתקפות מנצלות בעיות התנהגותיות ולא רק כשלים בקודניתוח התנהגותי דינמי: במקום להתבסס רק על חוקים קשיחים או גבולות מוגדרים מראש, רדואר משתמשת באלגוריתמים מתמטיים מתקדמים המזהים דפוסי התנהגות חריגים ולומדים את דפוסי ההתנהגות הלגיטימיים של הלוגיקה העסקית והסוכנים: 1זיהוי הפער בין כוונה לביצוע: המערכת מזהה מתי ה"כוונה" של המודל עברה מניפולציה בזמן אמת ועוצרת את ההתקפה באופן מיידי בזמן ריצהרמת דיוק גבוהה: בעוד הממוצע בתעשייה לזיהוי התקפות עומד על כ-80%-90%, הפתרונות של רדואר מגיעים לרמות דיוק של 96%-98% הודות לשימוש בבינה מלאכותית לצורך חסימת איומי בינה מלאכותיתמודלים מתקדמים של בדיקות איכות ובדיקות אבטחה (Red Teaming)עולם הבדיקות ואימות המערכות עובר שינוי משמעותיצוותי תקיפה מבוססי סוכנים: הסטנדרט המוביל כיום בתעשייה מבוסס על פיתוח קבוצות של סוכני בינה מלאכותית הפועלים בשיתוף פעולהסימולציית תקיפה מורכבת: סוכן אחד מנסה לפרוץ ליישום, סוכן שני מייצר סוגי תקיפות שונים, והם משתפים מידע ביניהם (כגון שמות משתמש וסיסמאות שהושגו) כדי להמשיך בלחימה מול המערכת – בדומה לקבוצות תקיפה אנושיותלסיכום: הטמעת בינה מלאכותית בארגונים היא כורח המציאות המעלה את התפוקה, אך היא יוצרת שטח תקיפה חדש. הגנה אפקטיבית דורשת שילוב של בדיקות אבטחה מקיפות והגנה אקטיבית בזמן ריצה המבוססת על ניתוח התנהגותי
• 
  פרק #82| מהבאג הקטן לניהול מוצר עם זוהר פרנקור 19.07.2026 56min

  בואו לשמוע את ניצן ונתנאל מראיינים את זוהר על הדרך שעשה מבדיקות תוכנה לניהול מוצר בפרק שכולו מוטיבציהמ-QA לניהול מוצר, ממובייל ל-AI – המסע של זוהר פרנקורבפרק הזה אנחנו מארחים את זוהר פרנקור, איש מוצר עם רקע עשיר בעולם ה-QA, לשיחה על קריירה, קבלת החלטות, חדשנות והיכולת לזהות את הגל הבא לפני כולם.זוהר משתף כיצד נכנס לעולם בדיקות התוכנה לאחר משבר 2008, למה בחר להתמחות דווקא בבדיקות מובייל בתקופה שבה מעטים האמינו שהתחום יתפוס תאוצה, ואיך הבחירה הזו פתחה בפניו דלתות לתפקידי ניהול, הובלת צוותים ובניית תהליכי איכות ואוטומציה.בהמשך הוא מספר על המעבר לעולם ניהול המוצר, על העבודה בחברות בינלאומיות בגרמניה, על הקמת מחלקות QA ותהליכי אוטומציה, על המעבר לתפקידי Product Management ועל האתגרים שבבניית מוצרים בקנה מידה עולמי.השיחה נוגעת גם בהחלטה האמיצה לעבור עם המשפחה לקנדה, בהבדלים בין רילוקיישן להגירה, בהתמודדות עם חוסר הוודאות ובבניית קריירה מחדש במדינה חדשה.בחלק האחרון של הפרק זוהר מסביר מדוע בחר להתמקד כיום דווקא במוצרי AI, כיצד הוא מזהה מגמות טכנולוגיות כבר בשלבים מוקדמים, ומה לדעתו מנהלי מוצר ואנשי QA צריכים לעשות כדי להישאר רלוונטיים בעידן שבו בינה מלאכותית משנה את הדרך שבה מפתחים, בודקים ומנהלים מוצרים.בין הנושאים שעליהם דיברנו:איך מתחילים קריירה ב-QA גם ללא רקע טכנולוגי.היתרון שבהתמחות בתחום נישתי בזמן הנכון.המעבר מבדיקות תוכנה לניהול מוצר.בניית תהליכי איכות ואוטומציה בארגונים גלובליים.עבודה בגרמניה ובקנדה והבדלי התרבות המקצועית.המעבר לפרילנס ולייעוץ בתחום ניהול המוצר.למה AI הוא התחום הבא שכל איש מוצר ואיש QA חייב להכיר.פרק מעורר השראה על קריירה, אומץ לבצע שינויים, חשיבה אסטרטגית והיכולת לזהות הזדמנויות לפני שהן הופכות למיינסטרים. קישור לפרופיל לינקדאין של זוהר: https://www.linkedin.com/in/zoharf/לפרופיל לינקדאין של נתנאל: https://www.linkedin.com/in/netanel-harush/לפרופיל לינקדאין של ניצן: https://www.linkedin.com/in/ngqa/לקבוצת העדכונים: https://bit.ly/TestIL_Whatsappאל תשכחו להרשם לתחרות האוטומציה של ישראל: https://www.itac.co.il/ הפרק של היום בחסות סקיפר סופטסקיפר סופט הופכת את איכות התוכנה מצוואר בקבוק למנוע צמיחה.החל מאסטרטגיית בדיקות ואוטומציה, דרך שילוב בתהליכי הפיתוח וההפצה ועד לבדיקות ביצועים, הצוות של סקיפר בונה מערכי איכות גמישים וניתנים להרחבה עבור חברות טכנולוגיה שפועלות בקצב מהיר.באמצעות סוכני בדיקות מבוססי בינה מלאכותית, תהליכים אג׳נטיים ואוטומציה בעלת יכולות תיקון עצמי, סקיפר מסייעת לצוותים להרחיב את כיסוי הבדיקות, לשחרר גרסאות מהר יותר ולהפחית את עלויות הבדיקות.סקיפר סופט — הנדסת איכות לעידן הבינה המלאכותית.www.skipper-soft.comקישור לצפיית וידאו של הפרקhttps://www.youtube.com/embed/KvaCSCg_iGQ?si=-zt6f993QHFv8CVI 
• 
  פרק מס 81 | ראיון עם מוביל בדיקות - אלכס סטרוסברג 27.06.2026 59min

  QA Lead בצוותי פיתוח – איך מובילים איכות כשה-QA הוא חלק מהצוות?בפרק זה של פודקאסט TestIL מארח ניצן גולדנברג את אלכס סטרוסברג, QA Lead בחברת SAP, לשיחה מרתקת על הדרך המקצועית שלו, תפיסת האיכות בעולם הפיתוח המודרני והאתגרים שבהובלת תחום הבדיקות בתוך צוותי הפיתוח.אבל עוד לפני שמדברים על QA, אלכס משתף בסיפור האישי והמרגש שלו. בתו הצעירה נולדה עם תסמונת גנטית נדירה בשם Cornelia de Lange Syndrome, אירוע ששינה לחלוטין את מסלול חייו.מתוך ההתמודדות המשפחתית הוא ומשפחות נוספות הקימו עמותה הפועלת להעלאת המודעות למחלה, לתמיכה במשפחות ולקידום המחקר בישראל. אלכס מספר כיצד דווקא מתוך האתגר האישי נולדה תחושת שליחות גדולה יותר והסתכלות שונה על החיים ועל העבודה.הדרך לעולם הבדיקותאלכס מספר כיצד בתחילת שנות ה-2000, לאחר שסיים את לימודיו, חיפש את דרכו בעולם ההייטק. לאחר ראיונות רבים התקבל לצוות QA, וגילה במהרה שזהו התחום שמתאים לאופי שלו.הוא מסביר שתמיד אהב להבין כיצד מערכות עובדות, לפרק אותן לגורמים ולחשוב כיצד ניתן לשפר אותן. למרות שאהב תכנות, הוא פחות התחבר לכתיבת קוד אינטנסיבית ולכן מצא בעולם הבדיקות את השילוב המושלם בין חשיבה אנליטית, הבנת מערכות וטכנולוגיה.אלכס גם נזכר כיצד התחיל לעבוד עם כלים בסיסיים כמו Word ו-Excel לבדיקות, ומשווה זאת לעולם המודרני שבו בדיקות משלבות אוטומציה, תהליכים מתקדמים ובינה מלאכותית.כיצד הגנטיקה השפיעה על החשיבה המקצועיתלאחר אבחון בתו, אלכס החל ללמוד בעצמו תחום חדש לחלוטין – ביואינפורמטיקה. הוא השתמש בפרויקט קוד פתוח בשם Galaxy כדי לנתח בעצמו את הנתונים הגנטיים של בתו.דרך ההתנסות הזו הוא גילה עד כמה מערכות ביולוגיות מורכבות בהרבה מכל מערכת תוכנה שאנחנו מפתחים. תא בודד בגוף האדם מכיל אלפי תהליכים ומנגנונים העובדים יחד בהרמוניה מושלמת, וההבנה הזו העניקה לו פרספקטיבה חדשה לחלוטין גם על מערכות תוכנה גדולות ומבוזרות.מהו QA Lead בתוך צוות פיתוח?אלכס מסביר שהיום תפקידו אינו לנהל צוות QA מסורתי, אלא להוביל את תחום האיכות מתוך צוות הפיתוח עצמו.לדבריו, האחריות שלו אינה מסתכמת במציאת באגים בלבד, אלא כוללת:הובלת תרבות האיכות בצוות.שיפור תהליכי העבודה.זיהוי פערים בתהליך הפיתוח.עבודה צמודה עם מפתחים, מנהלי מוצר וראשי צוותים.יצירת שיח מקצועי סביב איכות המוצר.הוא מדגיש את ההבדל בין:QC (Quality Control) – בדיקת איכות המוצר עצמו.QA (Quality Assurance) – איכות התהליכים שמובילים ליצירת המוצר.לדבריו, כאשר התהליכים טובים וברורים – גם איכות המוצר משתפרת באופן טבעי.למה בחר בהובלה מקצועית ולא בניהול אנשים?אלכס מספר שבעבר שימש כראש צוות, אך עם השנים הבין שהכיוון שמעניין אותו באמת הוא העמקה מקצועית ולא ניהול עובדים.במקום להתקדם במסלול הניהולי, הוא בחר להפוך למומחה בתחום האיכות, להרחיב את הידע הטכנולוגי שלו ולהשפיע באמצעות מומחיות מקצועית.לדבריו, ניהול אנשים דורש סט כישורים שונה לחלוטין, והוא מצא שההשפעה המקצועית מתאימה לו יותר.QA בתוך צוותי Agileב-SAP אלכס עובד במודל שבו אנשי ה-QA הם חלק בלתי נפרד מצוותי הפיתוח.המשמעות היא:השתתפות בכל ישיבות הפיתוח.עבודה יומיומית עם המפתחים.מעורבות כבר משלב הדרישות.Review על Test Plans.ליווי הפיתוח עד העלייה לפרודקשן.בפועל, כל מפתח אחראי על ה-Feature שלו מקצה לקצה — מהפיתוח ועד הפריסה, כאשר איש ה-QA מלווה את התהליך ומוודא שהאיכות נשמרת לאורך כל הדרך.איך עובדים עם מעט מסמכים ועדיין שומרים על איכות?אחד הנושאים שעלו בפרק הוא המעבר ממסמכי אפיון גדולים ומפורטים לעולם ה-Agile.אלכס מסביר שכיום אין צורך במסמכים ארוכים של מאות עמודים. במקום זאת עובדים עם:User StoriesBDDGiven / When / ThenTest Cases קצריםReview מתמשךעם זאת, הוא מדגיש שהאחריות של אנשי ה-QA היא להשלים את התמונה, לזהות חוסרים בדרישות ולהעשיר את תרחישי הבדיקה לאורך כל מחזור הפיתוח.למה QA No הוא רעיון בעייתי?אלכס מתייחס לגישה שלפיה אין צורך באנשי QA, והמפתחים יכולים לבדוק את עצמם.לדבריו, מדובר בגישה בעייתית משום שקיים אפקט פסיכולוגי מוכר של Blindness – אדם מתקשה לראות את הטעויות של עצמו.מפתחים שקועים בקוד, בתכנון ובפתרון הבעיה ולכן זקוקים למישהו שיגיע מבחוץ עם הסתכלות אחרת.איש QA מביא איתו יכולות ייחודיות כמו:חשיבה מערכתית.ראייה מנקודת מבט הלקוח.Exploratory Testing.רגישות ל-UI ו-UX.ניסיון בזיהוי סיכונים.חיבור בין כלל חלקי המערכת.לדבריו, גם המפתחים המנוסים ביותר אינם חסינים מטעויות, ולכן נדרש גורם מקצועי נוסף שיבחן את המערכת בצורה אובייקטיבית.איכות היא אחריות של כל הצוותאחד המסרים המרכזיים בפרק הוא המודל של Whole Team Quality.בגישה זו:איכות אינה אחריות של איש ה-QA בלבד.כל חברי הצוות מחויבים לאיכות.מציאת באג קריטי אינה כישלון אלא הצלחה של הצוות.כל חברי הצוות שותפים לשיפור המוצר.אלכס מספר שבצוות שלו מנהלי הפיתוח מעודדים השקעה באיכות ומבינים שתהליכי QA דורשים זמן ותשומת לב.למה חשוב לכתוב Test Plan לפני כתיבת הקוד?לדברי אלכס, אחת הפרקטיקות החשובות ביותר היא הכנת Test Plan כבר בתחילת הפיתוח.כאשר הבדיקות מוגדרות מראש:מבינים טוב יותר את הדרישות.מזהים בעיות עוד לפני כתיבת הקוד.חושבים על מקרי קצה בשלב מוקדם.מאפשרים Review מקצועי.מקבלים פידבק מוקדם מהמפתחים ומה-QA.גישה זו משתלבת היטב עם עקרונות Shift Left ו-Test-Driven Thinking.מהו Test Plan טוב?לסיום, אלכס מסביר שאין תבנית אחת נכונה ל-Test Plan, אך הוא צריך לשלב הסתכלות ממספר עולמות:Functional TestingRisk Based TestingSecurity TestingAccessibility TestingCompatibility TestingPerformance במידת הצורךלדבריו, מוצר איכותי אינו רק כזה שעובד פונקציונלית, אלא גם כזה שמאובטח, נגיש, עקבי ומתאים למגוון משתמשים וסביבות עבודה.קישור לאתר עמותת קורנליה דה לנג ישראל: https://cdls.org.il/קישור לפרופיל לינקדאין של אלכס: https://www.linkedin.com/in/alex-s-77a3a68/קישור לפרופיל לינקדאין של ניצן: https://www.linkedin.com/in/ngqa/קישור לקבוצת העדכונים של TESTIL: https://bit.ly/TestIL_Whatsapp
• 
  פרק #80: מאוטומציה לאינפרט: סיפור הצלחה של סטארט-אפ עם איתי ששון 13.06.2026 34min

  איתי ששון: המעבר מסטארט-אפ לחברה מסחרית מנקודת מבט של בדיקות ואוטומציהבפרק זה של פודקאסט טסט איי אל, נתנאל הרוש מארח את איתי ששון, לשעבר כ-automation teach lead בחברת CathWorks וכיום QA Lead בחברת UNIXi לשיחה על האתגרים וההזדמנויות במעבר מחברת הזנק הנמצאת בשלב הוכחת הרעיון לחברה המוכרת מוצר ללקוחות בפועל.עבודה בחברת הזנק בתחום המכשור הרפואיאיתי מספר על עבודתו בחברת קאטוורקס, שפעלה בתחום המכשור הרפואי. בניגוד לחברות הזנק קלאסיות, שבהן המטרה הראשונית היא למצוא לקוחות ולהוכיח שהרעיון עובד, בעולם המכשור הרפואי יש צורך לעבור מחקרים קליניים, לעמוד בדרישות רגולטוריות מחמירות ולקבל אישורי שיווק לפני שניתן להתחיל למכור את המוצר.החברה השקיעה שנים במחקרים ובהוכחת יעילות המוצר מול בתי חולים ורופאים, ורק לאחר קבלת האישורים הרגולטוריים נדרשה לעבור לחשיבה עסקית של מכירת מוצר ושירות ללקוחות.השינוי המרכזי – מעבר מהוכחת יכולת לאיכות מוצרלדברי איתי, המעבר המשמעותי ביותר הוא שינוי תפיסתי. בשלב המחקר המטרה היא להוכיח שהמוצר עובד, בעוד שבשלב המסחרי נדרש לספק מוצר יציב, אמין ואיכותי עבור לקוחות אמיתיים.הוא מדגיש כי איכות אינה אחריות של אנשי הבדיקות בלבד, אלא של כל בעלי התפקידים בארגון:כתיבת דרישות נכונהתכנון ופיתוח איכותיסקירות קודבדיקות אוטומטיותתהליכי שחרור גרסאותמשוב מלקוחותהאיכות מתחילה כבר בשלב התכנון ונמשכת לאורך כל מחזור חיי המוצר.מצב האיכות והאוטומציה בתחילת הדרךכאשר איתי הצטרף לחברה, מצב הבדיקות היה רחוק מלהיות אידיאלי:כ-89 בדיקות אוטומטיות בלבד.רוב הבדיקות נכשלו באופן קבוע.הבדיקות הופעלו ידנית מתוך סביבת הפיתוח.אחת לשלושה חודשים כל החברה עצרה את עבודתה לטובת מספר ימי בדיקות ידניות.לא היה תהליך מסודר להכנסת קוד למערכת.מנהלי המוצר ראו יכולות חדשות רק לאחר שכבר שולבו בגרסה המרכזית.המצב יצר חוסר תקשורת, בזבוז זמן ותיקונים חוזרים.בניית תרבות איכות חדשהאיתי החל להוביל שינוי ארגוני מקיף.הצעד הראשון היה יצירת שליטה בתהליך הכנסת הקוד. הוא הגדיר כי צוות הבדיקות אחראי על הגרסה המרכזית של המוצר ולכן עליו לקבוע אילו שינויים יכולים להיכנס ומתי.לדבריו, אם אנשי הבדיקות נושאים באחריות כאשר תקלות חומקות ללקוחות, עליהם לקבל גם את הסמכות להשפיע על תהליך קבלת ההחלטות.אנשי בדיקות חייבים להכיר את המוצר לעומקאיתי טוען שאנשי הבדיקות צריכים להיות בעלי ההיכרות הרחבה ביותר עם המערכת:להבין את כל הרכיבים.להכיר תקלות עבר.לזהות סיכונים.להשתתף בתכנון העבודה.לסייע בניתוח דרישות ובקבלת החלטות.לדבריו, אנשי הבדיקות והמפתחים הם אלו שמכירים בצורה הטובה ביותר את נקודות החולשה של המערכת ולכן יכולים להתריע על סיכונים לפני שהם הופכים לבעיות אמיתיות.יצירת אמון באוטומציהאחד האתגרים המרכזיים היה חוסר אמון מוחלט במערך הבדיקות האוטומטיות.כאשר איתי הגיע לחברה, היו עובדים שסברו שעדיף להעסיק מספר בודקים ידניים במקום להשקיע באוטומציה, משום שניסיונות קודמים לא הצליחו.לכן היעד הראשון שלו היה להפוך את האוטומציה לכלי אמין ויציב.הוא:שכתב בדיקות.שיפר את תשתיות האוטומציה.הגדיל משמעותית את מספר הבדיקות.יצר קוד קריא וניתן לתחזוקה.הפחית באופן דרמטי את מספר הכשלים השגויים.מעבר לאוטומציה מקצועיתבהמשך נבנתה תשתית מלאה שכללה:מסדי נתונים לאיסוף מידע.לוחות מחוונים להצגת נתוני איכות.שרתי הרצה ייעודיים.תהליכי בדיקה אוטומטיים לפני שילוב קוד.המערכת אפשרה לכלל העובדים לצפות בנתוני האיכות בזמן אמת ולזהות מגמות ושינויים לאורך זמן.מנגנון בקרת איכות לפני שילוב קודאיתי הוביל הקמת תהליך שבו כל שינוי חייב לעבור סדרת בדיקות לפני שהוא נכנס למוצר:הקוד חייב להיבנות בהצלחה.חבילת ההתקנה חייבת להיווצר.בדיקות יחידה חייבות לעבור.בדיקות אוטומטיות קריטיות חייבות להצליח.גישה זו אפשרה לזהות בעיות מוקדם ולמנוע תקלות משמעותיות לפני הגעתן ללקוחות.שילוב אוטומציה כחלק מתהליך הפיתוחלאחר שהאוטומציה הפכה לאמינה, היא שולבה כחלק מתהליך העבודה הרשמי.כל יכולת חדשה הייתה צריכה לכלול גם בדיקות אוטומטיות, כל עוד ניתן היה לבצע אוטומציה עבורה. בנוסף, כל הפעולות הקשורות לאיכות ולבדיקות תועדו כחלק מדרישות הארגון והרגולציה.כיצד יודעים שאוטומציה מצליחה?לדברי איתי, הצלחת אוטומציה אינה נמדדת בכמות הבדיקות או באחוזי הכיסוי בלבד.המדדים החשובים באמת הם:איתור תקלות במהירות.זיהוי השפעות של שינויים במערכת.קבלת משוב מהיר למפתחים.מניעת תקלות לפני הגעתן לגרסה המרכזית.קיצור זמני התגובה לתקלות.כאשר מפתחים מקבלים תשובה מהירה על איכות השינויים שביצעו, הם מסוגלים לעבוד בצורה יעילה הרבה יותר.האם אוטומציה מחליפה בודקים ידניים?איתי מתנגד לגישה זו באופן חד-משמעי.לדבריו, אוטומציה היא כלי נוסף בארגז הכלים של איש הבדיקות ואינה מחליפה את החשיבה האנושית. גם לאחר שנים רבות של השקעה באוטומציה, הוא המשיך לבדוק את המוצר ידנית מדי יום כדי להרגיש את חוויית המשתמש ולזהות בעיות שאינן ניתנות לזיהוי באמצעות בדיקות אוטומטיות בלבד.היתרונות בעבודה בחברת הזנקבסיום הפרק מסביר איתי מדוע הוא אוהב לעבוד בחברות הזנק:למידה מואצת – חשיפה למגוון רחב של תחומים וטכנולוגיות.יכולת השפעה גבוהה – אפשרות לעצב תהליכים, כלים ותרבות ארגונית.חופש טכנולוגי – בחירת הכלים והתשתיות המתאימים ביותר לצרכים.תחושת בעלות ואחריות – היכולת להוביל שינויים משמעותיים בארגון.בניית פתרונות מאפס – יצירת תשתיות ותהליכים המותאמים בדיוק לצורכי החברה.מסר מרכזי מהפרקהמעבר מחברת הזנק הממוקדת בהוכחת יכולת לחברה מסחרית מחייב שינוי תפיסתי עמוק. הצלחת המוצר תלויה בבניית תרבות איכות ארגונית, בתהליכי עבודה מסודרים ובאוטומציה אמינה התומכת בצוותים השונים. אנשי הבדיקות אינם רק מאתרי תקלות, אלא שותפים מרכזיים בהובלת האיכות, בניהול הסיכונים ובהצלחת המוצר כולו.קישור לפרופיל לינקדאין של איתיקישור לפרופיל לינקדאין של נתנאלקישור לקבוצת הוואצאפ לקבלת עדכונים
• 
  פרק #79 | תחרות האוטומציה של ישראל 30.05.2026 50min

  תחרות ITAC היא תחרות האוטומציה הישראלית הראשונה מסוגה, שמביאה לקדמת הבמה את אנשי ונשות האוטומציה, הבדיקות וה־DevOps בישראל. מטרת התחרות היא לא רק לבדוק מי כותב את הקוד הכי מהר, אלא מי יודע לחשוב כמו מהנדס בדיקות אמיתי: להבין מערכת, לתכנן אסטרטגיית בדיקות חכמה, לבנות פתרון אוטומציה יציב, קריא, יעיל ובר־תחזוקה, ולהציג יכולת הנדסית שמתאימה לעולם הפיתוח המודרני.במהלך התחרות המשתתפים מתמודדים עם אתגר אמיתי המדמה עבודה בסביבת מוצר, שבו עליהם לנתח דרישות, לזהות תרחישים חשובים, לבנות בדיקות אוטומטיות, להתמודד עם כשלים, לדבג תקלות ולהראות לא רק תוצאה עובדת, אלא גם חשיבה מקצועית מאחורי הפתרון. הדגש הוא על איכות הקוד, בחירת הכלים, מבנה הפרויקט, יציבות הבדיקות, יכולת תחזוקה, דיווח ברור על תקלות והיכולת לייצר ערך אמיתי לצוותי הפיתוח והמוצר.ITAC נועדה לתת במה לקהילה המקצועית בישראל ולהראות שאוטומציה היא הרבה מעבר לכתיבת סקריפטים. מדובר בדיסציפלינה הנדסית שלמה, שמשלבת הבנה טכנולוגית, חשיבה ביקורתית, בדיקות תוכנה, פיתוח, תשתיות, תהליכי CI/CD, עבודה עם כלים מתקדמים ולעיתים גם שימוש בבינה מלאכותית כדי לשפר את תהליך הבדיקה.התחרות מתקיימת ביוזמת ITCB ובשיתוף שותפים מהתעשייה, מתוך מטרה לקדם את תחום האוטומציה בישראל, לעודד מצוינות מקצועית, לחשוף כישרונות חדשים ולחבר בין אנשי בדיקות, מפתחים, מנהלים, חברות וקהילות טכנולוגיות. עבור המשתתפים זו הזדמנות להוכיח יכולות, ללמוד מאחרים, לקבל חשיפה מקצועית ולהיות חלק מאירוע שמסמן את עתיד עולם הבדיקות והאוטומציה.בסופו של דבר, ITAC היא לא רק תחרות. היא הצהרה מקצועית: עולם הבדיקות משתנה, האוטומציה הופכת למרכיב מרכזי באיכות המוצר, ואנשי הבדיקות של העתיד צריכים לדעת לשלב בין חשיבה בדיקותית עמוקה לבין יכולות הנדסיות מתקדמות. ITAC באה בדיוק כדי להראות את זה — על במה אחת, מול הקהילה כולה.קישור לאתר התחרות:  WWW.ITAC.CO.IL 
• 
  פרק#78 | מה באמת קורה מאחורי הקלעים של הבינה המלאכותית עם נתנאל הרוש ושי ששון 16.05.2026 1h 6min

   סיכום מלא של הפרקבפרק הזה של פודקאסט טסט.איי.אל מבית אי.טי.סי.בי, נתנאל הרוש מארח את שי ששון לשיחה עמוקה ומרתקת על מה שבאמת קורה מאחורי הקלעים של עולם הבינה המלאכותית – מעבר לכלים שכולנו מכירים ולשימושים היומיומיים שהפכו לחלק מהחיים שלנו.שי, שעוסק בתחום כבר יותר מ־20 שנה, מספר כיצד התחיל לעבוד עם מערכות בינה מלאכותית עוד בתקופה שבה התחום היה שייך כמעט רק לצבאות, מדינות ותאגידים גדולים. הוא מתאר עולם שבו פעולות שכיום ניתן לבצע בתוך שניות, דרשו בעבר מחשבים חזקים במיוחד, שעות ארוכות של עיבוד ועלויות עצומות.השיחה מתמקדת במהפכה שהתרחשה בשנים האחרונות – שילוב של מחשוב ענן, אינטרנט מהיר, כוח עיבוד מתקדם וכמויות מידע אדירות, שאפשרו לבינה המלאכותית להפוך מכלי יקר ומוגבל לטכנולוגיה שכל אדם יכול להשתמש בה.אחד הנושאים המרכזיים בפרק הוא המעבר ממערכות שמגיבות לפקודות בלבד, למערכות שמסוגלות ללמוד, לחקור, לחפש פתרונות ולבצע משימות באופן עצמאי. שי מתאר כיצד מערכות כאלה כבר יודעות לאתר בעיות, לחפש מידע ברחבי האינטרנט, לבדוק פתרונות שונים ולנסות לפתור תקלות ללא התערבות אנושית כמעט בכלל.בהמשך הפרק עולה גם נושא הדור הבא של הבינה המלאכותית – מערכות שצפויות להגיע לרמת חשיבה ויכולת המזכירות חשיבה אנושית מלאה. שי מסביר שלדעתו הציבור עדיין לא מבין עד כמה הטכנולוגיה כבר מתקדמת, וכי החברות הגדולות בעולם מחזיקות ביכולות מתקדמות הרבה יותר ממה שנחשף לציבור הרחב.השיחה נוגעת גם בהשפעה של הבינה המלאכותית על עולם העבודה. שי טוען שבעתיד הקרוב משימות רבות יתבצעו בצורה אוטומטית לחלוטין, ותפקידים רבים ישתנו משמעותית. במקום לבצע עבודה טכנית שחוזרת על עצמה, אנשים יתמקדו יותר בניהול, קבלת החלטות, חיבור בין מערכות ויצירת רעיונות חדשים.נושא נוסף שמקבל מקום משמעותי בפרק הוא עולם הרובוטיקה. שי מספר על טכנולוגיות שמאפשרות לרובוטים ללמוד משימות חדשות בצורה עצמאית, במקום להיות מתוכנתים לבצע פעולה אחת בלבד. לדבריו, מדובר רק בתחילת הדרך, ובעתיד נראה רובוטים שמסוגלים להסתגל למשימות חדשות במהירות ובצורה כמעט אנושית.לקראת סוף הפרק, השיחה הופכת רחבה ופילוסופית יותר. השניים מדברים על האפשרות שהבינה המלאכותית תשפר משמעותית את איכות החיים – פחות שעות עבודה, פחות בירוקרטיה, פתרון בעיות מורכבות ושיפור ברמת החיים של אנשים ברחבי העולם. לצד זאת, עולה גם החשש משימושים מסוכנים בטכנולוגיה – מאבקי כוח בין מדינות, מערכות נשק חכמות ואובדן שליטה אנושי על חלק מהמערכות.הפרק מסתיים בתחושה ברורה: אנחנו נמצאים רק בתחילת המהפכה. מה שנראה היום מרשים ומתקדם הוא כנראה רק הצעד הראשון בדרך לעולם חדש לחלוטין, שבו הבינה המלאכותית תשפיע כמעט על כל תחום בחיים שלנו.קישור לפרופיל לינקדאין של שי ששון: https://www.linkedin.com/in/shay-sasson-77aa5256/קישור לפרופיל לינקדאין של נתנאל הרוש: https://www.linkedin.com/in/netanel-harush/קישור לקבוצת הוואצאפ של טסט.איי.אל: https://bit.ly/TestIL_Whatsappהפרק של היום בחסות מכללת IPC - המכללה המובילה למקצועות הייטק בישראלIPC - מקצועיות, קריירה ועתידhttps://ipc.co.il/ | 077-2760060 ```
• 
  פרק #77 | ״אישה בחזית מהפיכה ושינוי ב-איי.טי.אנ.טי״ עם דקר שלום ויעל גולדברג 03.05.2026 1h 9min

  פרק #77 | ״אישה בחזית מהפיכה ושינוי ב-איי.טי.אנ.טי״ עם דקר שלום ויעל גולדברגרקע על יעל גולדברגיעל גולדברג היא סמנכ"לית חטיבת מרכז הפיתוח ב-איי.טי.אן.טי ישראלהקריירה שלה התחילה כמפתחת תוכנה בחברת קונברס בזמן לימודיה, שם התקדמה לתפקידי ניהול (ראש צוות וקבוצה):בהמשךעברה לניהול תוכניות רחבותנחשפה לתמונה הרחבה של תהליכי פיתוח והאילוצים העסקייםקיבלה הזדמנות לנהל קבוצת בדיקות – למרות חוסר ניסיון קודםלמדה את תחום הבדיקות לעומק (כולל הסמכות מקצועיות)פיתחה מומחיות משולבת: פיתוח + בדיקותהחיבור בין שני העולמות (פיתוח ובדיקות) הפך לבסיס הקריירה שלהעל איי.טי.אן.טי ומרכז הפיתוח בישראלאיי.טי.אן.טי היא חברה ותיקה מאוד (כ-160 שנה), שהוקמה ע"י ממציא הטלפוןשרדה והתפתחה בזכות יכולת הסתגלות לשינויים:מרכז הפיתוח בישראלקיים מעל 15 שנהנחשב למוביל בתוך הארגוןהתחיל כסטארטאפ ישראלי (אינטרוייז) שנרכש ע"י איי.טי.אן.טימשמש כמוקד מומחיות:הייחוד המרכזי👉 דגש על מצוינות טכנולוגית ושיטות פיתוח מתקדמות👉 לא רק “לייצר תוכנה”, אלא להביא ערך ייחודיעקרונות מרכזיים בניהול ופיתוחיעל מדגישה שארגון חייב לבחור ערכים ברורים:במקרה שלהםמצוינות מקצועיתחדשנות טכנולוגיתשיפור מתמיד:הדגש הוא על👉 השקעה ארגונית במצוינות👉 מדידה לפי איכות התוצר והאימפקט – לא לפי כמות קודhttps://www.linkedin.com/in/yael-goldeberg-katz/ קישור לפרופיל לינקדאין של יעלhttps://www.linkedin.com/in/dakar-shalom-7b6a575/ קישור לפרופיל לינקדאין של דקרhttps://bit.ly/TestIL_Whatsapp קישור לקבוצת הוואצאפ של עמותת הבודקים לקבלת עדכונים
• 
  פרק #76 | התפתחות מקצועית לבודקי תוכנה עם עמית ורטהיימר 18.04.2026 1h 1min

  בואו הקשיבו לניצן גולדנברג מארח את עמית ורטהיימר אשר מדברים על התפתחות מקצועית לבודקי תוכנהתיאור הפרק: התפתחות מקצועית לבדוקי תוכנה:בפרק הזה של הפודקאסט מתארח עמית ורטהיימר, בודק תוכנה ותיק וראש צוות בדיקות, לשיחה עמוקה על השאלה שמעסיקה הרבה אנשי בדיקות תוכנה?איך מתקדמים מקצועית – בלי לעזוב את עולם הבדיקותהרקע לפרק.הדיון מתחיל מתופעה מוכרת: אנשי בדיקות תוכנה מוכשרים עוזבים את התחום אחרי כמה שנים, לרוב לכיוון פיתוח או דבאופס.הסיבה המרכזית שחוזרת על עצמה: תחושת “תקרת זכוכית” – חוסר במסלול התקדמות ברור בתוך בדיקות תוכנה.עמית מנסה להתמודד עם הבעיה דרך מודל שמגדיר מסלולי התפתחות אמיתיים בתוך המקצוערמות התפתחות ב-בדיקות תוכנהרמה בסיסיתביצוע משימות בדיקהעבודה לפי הנחיותיכולת לתפעל בדיקות (ידניות או אוטומטיות)זה השלב שבו  - עושים את העבודה רמת – יצירת אימפקט:כאן מתחיל ההבדל האמיתי.בודק בכיר לא רק מבצע – אלא משפיע על הסביבה שלו:דוגמאותמנטורינג לצוות      מומחיות עמוקה במוצר     הובלת תחום טכנולוגי (כמו אוטומציה)     שיפור תהליכיםהפוקוס עובר מ-“מה אני עושה” ל-איך אני משפיערמות בכירות:בשלב הזה ההשפעה כבר חוצה צוותיםטסט ארכיטקטמגדיר אסטרטגיית בדיקות ארגונית     מחבר בין בדיקות לבין מטרות עסקיות    בונה חזון   טסט ג׳אמפר (מושג של ג׳יימס באך)כוח חילוץ-  למצבים מורכבים    נכנס לבעיות קריטיות ומייצר פתרון מהיר   מהנדס פרודקטיביטימשפר תהליכי עבודה     בונה כלים שמייעלים את עבודת הצוות     מומחה טכני מתכנת חזק שמתמחה בכלי בדיקות     בונה תשתיות מתקדמות     רמת “משפיענים” בתעשייהאנשים עם מוניטין רחב    מפיצים רעיונות חדשים   מחברים בין קהילות וארגונים   בעיה מרכזית: טייטלים לא ברורים:אחת הביקורות החזקות בפרק היא על שוק העבודהבודק תוכנה, מהנדס בדיקות, מהנדס אוטומציהלא באמת מגדירים מה מצופה מהתפקיד:התוצאהמועמדים לא מתאימים מגישים מועמדות     פערים בין ציפיות למציאות     ?ומה עם בינה מלאכותית:הנושא עולה בסוף הפרקבינה מלאכותית הוא כלי חזק – אבל לא חובה (עדיין)      יש הרבה הייפ, אבל השוק עדיין לומד איך להשתמש בו נכון      שימוש לא נכון יכול אפילו לבזבז זמן (למשל: יצירת כמויות קוד שלא מספיקים לבדוק)    :המסקנהבינה מלאכותית חשוב – אבל הוא עוד כלי בארגז, לא תחליף לחשיבה מקצועית:קישורים שאוזכרו בפרקhttps://www.satisfice.com https://www.associationforsoftwaretesting.org? מסקנה מרכזית:הפרק שובר מיתוס חשוביש התפתחות מקצועית ב-בדיקות תוכנה – אבל צריך להגדיר אותה נכון:הקידום האמיתי לא מגיע רק מתפקידים חדשים, אלא מהרחבת השפעההעמקת מומחיותתרומה לארגון ולתעשייה?רוצים להבין את זה לעומקהאזינו לפרק המלא וקחו את הבדיקות שלכם לשלב הבאhttps://bit.ly/TestIL_Whatsapp :לקבוצת הוואצאפ של קהילת הבודקים https://www.linkedin.com/in/ngqa/ :קישור לפרופיל לינקדאין של ניצןhttps://www.linkedin.com/in/amit-wertheimer-ba187550/  :קישור לפרופיל לינקדאין של עמית       
• 
  פרק #75 | האנציקלופדיה לבדיקות עם ניצן גולדנברג - אדפטיביליטי - היכולת להסתגל 04.04.2026 10min

    Adaptability פרק #75 - האנציקלופדיה לבדיקות - היכולת של מערכות להסתגל  ( מערכות משולבות בינה מלאכותית) כשהמערכת משתנה בלי שאף אחד שינה קודאתם מגיעים בבוקר, כל הבדיקות עברו, אין גרסה חדשה, והמערכת נראית תקינה לחלוטין. ואז מתחילים להגיע דיווחים מהמשתמשים שמשהו לא עובד כמו אתמול. אתם בודקים שוב ולא מוצאים שום שינוי. זה הרגע שבו מבינים שהשינוי לא הגיע מהקוד, אלא מהעולם עצמו.יכולת הסתגלות היא היכולת של מערכת מבוססת בינה מלאכותית להגיב לשינויים בסביבה שלה. המערכת מושפעת מדברים שמשתנים כל הזמן כמו נתונים, משתמשים, שפה, הקשר עסקי וסביבה טכנולוגית. לכן גם בלי שינוי קוד, ההתנהגות שלה יכולה להשתנות.אבל עצם השינוי אינו מספיק. מערכת טובה צריכה להשתנות בצורה נכונה. היא צריכה להמשיך לעמוד בדרישות, לא לפגוע במשתמשים, לא ליצור הטיות בעייתיות ולשמור על רמת איכות יציבה. התפקיד של הבודק הוא לא רק לבדוק אם המערכת עובדת, אלא לבדוק האם הדרך שבה היא השתנתה היא תקינה.בעולם הקלאסי בדיקות התמקדו בשאלה האם הפונקציונליות עובדת. בעולם של בינה מלאכותית צריך לשאול שאלה אחרת: האם המערכת עדיין נכונה. מערכת יכולה להחזיר תשובות, לעבור בדיקות ולהיראות תקינה, ובכל זאת לא להתאים למציאות המשתנה.אפשר לראות את זה בדוגמאות שונות. מערכת לסינון מיילים יכולה להתחיל לחסום הודעות חשובות בגלל שינוי בשפה או בניסוח. מערכת לזיהוי תמונה יכולה לאבד דיוק בגלל שינוי בתאורה או במצלמות. מודל אשראי יכול להתחיל לדחות יותר בקשות בגלל שינוי בהרכב האוכלוסייה. צ׳אטבוט יכול להיכשל כאשר המשתמשים עוברים לשפה חדשה עם סלנג וקיצורים. בכל המקרים האלה אין תקלה קלאסית, אלא תגובה לשינוי שלא נבדקה נכון.כדי לבדוק יכולת הסתגלות צריך לשנות גישה. צריך להשתמש בנתונים אמיתיים מהשטח ולא רק בנתונים נקיים ומלאכותיים. צריך לבדוק איך המערכת מתמודדת עם קלטים בעייתיים, שגיאות ותנאים קיצוניים. צריך להשוות התנהגות לאורך זמן ולבדוק לא רק אם משהו עובד אלא אם הוא השתנה, ואם השינוי הוא שיפור או הידרדרות. בנוסף, מאחר שאין תשובה אחת נכונה, יש לבדוק עקביות, היגיון ועמידה בחוקים ובגבולות. ולבסוף, חשוב לעבוד עם הצוות ולהבין מה באמת קריטי לעסק כדי להעריך נכון את המשמעות של השינוי.חשוב להבין שיכולת הסתגלות אינה כאוס. המערכת לא אמורה לפעול באופן חופשי ללא גבולות, אלא להשתנות בצורה מבוקרת ובהתאם לחוקים ולדרישות.השורה התחתונה היא שבעולם של בינה מלאכותית לא מספיק שהמערכת עובדת. צריך לשאול האם היא עדיין נכונה גם אחרי שהשתנתה.האזינו לפרק המלא וקחו את הבדיקות שלכם לשלב הבאhttps://bit.ly/TestIL_Whatsapp :לקבוצת הוואצאפ של קהילת הבודקיםhttps://www.linkedin.com/in/ngqa/ :קישור לפרופיל לינקדאין של ניצן 
• 
  פרק #74 | בינה מלאכותית כשופטת עם יאיר כהן 20.03.2026 51min

  ?מה זה מודל שפה גדולמערכת שלומדת מטקסטים רבים מאוד, ומנבאת מילים בצורה סטטיסטיתהיא לא מבינה באמת — אלא חוזה המשךהאתגר בבדיקות:בניגוד לתוכנה רגילהאין תשובה אחת נכונהיש תחום אפורחוויית משתמש קשה למדידה הפתרון: בינה מלאכותית כשופטת:משתמשים במודל אחד כדי לבדוק מודל אחרנותנים קריטריוניםמבקשים דירוגמקבלים ציון ? איך מלמדים את השופט:שתי דרכיםמתן דוגמאות והנחיות ברורותאימון על נתונים ייעודיים בעיה: הטיה אנושית בנתוניםפתרון להטיה:מגדירים עקרונות קבועים (כמו חוקה)לא להפלותלא להמציא מידעלהיות שקוף המודל בודק את עצמו לפי זה ומשתפרבעיית ״המצאות מידע״המודל לפעמים ממציא תשובות שנשמעות נכונות:דרכי התמודדותבקרה אנושיתחיבור למידע אמיתיבדיקה באמצעות מודל נוסףהנחיות מדויקות ?איך מודדים איכותציונים לפי קריטריוניםאחוז הצלחה (למשל 85%)בדיקות אנושיות להשוואה ?מה זה סוכןמערכת שמבצעת משימות לבד:מרכיביםמוח (מודל שפה)הוראותזיכרוןמידע חיצונייכולות פעולהחיבור לעולם האמיתייש תקן שמאפשר חיבור למידע וכלים חיצוניים בצורה מסודרת ואחידה?איך בונים סוכןיש כלים ללא קוד או פיתוח מלא שינוי בעולם הפיתוח:המפתחיםפחות כותבים קודיותר מפקחים ומכוונים מסקנההבינה המלאכותית לא מחליפה אנשים -  היא הופכת אותם למנהלים של מערכות חכמותקישור לפרופיל לינקדאין של יאיר כהןקישור לפרופיל לינקדאין של נתנאל הרושקישור לקבוצת העדכונים של עמותת הבודקים בוואצאפ
• 
  פרק #73 | הקשר בין מנהיגות מודרנית לאיכות עם פבל מלין 07.03.2026 45min

  פרק #73 - הקשר בין מנהיגות מודרנית לאיכות עם ניצן גולדנברג מראיין את פבל מלין כיצד סגנון המנהיגות בארגון משפיע על איכות המוצרים והשירותים? בפרק זה נצלול לקשר בין מנהיגות מודרנית לניהול איכות, ונבחן כיצד התפתחות הגישות הניהוליות לאורך המאה האחרונה עיצבה את הדרך שבה ארגונים משיגים מצוינותנעסוק בהתפתחות עולם האיכות – מהניהול המדעי של פרדריק טיילור, דרך בקרת איכות סטטיסטית של וולטר שוהרט, ומעגל השיפור המתמיד תכנון–ביצוע–בדיקה–פעולה של אדוארדס דמינגבהמשך נדבר גם על גישות מתקדמות לניהול איכות, כמו ניהול איכות כולל ניהול אג'ילי וניהול רזה גישות שמדגישות שיפור מתמיד, עבודה צוותית והתמקדות בערך ללקוחבנוסף נבחן את השינוי בתפקיד המנהל: ממודל היררכי המתמקד בשליטה ותהליכים, למנהיגות מודרנית שמדגישה מיומנויות רכות כמו תקשורת אפקטיבית, אינטליגנציה רגשית, העצמת עובדים ויצירת ביטחון פסיכולוגי בצוותבפרק נבין כיצד תקשורת ברורה, ניהול קונפליקטים, משוב מתמשך ויכולת הסתגלות לשינויים יכולים להשפיע ישירות על איכות העבודה והמוצר – וליצור תרבות ארגונית שמובילה לשיפור מתמיד, חדשנות והצלחה לאורך זמןמבוסס על מאמרו של פבל מליןקישור לפרופיל לינקדאין של פבלקישור לקבוצת הוואצאפ של עמותת הבודקים של ישראל 
• 
  פרק #72 להיות בתפקיד השיא שלך עם איילת מלמד כהן 21.02.2026 57min

  בואו הקשיבו לניצן גולדנברג מארח את איילת מלמד כהן, מנטורית למנהלי בדיקות תוכנה ובעלת הטור ״עושים QA לקריירה״ במגזין ״עולם הבדיקות״ מדברים על הטור האחרון שלה מגליון 42 ״להיות בתפקיד השיא שלך״ עושים בדיקות תוכנה לקריירה – איך להגיע לתפקוד השיא שלךבפרק הזה נדבר על שינוי תפיסה משמעותי בפיתוח קריירה – מעבר ממיקוד בחולשות למיקוד בחוזקותהרעיון המרכזי: המרחב הגדול ביותר לצמיחה והתפתחות אינו טמון בשיפור החולשות שלנו – אלא בחיזוק החוזקותהמאמר פורסם בגיליון 42 של מגזין ״עולם הבדיקות״, רבעון שלישי 2025?למה אנחנו כל כך ממוקדים בחולשות:רובנו גדלנו על תפיסה ברורהתשתפר במה שאתה לא טוב בותתקן את מה שמקולקלתמצא את הבאגיםכאנשי בדיקות – זו אפילו המומחיות שלנואבל כשאנחנו מפעילים את אותו "מיינדסט של באגים" על הקריירה שלנו – אנחנו לעיתים שמים לעצמנו מקלות בגלגלים?מה אומר המחקרארגון המחקר האמריקאי חקר מעל מיליון אנשים ויותר מ-50,000 צוותים, ובדק מה מייצר הצלחה, שביעות רצון וביצועים גבוהים:המסקנה חד משמעיתאנשים וצוותים מצליחים יותר כשהם עובדים מתוך החוזקות שלהם – לא מתוך ניסיון לתקן חולשות:כאשרמשימות מותאמות לחוזקות:הפידבק מחזק את השימוש בהן ואז ישיותר מעורבותביצועים גבוהים יותרפחות שחיקהיותר מחוברות לארגון וזה לא אומר להתעלם מחולשות – אלא לשים את הפוקוס במקום שמייצר מקסימום צמיחהשני סוגי חוזקות:איילת מחלקת את החוזקות לשני סוגיםחוזקות מיומנותכישרון + ידע + ניסיוןלדוגמה: חקירה עמוקה, תכנון טסטים, הבנת מערכות מורכבותחוזקות תשוקהדברים שממלאים אותנו באנרגיהפעילויות שמרגישות טבעיות ונותנות תחושת חיוניות?מהו תפקוד שיא:תפקוד שיא קורה בנקודת ההצטלבות ביןמה שאני טוב/ה בומה שנותן לי אנרגיה וסיפוק :שם אנחנוגם מצטייניםגם נהניםגם מרגישים ערך עצמי גבוה לא כל חוזקה היא בהכרח מקור אנרגיהאפשר להיות מעולים במשהו – וזה עדיין ירוקן אותנוסיפור אישי מהשטחאיילת משתפת שבניהול קבוצת בדיקות תוכנה היא הייתה מאוד חזקה בהבנת מערכות ומתן פידבקהיא הוזמנה להרבה סקירות וישיבות – כי זו הייתה חוזקה ברורה?אבל בפועלזה שאב ממנה אנרגיהבמקביל, פעילויות שלא נחשבו "תחום המומחיות שלה" – כמו פיתוח סדנאות קריירה ומנטורינג – דווקא מילאו אותה באנרגיהמה שהתחיל כצדדי – הפך בהמשך לחלק מהמקצוע שלהתרגיל פרקטי לזיהוי תפקוד השיאקחו דף וחלקו לשתי עמודותעמודה 1: במה אני חזק/ה? (לפחות 10 דברים)?עמודה 2: ממה אני נהנה/ית? מה נותן לי אנרגיה וסיפוקקישור לשאלון של איילה:לאחר מכןסמנו את מה שחוזר על עצמו בין העמודותשם נמצא הרמז לאזור תפקוד השיא שלכם אפשר גם למלא שאלון כתוב שמחדד את המקומות שבהם אתם במיטבכם?איך מיישמים את זה בקריירהכשנכנס פרויקט חדש – דחפו לחלק שמתאים לחוזקות שלכםבראיונות עבודה – הציגו את עצמכם דרך אזור תפקוד השיאבשיחות משוב – שתפו במה שמאפשר לכם להיות במיטבכםחפשו יוזמות ופעילויות שמחוברות לאזור הזהדוגמה: אנשי ה-גם וגםיש אנשים שאולי מקצועית הם בינוניים – אבל חברתית הם כוכביםהם מחוברים, משתתפים ביוזמות, בהאקתונים, בצוותי חדשנות, בפעילויות משאבי אנושהם פורחים כשהם מחוברים לאנשיםשם תפקוד השיא שלהם – ביצירת קשרים ובהשפעה רוחבית?למה זה חשוב במיוחד בתקופות קשותאיילת משתפת שבתקופה מאתגרת בקריירה, כשהרגישה תקיעות באחד הדומיינים שבאחריותה – ההתמקדות בחוזקות שלה שמרה על המוטיבציה:תפקוד השיאמשמר ביטחוןמעלה מסוגלותמאפשר להתמודד עם אתגרים ממקום יציב המסר המרכזי לפרקלהכיר את עצמך – זה כלי עבודהלהשקיע זמן בתפקוד השיא שלך – זו אסטרטגיית פיתוח קריירה:במקום לשאול?איפה אני לא מספיק טוב:שאלו?איפה אני גם טוב וגם מתמלא מזה באנרגיהשם נמצאת קפיצת הגדילה הבאה שלכםלאתר של איילת מלמד כהןלפרופיל לינקדאין של איילת מלמד כהן הפרק בחסות מכללת איי פי סיאם גם אתם רוצים לעשות את הצעד הבא בקריירה – זה הזמן להצטרף לקורס בדיקות התוכנה של מכללת איי פי סימדובר בקורס עדכני, מעשי ומקצועי במיוחד, שמשלב בין בדיקות ידניות, אוטומציה וכלים מתקדמים מעולם הבינה המלאכותיתתלמדו איך לתכנן, להריץ ולנתח בדיקות בצורה חכמה – כולל הכנה מלאה להסמכת ISTQB הבינלאומיתעם מרצים מנוסים מהתעשייה, ליווי אישי ותיק עבודות אמיתי – תקבלו את כל הכלים להשתלב בהצלחה בתחוםלפרטים והרשמה חפשו מכללת איי פי סי בגוגל או הקליקו על הקישורלקבוצת הוואצאפ של קהילת הבדוקיםלהרשמה לתחרות הבדיקות תוכנה של ישראלhttps://www.youtube.com/embed/qKt0X4JJnho?si=BB23W6LGveHdJnjK  [email protected] :אם גם אתם מעוניינים להשתתף בפודקאסטים, אנא צרו עימנו קשר במיילקישור לערוץ הפודקאסט שלנו   
• 
  פרק #71 | בדיקות בחברת חשמל עם ויקטור אוסיפוב 07.02.2026 1h 13min

  פרק #71בדיקות תוכנה בחברת חשמל עם ויקטור אוסיפוב בואו הקשיבו לניצן גולדנברג מארח את ויקטור אוסיפוב - מהנדס בדיקות בחברת חשמל אשר מספר על אילו בדיקות עושים בחברת חשמלרקע על האורח – ויקטור אוסיפובויקטור בן 47, גרוש ואב לשניים, מגיע מרקע עשיר בתחום האלקטרוניקה והבקרה שירת בצה"ל בתחום האלקטרוניקהעבד 17 שנים באינטל בתחום הבקרה והתקשורתהמשיך לעבוד במקורות בבדיקת מערכות של תחנות שאיבה, כולל סימולציותעבר לסטארטאפ בתחום מדעי – "חתול מדע"כיום ראש צוות בדיקות מסירה בחברת החשמל – דרך קבלן משנה (טסטנט) דרך אריקסון מה זה אומר לעבוד בבדיקות בחברת החשמלויקטור וצוותו עוסקים בבדיקות למערכת מונה חכםהמונה מעביר נתוני צריכת חשמל למרכז הבקרהמדובר בפרויקט מורכב הכולל תקשורת, בטיחות, אבטחה, רגולציה, וסנכרון עם מערכות כמו סאפהחברה משתמשת בשירותי אאוטסורס נוספים, בנוסף לצוותים פנימיים המערכות מערכות רבות מאוד, לרוב מונוליטיות, הדורשות תקשורת מתואמת ביניהןדוגמה  סאפ מנהלת מעקב אחרי התקנת מונים, סטטוס מלאי וכו' מתודולוגיות בדיקהעובדים בעיקר במודל של קבלנות לפי נפח עבודה ולא במתודולוגיות מודרניות כמו אג׳ייל או מרתוניםאין שימוש באוטומציה או בינה מלאכותית בצוות של ויקטור (לפי דרישת ההנהלה), אם כי צוותים אחרים כן עוסקים באוטומציה מתודולוגיית הבדיקה המרכזיתבדיקות מסירהבדיקות פונקציונליות מול מערכות ניהול בדיקות חקרניות - הבדיקות "הטעימות" ביותר בעיניו של ויקטור באגים מענייניםהבאגים המהנים ביותר הם אלו שלא חלק מנפח העבודה הרשמי – כאלו שנמצאים מתוך היכרות עמוקה עם המערכת (בדיקות חקרניות)צוותו מצא כ-100 באגים במערכות שכבר עברו בדיקות איכות של חברות מפתחות – כולל באגים קריטיים תהליכי גרסה ושחרוראין תהליך אג׳ייל אמיתי או שחרור יומימערכות שונות משתחררות בגרסאות נפרדות, לא תמיד מסונכרנותדוגמה מטרידה  לעיתים סביבת טסט מקבלת גרסה חדשה יותר מסביבת דב סקיוריטי, פרפורמנס, ותחומי אחריותיש חלוקה ברורה בין צוותיםצוותים שמתמקדים בפונקציונליותצוותים שעוסקים בביצועים, אבטחה, סאפ ועודכל צוות הוא "דומיין אקספרט" – מתמקצע בתחום ספציפי מאוד, אך חסר גמישות תפעולית בינה מלאכותית ואוטומציהבצוות של ויקטור אין שימוש בבינה מלאכותית או אוטומציהבחלקים אחרים של חברת החשמל כן יש פרויקטים באוטומציה תובנות כלליותויקטור מדגיש את החשיבות של לא למהר להגדיר בג כקריטי - לפעמים מדובר בטעות בשימוש או בהבנהכל בג צריך לעבור אימות חוזר, בדיקה על מספר מונים, ורק לאחר מכן לפתוח טיקט נקודה אישית בסיוםויקטור מביא גישה מקצועית, אך גם הומור, אהבה לתחום, וכנות לגבי האתגרים – כמו עמידה מול חסמים, קצב עבודה שונה מחברות הייטק, והצורך באלתור בתוך מסגרות נוקשות [email protected]: לשליחת התשובות לחידה שויקטור שאל בפרק ניתן לשלוח למיילhttps://bit.ly/TestIL_Whatsapp :לקבוצת הוואצאפ של קהילת הבדוקיםwww.istc.org.il הרשמה לתחרות הבדיקות תוכנה של ישראל 
• 
  פרק #70 | ראיון עם מנצחי תחרות הבדיקות הישראלית והבינלאומית 2025 24.01.2026 49min

  ראיון עם מנצחי תחרות הבדיקות הישראלית והבינלאומית לשנת 2025רקע אישי על המרואייני:אלכס נשוי +2, תושב כרמיאל. עובד בבדיקות אוטומציה בחברת טנבולעומרי, אבא לשתי בנות. עובד בצוות האוטומציה של טנבול, חברו הקרוב של אלכס. שניהם עבדו בעבר בחברת סיטגיק תחרות הבדיקות הישראליתאיך נחשפו לתחרותדרך רשתות חברתיות וגם בזכות ניצן, שהציע להשתתף ונתן ביטחון אישי לעומריהצטרפו לתחרות לראשונה עם שותפים אחרים – ובהמשך התאחדו לצוות קבוע משלהם. איך נולד השם "קומומנוב"שילוב של שמות המשפחה: קומומנוב (קומנוב וממן)השם נבחר באופן קליל ואישי – כמו לבחור שם לתינוק ההכנות לתחרותעם הזמן פיתחו שיטת עבודה מסודרת טמפלטים מוכנים לדוחות סיכום בדיקותחלוקת תפקידים לפי חוזקות: אלכס – אוטומציה, עומרי – תיעוד באגים וסיכום בדיקותהפקת לקחים מתחרויות קודמותדגש על ניהול זמן מדויק אסטרטגיות נוספותהקצאת זמן מראש לאימפרוביזציות, למקרה שיתקבל מוצר לא מוכרבניית סביבת בדיקות מראש לכלי בדיקה כמו פליירייט ובלייזמטר אתגרים מרכזיים בתחרותניהול זמן, במיוחד הכנת דוח מסכם בזמן מוגבלהצורך להבין מוצר חדש במהירות, ללא מסמכי אפיוןשיתוף פעולה שוטף, תיאום הדדי והיכולת לתמוך אחד בשני ברגעי לחץ מה עזר להם לנצחכימיה אישית וחברות חזקהניסיון מגוון בבדיקות ידניות ואוטומציהיכולות תקשורת גבוהות, הבנת הצרכים אחד של השני בלי הרבה מיליםחשיבה ביקורתית, סדר ודיוק בתיעודגישה של למידה מהתהליך, לא רק מיקוד בזכייה התחרות הבינלאומית בקופנהגןאיך גילו שזכוקיבלו את ההודעה כשהיו בנסיעת עבודה בוושינגטון – באמצע נסיעה באובר לשדה תעופההייתה שמחה אדירה באוטו, כולל חיבוקים, קריאות בעברית ונהג מופתע במיוחד מה היה שונה בתחרות הבינלאומיתמשך ארוך יותר: כ-7 שעות לעומת 3 בתחרות הישראליתנדרשו להגיש מסמכים מורכבים כמו מסמך תכנון בדיקות ועיצוב בדיקותדיווח באגים לא במערכת מוכנה – אלא בדוחות ידניים (למשל אקסל)החשיבות הגבוהה של תכנון מקצועי מוקדם ואיך להציג אותו לפי סטנדרטים של ארגון הבודקים היבנלאומי אתגרי ההכנההכנה אינטנסיבית יותר עם ניצןהתמודדות עם מוצר מורכב מאוד שהקשה על מציאת באגיםדגש על איכות התכנון, לא רק הביצוע תובנות וסיכוםמה למדו מהחוויהאלכס: הכיף והחוויה שבלהתמודד עם מוצר לא מוכרעומרי: החשיפה לעולמות חדשים וטכנולוגיות שלא היה נוגע בהן אחרתשניהם מדגישים שהחוויה עצמה – אפילו מעבר לזכייה – היא מה שנותן הכי הרבה ערך אישי ומקצועי  פרסומתהפרק כלל פרסומת לקורס בדיקות ידניות ואוטומציה (כולל בינה מלאכותית) במכללת אי.פי.סי, כולל הכנה להסמכת הבודקים הבינלאומיתקישור לפרטים נוספים לקורס בדיקות של מכללה אי.פי.סיhttps://ipc.co.il/course/qa-course/
• 
  פרק #69 | 10 שנים למגזין ״עולם הבדיקות״ עם אייל זילברמן 10.01.2026 48min

  :נושא הפרקחגיגת 10 שנים למגזין "עולם הבדיקות" ו-40 גיליונות שיצאו מאז הקמתו. לרגל החגיגה, מתארח אייל זילברמן, ממקימי מגזשין ״חושבים בדיקות״ (לפני הפיכת המגזין ל״עולם הבדיקות״, לשיחה מרתקת על ההיסטוריה של התחום, תרומתו האישית והקהילתית, והתפתחות עולם הבדיקות בישראלעל האורח – אייל זילברמןמקצוע: רואה חשבון במקור, אך עוסק בבדיקות תוכנה מאז גיל 21התחלה מקרית: קיבל הצעת עבודה ממפקדו מהצבא בשל הרקע בתותחנות, והתחיל לעבוד בבדיקות תוכנה בלי לדעת מה זה בכללהקמת קוואליטסט: ב-1998 הקים יחד עם שותף את חברת הבדיקות "קוואליטסט", שהפכה עם השנים לחברה הגדולה בעולם בתחום, ונמכרה בסכום של כחצי מיליארד דולר ב-2019מוביל קהילתי: היה שותף להקמת מגזין "עולם הבדיקות", כתב טורים רבים, ביניהם "אנציקלופדיה לבדיקות"היום: פחות פעיל בתחום, אך זוכר לו הרבה טוב וממשיך ליישם את מיומנויות הביקורת שרכש גם בעסקים אחריםעל מגזין "עולם הבדיקות"הקמה: התחיל ב-2010 (למרות שמציינים "10 שנים", עברו כבר כ-15). נוסד על ידי אייל, רם יוניש ויואל מונטבילסקישם קודם: נקרא בתחילה "חושבים בדיקות"מטרות המגזיןלספק תוכן מקצועי, כלים וידע לבודקי תוכנהלתת במה לאנשי מקצוע מהתחום לשתף ידע וניסיוןקהילתיות: מעל ל-100 כותבים לאורך השנים. חלק מהטורים נוצרו במיוחד לאנשים שפחות כותבים, כמו "ראיונות עם מנהלי בדיקות"תרומה קהילתית: המגזין מהווה מקור ידע משמעותי בעברית, נדיר בתחומו, ומספק תחושת שייכות לקהילת הבודקים בישראלטורים ומאמרים זכורים"אנציקלופדיה לבדיקות" – טור עמוק שמסביר מושגים מעולם הבדיקות עם דוגמאות פרקטיות. נכתב ע"י אייל ממניעים אישיים של למידה עצמית"עשרה טיפים לבודק תוכנה" – מאמר מפתח מהמגזין הראשון, עם עצות פרקטיות משולחן העבודה, שנכתב בשיתוף עם רם ויואל"מיומנו של בודק מתחיל" – טור אותנטי של רוטם אקרמן על חוויותיו כבודק מתחיל, כולל חוויות מהתמודדות עם בדיקות עומסיםטיפ בולט מהמאמר הראשון: "השקע 20 דקות ביום במעבר על הבאגים במערכת" – דרך פשוטה ללמוד גם על המערכת וגם על הבדיקות שכבר בוצעומחשבות של אייל על עולם הבדיקותהבדיקות הן לא רק עבודה טכנית – הן דורשות חשיבה, ביקורת, הכרת המערכת לעומקבודקי תוכנה לרוב מכירים את המערכת טוב יותר ממפתחים או מנהלי מוצרפתיחת בג היא תחושת הישג מרגשת – כמו מציאת אוצר או פתרון בחדר בריחההמגזין הוא לא רק כלי מקצועי – הוא פלטפורמה קהילתית, מרגשת, שנותנת במה ומחברת בין אנשים שבאמת אוהבים את תחום בדיקות התוכנהעל נותני החסותקורס בדיקות תוכנה מעשי עם בינה מלאכותית של אי.פי.סי – כי השוק לא מחכהקורס בדיקות תוכנה של מכללת אי.פי.סי מעניק לך הכשרה מעשית מלאה בכל שלבי בדיקות – ידניות, אוטומציה ויישום כלים חכמים עם בינה מלאכותיתתלמד טכניקות בדיקה, SQL, טייפסקריפט, תכנות בסיסי ואוטומציה עם פליירייט — בדיוק מה שמעסיקים מחפשים היוםחלק מהתוכנית כולל גם הכרת כלים מבוססי בינה מלאכותית לשיפור תסריטי בדיקות, תיעוד ואופטימיזציה של תהליכיםהקורס בנוי בהתאמה לשוק העבודה ההייטקי בישראל עם דגש על מיומנויות פרקטיות ותיק עבודותכולל הכנה להסמכה בינלאומית של ארגון הבודקים, שמכירה מעל ל‑80 מדינותמתאים גם למתחילים — אין צורך בידע טכני קודם, ליווי צמוד לאורך הדרךלימודים היברידיים / אונליין שמותאמים ללוח הזמנים שלךלפרטים והרשמהhttps://ipc.co.il/courses/ לדף הרשמה לקורס בדיקות תוכנהhttps://ipc.co.il/our-courses/software-testing/ 
• 
  פרק #68 | שילוב בינה מלאכותית בבדיקות אוטומציה עם גיל זילברפלד 27.12.2025 52min

  Integrating AI into Test Automation with Gil ZilberfeldIn this episode, Gil Zilberfeld joins the show to discuss one of today’s hottest topics in software testing: integrating artificial intelligence into software testing and automation. Gil, a long-time quality expert, shares insights on how this technology is reshaping the tester’s role in a rapidly changing industry.Key topics covered:Should testers use artificial intelligence?The answer: it depends. Artificial intelligence can save time and help execute more tests in less time, but it still cannot be trusted completely. It should be treated as an assistive tool that supports - but does not replace - human judgment.How the tester’s role is changing:In the past, testers were mainly responsible for executing tests. Today, with artificial intelligence in the picture, testers are increasingly expected to manage and review testing activities performed or recommended by models. This requires a deep understanding of the system and business context - something an automated tool cannot fully provide on its own.Time optimization:Similar to automation, artificial intelligence is an investment that pays off over time. It enables testers to focus on more complex tasks while helping with test case creation, data generation, script writing, and more.Warnings and challenges:Artificial intelligence is not always accurate, and its suggestions can include errors. The tester must act as the "responsible adult" - filtering, judging, and validating the outputs. For example, if artificial intelligence generates tests that include dynamic fields (such as IDs or timestamps), testers must understand what can be compared reliably and what cannot.Common use cases:Generating test cases based on API schemasRefactoring test code using design patternsAutomatically producing documentation and defect reports (for example, a Jira ticket generated from a failed test)Creating JSON files for required test dataSignificantly reducing test development time (up to 70%-80% time savings)API testing vs. UI testing:API tests are generally easier to automate and manage due to clear schemas and contracts. UI tests are more complex and require more context, including understanding screen structure and user behavior. Using artificial intelligence effectively often requires an even stronger understanding of the system to "help it help us."Bottom line:Artificial intelligence is driving a major shift in the testing world, but it does not replace people. It strengthens our ability to test faster and deeper, while still requiring oversight, judgment, and a deep understanding of the product and processes.Link to our Community Whatsapp GroupLinkedIn profiles:Gil ZilberfeldNetanel Harush