TestIL Podcast

ITCB

The ITCB podcast are intended for all software testers in Israel. Here you will find podcasts on topics such as interviews with test managers, test engineers who have undergone conversion from other fields, reviews of various events, tips for job seekers, lectures on any topic in the world of software testing The podcasts are delivered in Hebrew

  1. פרק #54 | מנהלי ״האנדס-און״ עם שביט ג׳רסי

    NOV 1

    פרק #54 | מנהלי ״האנדס-און״ עם שביט ג׳רסי

    מנהל ״האנדס-און״ עם שביט ג׳רסי  בפרק זה ניצן גולדנברג מארח את שביט ג׳רסי, מוביל צוותי בדיקות ואוטומציה ויוצר “קיו איי ללא הפסקה”. יחד הם צוללים לדילמה בין ניהול ״האנדס-און״ לניהול אסטרטגי—איך נשארים רלוונטיים טכנולוגית, מאזנים בין קוד לישיבות, ושומרים על מוטיבציה גבוהה בצוותמי זה שביט ג׳רסי בעל ניסיון של כ-12 שנה בבדיקות תוכנה, מתוכן כמעט עשור באוטומציה שימש כמוביל צוות אוטומציה בחברת ויינשטיין, מדריך ומנטור לסטודנטים בתחום, ויוצר הסדרה הפופולרית “קיו איי ללא הפסקה” שמשתפת חוויות מהשטח הגדרת “מנהל ״האנדס-און״ מנהל שמבצע חלק ניכר מהעבודה הטכנית בעצמו – כתיבת קוד, בדיקות, ניתוח תקלות – בנוסף לאחריות ניהולית בדרך כלל מדובר בשילוב משתנה: 50% ניהול, 50% טכני (תלוי בגודל הצוות) יתרונות הניהול ה-״האנדס און״ חיבור אמיתי לשטח ולכאבי הצוות הבנה מעמיקה של הקוד, התשתיות והאתגרים ״השראה ומוטיבציה לצוות כשמנהל “מלכלך את הידיים חדשנות גבוהה יותר בזכות עדכניות טכנולוגית אתגרים וחסרונות שחיקה וניהול זמן קשה – שילוב בין ישיבות, משימות, וקוד סכנה שהאחוז הטכני ירד עם גדילת הצוות הצורך להגדיר מחדש את התפקיד כדי לשמור על איזון מנהלים לא-״האנדס-און״ עלולים להתרחק מהתחום המקצועי, אך יכולים לשמור על רלוונטיות באמצעות חקירה מתמדת, לימוד עצמי, והכנסת טכנולוגיות חדשות לצוות השפעת ״האנדס-און״ על מוטיבציית הצוות חיובית מאוד – העובדים מרגישים שהמנהל מבין אותם באמת   קישור לערוץ קיו איי ללא הפסקה של שביט קישור לפרופיל לינקדאין של שביט

    58 min
  2. פרק #63 | קריטריון יציאה בעולם האג׳ייל עם איגור גולדשמידט

    OCT 15

    פרק #63 | קריטריון יציאה בעולם האג׳ייל עם איגור גולדשמידט

    ״קריטריון יציאה״ בעולם האג׳ייל עם איגור גודשמידט  🧠 Main Themes Discussed: The Importance of Community in QA Igor emphasizes the role of professional communities in knowledge sharing. He mentions the proactive involvement of the Israeli QA community, including webinars, meetups, TikTok, articles, podcasts, etc. He presents Israeli efforts at international conferences (e.g., STQB) and notes global recognition of Israel's contributions to software testing. Igor's Background Focuses on providing QA/testing frameworks for startups. Writes articles based on real-life experience and field challenges. Member of the international academic team of a global testing organization. 🧰 Main Topic: Exit Criteria ❓ What is Exit Criteria? A set of conditions or actions that must be completed before advancing to the next phase (e.g., feature completion, release, sprint). Examples: all planned tests are executed, critical bugs are resolved, monitoring is in place, sufficient automation coverage. 🔁 Common Confusion: Often confused with Acceptance Criteria: Exit Criteria: A QA/testing-focused gate to move forward. Acceptance Criteria: Business/development-focused requirements for accepting a story or task. 🧭 The Problem: Many teams treat exit criteria as a checklist — a "tick box" exercise — which leads to poor understanding and superficial QA. ✔️ Igor's Approach: Exit criteria should be a living, collaborative tool. Created with the entire team (devs, testers, managers) for clarity and shared responsibility. It should reflect real quality control, not just formal documentation. 🧪 Agile & Quality Engineering Connections 🔄 Shift in Mindset: Move from the traditional "QA owns quality" to a team-wide quality ownership model. Shift Left approach: Developers take on unit, integration, and UI testing. Testers become more like quality coaches/gatekeepers, focusing on strategy rather than just executing test cases. 🧱 Tools and Practices: Exit Criteria = Acceptance Tests = Shared understanding. Not every step is manual testing – criteria can be automated, observable, or integrated into CI/CD pipelines. 🧩 Key Takeaways: Exit Criteria is not just technical – it's cultural. Its real value is helping teams stop, reflect, and align. It's about clarity, not control – knowing when a feature or release is truly ready. Checklists are good, but only if they reflect meaningful, agreed-upon quality goals. 🧠 Final Reflections: Exit Criteria should empower teams – not burden them. It's not just a QA tool; it's a team alignment mechanism. When used properly, it improves collaboration, quality ownership, and development velocity — especially in fast-paced environments like startups.   Link to Igor Linkedin profile

    1h 14m
  3. פרק #62 | שורטקאסט ״הזזה שמאלה בבדיקות תוכנה״ עם קובי יונסי

    OCT 3

    פרק #62 | שורטקאסט ״הזזה שמאלה בבדיקות תוכנה״ עם קובי יונסי

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

    16 min
  4. פרק #61 | ניהול וקידום עובדים בהייטק עם פבל מלין

    SEP 14

    פרק #61 | ניהול וקידום עובדים בהייטק עם פבל מלין

    פרק מס 61 - ניהול וקידום עובדים בהייטק עם פבל מלין ניצן ראיין את פבל מלין – מהנדס אלקטרוניקה במקצועו ומנהל ביקורת בחברת mprest, המפתחת מערכות בקרה ובדיקה למערכות הגנה אווירית. בפרק דנו יחד בנושאים: קידום מקצועי וניהולי: מה ההבדלים בין משרה טכנית (בודק/מפתח) לבין מעבר לניהול צוות. האתגרים בקידום עובדים: חוסר בקורסים רשמיים לניהול צוותי בדיקות בישראל, מה שגורם לעובדים לחפש ידע מחו"ל. סיבות טובות לקידום: הישגים, מוטיבציה אישית להתפתח, מחויבות לארגון, רצון להשפיע וליצור שינוי. סיבות פחות טובות לקידום: צורך דחוף למלא תפקיד, לחץ מצד העובד, פתרונות זמניים שהופכים לקבועים. פוטנציאל מנהיגות: לא כל עובד מצטיין טכנית מתאים לניהול – חשוב לבדוק יכולת הובלה, אחריות והשפעה על אחרים. הבדלים בין Tech Lead למנהל צוות: Tech Lead מתמקד בהובלה מקצועית, חלוקת משימות והדרכה טכנית, בעוד שמנהל צוות נושא גם באחריות לשכר, הערכות עובדים ושיחות אישיות. איזון בין צרכי הארגון לרצונות העובד: קידום צריך לבוא משני הצדדים – מהעובד שרוצה לקחת אחריות נוספת, ומהארגון שצריך להגדיר ציפיות ולספק תמיכה. קידום לרוחב: לא תמיד קידום הוא רק לתפקיד בכיר יותר. לפעמים ההתקדמות היא הרחבת אחריות או מעבר לתחום אחר (כמו אוטומציה, ניהול מוצר, או System Engineering). הערכת עובדים ומנהלים: נדרש להציג נתונים אמיתיים על הישגים, ולהיות מוכנים לקחת אחריות גם על הצלחות וגם על כישלונות. 📌 מסרים מרכזיים קידום לא מתאים לכולם – צריך גם רצון וגם יכולת. ידע טכני ניתן ללמידה, אך מנהיגות ואחריות הם מרכיבים אישיים. חשוב לקיים שיחות ציפיות ברורות בין מנהלים לעובדים. קידום מקצועי לצדדי או הרחבת תחומי אחריות הם לא פחות חשובים מקידום לדרג ניהולי. ניהול מחייב איזון בין הידיים-על לבין עבודת הניהול (פגישות, הערכות עובדים, ניהול משא ומתן מול הנהלה). קישור לפרופיל לינקדאין של פבל קישור לפרופיל לינקדאין של ניצן

    59 min
  5. פרק #60 | מהישיבה בקהילה חרדית לבניית תשתיות אוטומציה עם בני שור

    SEP 6

    פרק #60 | מהישיבה בקהילה חרדית לבניית תשתיות אוטומציה עם בני שור

    מהישיבה בקהילה חרדית לבניית תשתיות אוטומציה עם בני שור  הפרק מספר את סיפורו של בני שור, שיצא מהעולם החרדי, התגייס לצה"ל והצליח להשתלב בהיי-טק הישראלי כמפתח תשתיות אוטומציה השיחה נוגעת באתגרים האישיים, החברתיים והמקצועיים שעבר בדרך, ובחשיבות ההבדל בין בדיקות אוטומטיות לבין בניית תשתיות אוטומציה יציבותבפרק זה התארח בני שור, תושב בית שמש, בוגר ישיבה מקהילה חרדית, וכיום מפתח תשתיות אוטומציה בחברת סייפ קש אפליקציית תשלומים דיגיטלית שמחליפה כסף מזומן קטן מסלול אישי ומקצועיבני גדל והתחנך בישיבות חרדיות ולמד בכולל לאחר נישואיו באופן לא שגרתי לקהילתו, החליט להתגייס לצה״ל, צעד שנעשה בחשאיות כדי למנוע התנגדות מהסביבה בצבא נחשף ליכולות חדשות – עמידה ביעדים, סדר יום ומשמעת – שתרמו לו בהמשך לקריירה בהיי-טק לאחר השירות למד קורסי QA ותכנות (בין השאר ב־John Bryce) והמשיך להתמקצע בפיתוח אוטומציה ותשתיות אתגרים בדרךטכניים: לימוד מתמטיקה, אנגלית ותכנות בגיל מאוחר יחסית, מעבר חד מעולם הישיבה לעולם ההיי-טק חברתיים: הסתגלות לתרבות חילונית-טכנולוגית שונה מאוד מהחינוך החרדי, תוך שמירה על זהות משפחתית ודתית תובנות מרכזיותהמעבר מהעולם החרדי לצבא ולתעשיית ההיי-טק הוא אתגר אישי, חברתי ומקצועי – אך אפשרי נדרשות שנים רבות (7–10 שנים) עד שמפתח הופך למומחה אמיתי בתחום ההבדל בין מפתח אוטומציה לבין מפתח תשתיות אוטומציה הוא משמעותי מפתח אוטומציה כותב בדיקות אוטומטיות ספציפיות. מפתח תשתיות בונה מערכות יציבות, סקיילביליות ורב־פלטפורמיות שמאפשרות לעשרות ומאות בדיקות לרוץ באופן אמין 📌 בשורה המרכזית: הסיפור של בני שור מדגים כיצד חרדי בוגר ישיבה יכול לעבור דרך צבא, לימודים טכנולוגיים והתמודדות עם פערים עצומים – ולהפוך למומחה לבניית תשתיות אוטומציה בחזית ההיי-טק הישראלי           אם גם אתם מעוניינים להשתתף בפודקאסטים, אנא צרו עימנו קשר במייל Podcasts@itcb.org.il

    1h 3m
  6. פרק #59 | להיות עורכים ראשיים במגזין ״עולם הבדיקות״

    AUG 19

    פרק #59 | להיות עורכים ראשיים במגזין ״עולם הבדיקות״

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

    36 min
  7. פרק #58 | בדיקות מבוססות סיכונים - קובי יונסי

    JUL 30

    פרק #58 | בדיקות מבוססות סיכונים - קובי יונסי

    שורטקאסט - בדיקות מבוססות סיכונים  קובי יונסי בפינתו הקבוע ״האנציקלופדיה לבדיקות״ ממגזין ״עולם הבדיקות״ מרחיב לנו בשורטקאסט על משמעות המושג ״בדיקות מבוססות סיכונים״ מתוך הסילבוס של ISTQB ואיך סיכונים משתלבים בחיי היום יום של הבודקים  הפרק עוסק בגישת בדיקות מבוססות סיכונים שיטה המאפשרת למקד מאמצי בדיקה באזורים הקריטיים ביותר במערכת, במיוחד כאשר זמן, תקציב או משאבים מוגבלים קובי יונסי מסביר ש"סיכון" מוגדר כשילוב של ההסתברות לכשל ועוצמת ההשפעה שלו, ומדגים כיצד מתעדפים בדיקות בהתאם לכך השלבים המומלצים כוללים זיהוי סיכונים – בשיתוף בעלי עניין, מנהלים, מפתחים ולקוחות הערכת הסיכונים – דירוג לפי חומרה והסתברות (בסקאלה מותאמת) התאמת הבדיקות – השקעת מאמץ ובדיקות מעמיקות יותר באזורים בסיכון גבוה שיפור מתמשך – עדכון רשימת הסיכונים בכל שינוי או גרסה נידונות טכניקות לבחירת הבדיקות: חוק פארטו (80/20), בדיקות בפונקציות מורכבות, על סמך היסטוריית תקלות, ובדיקת אזורים שבהם כשל יגרום לנזק חמור במיוחד הוא מדגיש חשיבות שיתוף הלקוח והבנת חוויית המשתמש, מביא דוגמאות מעולמות המסחר המקוון והגיימינג, ומספר על מקרה אמיתי בחברת שבו התמקדות בשדות חדשים במערכת מנעה בעיות משמעותיות והעלתה את דיוק המשתמשים המסר המרכזי אי אפשר לבדוק הכול – אבל אפשר לבדוק את הדברים הנכונים בדיקות מבוססות סיכון הן כלי אסטרטגי לניהול זמן, משאבים ואיכות המוצר בצורה חכמה קישור לפרופיל לינקדאין של קובי קישור לאתר של קובי               אם גם אתם מעוניינים להשתתף בפודקאסטים, אנא צרו עימנו קשר במייל Podcasts@itcb.org.il

    19 min
  8. פרק #57 | בדיקות בצה״ל עם ניצן גולדנברג

    JUL 27

    פרק #57 | בדיקות בצה״ל עם ניצן גולדנברג

    פרק #57 | בדיקות בצה״ל עם ניצן גולדנברג אורחים: אדם ועמרי – מפקדים בתחום הבדיקות בצה"ל 🧑‍💻 היכרות עם המרואיינים אדם (24): ראש תחום בדיקות ביחידת שחר. בעל ניסיון בבדיקות ידניות, אוטומציה וניהול צוותים עמרי (22): ראש צוות בדיקות במערכת סמארט בייס – מערכת צה"לית לניהול כניסות לבסיסים. עבר קורס בדיקות והפך למדריך ומפקד ? איך מגיעים לתחום הבדיקות בצה"ל לרוב מקבלים "שיבוץ" לקורס בדיקות תוכנה בסיסי מתנסים בבדיקות ידניות, בדיקות אוטומטיות ותיאוריות איכות משם ממשיכים לשירות ביחידות שונות .חלק מהחיילים, כמו עמרי, מתנדבים ובוחרים במודע בתחום ?מה הבדל בין בדיקות בצה"ל לעולם האזרחי תחושת משמעות עמוקה – לעיתים בדיקה לא נכונה משפיעה על חיי אדם רמות אבטחת מידע גבוהות מאוד, במיוחד כאשר מדובר ברשתות מסווגות המידע רגיש ודורש הקפדה יתרה על מעבר בין רשתות ?מהם סוגי המערכות שנבדקות מערכות לניהול כניסות לבסיסים מערכות צה"ליות שפותחו על ידי יחידות פנימיות או גופים אזרחיים ?מהם הכלים ומגבלות טכנולוגיות קיימות מגבלות רבות על הכנסת כלים מהעולם האזרחי קיים קושי להשתמש ב־בינה מלאכותית ובכלים מתקדמים כמו צ׳ט גי.פי.טי או קופיילוט, במיוחד ברשתות המסווגות לעיתים יש צורך "לארוז מחדש" כלים מהענן לשימוש פנימי בצה"ל אדם ועמרי מסבירים איך בונים פתרונות פנימיים במקום שאין גישה לטכנולוגיות אזרחיות  בינה מלאכותית – עוזר, אבל לא מחליף בינה מלאכותית הוא כלי חזק, אך עדיין לא מסוגל להחליף בודקים אנושיים יש צורך בידע אנושי לנסח שאילתות, להבין הקשרים ולהתמודד עם תרחישים מורכבים. דוגמאות מהשטח: תקלות ב־פליירייט, ניסיונות להשתמש ב־גי.פי.טי לקוד – שלא תמיד הצליחו.  :אוטומציה בצה"ל השימוש באוטומציה תלוי ביחידה, בצוות ובמשאבים קיימת הכשרה בסיסית באוטומציה בקורסים, אך יישום בפועל תלוי בצוות שאליו משתבץ החייל שימוש בטכנולוגיות כמו טייפסקריפט, פליירייט, פייטון, סלניום. מערכות האוטומציה בצה"ל דומות למבנה של סטארטאפ – צוותים קטנים עם עצמאות גבוהה 🔄 מתודולוגיית עבודה צה"ל עובד בצורה מאוד אג׳יילית סקראם מאסטרים, ספרינטים, צוותים עצמאיים – בדומה לחברות הייטק יש גם צוותי בדיקות עצמאיים וגם משובצים ישירות בצוותי הפיתוח

    1h 13m

About

The ITCB podcast are intended for all software testers in Israel. Here you will find podcasts on topics such as interviews with test managers, test engineers who have undergone conversion from other fields, reviews of various events, tips for job seekers, lectures on any topic in the world of software testing The podcasts are delivered in Hebrew

You Might Also Like