- 96
- Episodes
- 10
- Ratings
- Bi-weekly
- Cadence
- 2023
- First episode
About TestIL Podcast
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
- Publisher
- ITCB
- Category
- technology
- Language
- he
- Explicit
- No
- First episode
- 2 Jun 2023
- Latest episode
- 30 Oct 2026
Latest episodes
96 episodes in the feed.
30 Oct 2026
פרק #90 | מודל סקיל-וויל-היל
פרק מס 90 Skill, Will & Hill איך מזהים מה באמת עוצר עובדים וצוותים, וכיצד מובילים אותם להצלחה? בפרק של פודקאסט TestIL, בהנחיית ניצן גולדנברג ובהשתתפות איילת, אנחנו צוללים לעולם הניהול, המוטיבציה ופיתוח העובדים באמצעות מודל Skill, Will & Hill. השיחה עוסקת בזיהוי מקור הקושי של עובדים, בהתאמת הגישה הניהולית וביצירת סביבת עבודה המאפשרת לאנשים להתפתח ולהצליח. מהו מודל Skill, Will & Hill? אחד האתגרים המרכזיים בניהול אנשים הוא ההבנה שלא כל בעיית ביצועים נובעת מאותה סיבה. לעיתים העובד אינו יודע כיצד לבצע משימה, לעיתים הוא אינו מעוניין לבצע אותה, ולעיתים קיימים חסמים חיצוניים המונעים ממנו להצליח. המודל מאפשר לבחון את האתגר באמצעות שלושה מרכיבים: Skill – יכולת ומיומנות האם לעובד יש את הידע, הכלים והמיומנויות הנדרשים לביצוע המשימה? כאשר הבעיה נובעת מפערי ידע או מיומנות, הפתרון עשוי להיות הכשרה, חניכה, תרגול, ליווי מקצועי או צבירת ניסיון. Will – רצון ומוטיבציה האם העובד רוצה לבצע את המשימה? האם הוא מבין את חשיבותה ומרגיש מחובר למטרה? כאשר קיימת בעיית מוטיבציה, הכשרה נוספת אינה בהכרח הפתרון. נדרשת שיחה על תחושת משמעות, מחויבות, ציפיות, ביטחון עצמי והנעה לפעולה. Hill – חסמים ומכשולים האם קיימים גורמים בסביבת העבודה המונעים מהעובד להצליח, גם כאשר יש לו את היכולת והרצון? חסמים עשויים לכלול תהליכים מסורבלים, עומס משימות, חוסר במשאבים, תלות בגורמים אחרים, בעיות תקשורת וסדרי עדיפויות לא ברורים. המסר המרכזי: לפני שמנסים לפתור בעיה של עובד, חשוב להבין אם מדובר בפער יכולת, פער מוטיבציה או במכשול סביבתי. למה המודל חשוב למנהלי QA? בעולם בדיקות התוכנה, מנהלים נדרשים להתמודד עם שינוי טכנולוגי, מעבר לאוטומציה, כניסת כלי בינה מלאכותית, עבודה מול צוותי פיתוח ועמידה בלוחות זמנים. לא פעם, כאשר עובד מתקשה לעמוד בציפיות, התגובה הראשונה היא להציע לו קורס או הכשרה מקצועית. אך ייתכן שהבעיה אינה מקצועית כלל. בודק שאינו מצליח לכתוב בדיקות אוטומטיות עשוי להזדקק להכשרה טכנית – Skill. בודק שמכיר את הכלים אך אינו מעוניין לעבור לאוטומציה עשוי להתמודד עם חוסר מוטיבציה או חשש משינוי – Will. בודק בעל ידע ומוטיבציה שאינו מצליח להתקדם בגלל סביבת עבודה לא יציבה או היעדר זמן מתאים מתמודד עם חסמים סביבתיים – Hill. ניהול אנשים מתחיל בשאלות הנכונות אחד הרעיונות המרכזיים בשיחה הוא החשיבות של הקשבה ושאילת שאלות לפני קבלת החלטות. מה מקשה עליך לבצע את המשימה? איזה ידע או כלי חסר לך כדי להתקדם? עד כמה המשימה ברורה לך? מה יכול לעזור לך להצליח? האם יש משהו בסביבת העבודה שמעכב אותך? שאלות אלה מסייעות ליצור שיח המבוסס על הבנה ולא על האשמה, ומאפשרות למנהל ולעובד למצוא פתרונות משותפים. המודל בעידן הבינה המלאכותית כניסת כלי AI לעולם בדיקות התוכנה יוצרת הזדמנויות חדשות, אך גם אתגרים עבור עובדים ומנהלים. לא כל עובד מאמץ טכנולוגיה חדשה באותו קצב, ולא כל קושי באימוץ AI נובע מחוסר ידע טכנולוגי. Skill: האם העובד יודע כיצד להשתמש בכלי AI בצורה יעילה, אחראית ומקצועית? Will: האם העובד רואה ערך בטכנולוגיה החדשה, או שהוא חושש מהשפעתה על תפקידו? Hill: האם הארגון מספק כלים מתאימים, מדיניות ברורה, זמן ללמידה וסביבה שתומכת בהתנסות? התובנות המרכזיות מהפרק לא כל בעיית ביצועים היא בעיית ידע. חשוב לזהות את שורש הבעיה לפני בחירת הפתרון. מוטיבציה היא מרכיב משמעותי בהצלחה. יכולת מקצועית לבדה אינה מבטיחה ביצועים טובים. סביבת העבודה משפיעה על התוצאות. גם עובד מוכשר ומחויב עלול להיתקל במכשולים שאינם בשליטתו. ניהול אפקטיבי דורש התאמה אישית. פתרון שמתאים לעובד אחד אינו בהכרח מתאים לאחר. שיח פתוח הוא כלי ניהולי חשוב. הקשבה ושאלות נכונות מסייעות לזהות בעיות מוקדם יותר. שינוי טכנולוגי מחייב גם ניהול שינוי אנושי. במיוחד בתקופה שבה AI משנה את עולם בדיקות התוכנה. למי כדאי להאזין לפרק? הפרק מתאים למנהלי QA, ראשי צוותי בדיקות, מובילי אוטומציה, מנהלי פיתוח, אנשי משאבי אנוש וכל מי שעוסק בניהול אנשים ובהובלת צוותים. גם בודקי תוכנה המעוניינים להבין טוב יותר את האתגרים המקצועיים שלהם, להתפתח בקריירה או להתכונן לתפקידי ניהול יכולים למצוא בשיחה נקודות למחשבה וכלים שימושיים. לסיכום מודל Skill, Will & Hill מציע דרך פשוטה אך משמעותית להסתכל על ביצועים, התפתחות מקצועית וניהול עובדים. במקום לשאול רק מדוע העובד אינו מצליח לבצע משימה, המודל מעודד אותנו לבדוק האם חסרה לו יכולת, האם קיימת בעיית מוטיבציה או האם הסביבה מציבה בפניו מכשולים. מנהל טוב אינו רק מי שיודע להגדיר יעדים ולמדוד תוצאות, אלא גם מי שיודע לזהות מה מונע מאנשים להצליח ולעזור להם להתגבר על האתגרים שבדרך. בפרק הזה של TestIL Podcast אנחנו מזמינים אתכם לחשוב מחדש על האופן שבו אנחנו מנהלים אנשים, מזהים קשיים ומפתחים את אנשי המקצוע של המחר. TestIL Podcast | קהילת בודקי התוכנה של ישראל מבית ITCB
18 Oct 2026
פרק #89 | בודקים, אוטומציה, בינה מלאכותית ומה שביניהם עם ירון סוטיצקי
להרשמה ליום בחינות מרוכז ב 04.11 יש להכנס לקישור ולהרשם: https://forms.cloud.microsoft/r/Rt7ubz8zJy (https://forms.cloud.microsoft/r/Rt7ubz8zJy) :בודקים, אוטומציה ובינה מלאכותית ?איך משתנה העבודה שלנו על הדרך מבדיקות ידניות לאוטומציה, העבודה עם סוכני בינה מלאכותית והערך שמביאים אנשי הבדיקות לעולם המשתנה בהנחיית נתנאל הרוש · בשיחה עם ירון · כ־45 דקות מה קורה כשכלי הבינה המלאכותית הופכים לחלק משגרת העבודה של בודקי התוכנה? בפרק הזה נתנאל וירון מדברים על השינוי דרך דוגמאות מהשטח: מיצירת נתוני בדיקה וכתיבת קוד, דרך תכנון בדיקות ועד חיבור לכלים ארגוניים. לצד ההתלהבות מהיכולות החדשות, הם מדגישים את הצורך בניסיון, בהבנת המוצר ובביקורת מקצועית על התוצרים. המעבר לאוטומציה מתחיל בצורך אמיתי ירון, בעל ניסיון של כ-20 שנה בבדיקות תוכנה, מספר כיצד תהליך ידני ומסורבל ליצירת נתונים הפך להזדמנות מקצועית. הוא התחיל במאקרו באקסל, התקדם לסקריפטים בפייטון ובהמשך השתלב בתפקיד אוטומציה בדל. היוזמה החלה בזמן שהקדיש לכך בעצמו, וכשהתוצאות נראו בשטח, גדל גם הזמן שהוקצה לה.בהמשך הדרך עבר מבדיקות צד שרת לבדיקות ממשק ובדיקות מקצה לקצה, וכיום הוא עובד עם טייפסקריפט ו־פליירייט הסיפור שלו ממחיש כיצד זיהוי בעיה, סקרנות ונכונות ללמוד יכולים לפתוח דלת לתפקיד הבא מהשלמת קוד לשותף בתהליך העבודה השיחה עוברת מההתנסות הראשונית ב־ChatGPT וב־GitHub Copilot, דרך Roo Code, ועד לעבודה עם Cursor ו־Claude Code. ירון מתאר כיצד הסיוע של AI הקל עליו במעבר בין שפות תכנות ואפשר לו להתמקד יותר במטרת הפתרון ובהיגיון שמאחוריו. שני המשתתפים מדגישים את החשיבות של תכנון לפני ביצוע: לבקש מהכלי להסביר מה הוא מתכוון לעשות, לבחון את התוכנית ורק לאחר מכן להתקדם לשינויים בקוד. ההתרשמויות מהכלים מוצגות כחוויות אישיות, והדיון מראה שגם בעבודה עם אותם מודלים עשויים להתקבל תוצרים שונים MCP לחבר את הבינה המלאכותית לסביבת העבודה אחד הנושאים המרכזיים בפרק הוא שימוש ב־MCP לחיבור כלי ה־AI למערכות נוספות. המשתתפים מדברים על חיבורים לכלי אטלסיאן, לפיגמה, ל־Playwright ולתהליכי אינטגרציה והרצה נתנאל משתף בדוגמה של תקלה בתהליך CircleCI: החיבור לכלי סייע לזהות הגדרה חסרה. ירון מתאר תהליך שבו הכלי קורא דרישה, מסייע להבינה ומייצר טיוטת מסמך בדיקות. בשני המקרים, החיבור להקשר העבודה מרחיב את הסיוע מעבר לשיחה כללית על קו תכנון בדיקות מהיר יותר — עם סקירה מקצועית ירון מתאר עבודה מדורגת: יצירת מסמך בדיקות ב־Markdown, מעבר על התרחישים, הוספת בדיקות שליליות ותיקון החוסרים. בהמשך הוא נעזר בהנחיות קבועות כדי לייצר קובץ CSV לייבוא הבדיקות ל־QMetry, וכך חוסך עבודה ידנית בתיעוד החיסכון בזמן אינו מבטל את הצורך לבדוק את התוצר. המשתתפים משתפים במקרים שבהם היה צורך לתקן קוד, להוסיף תנאים או להסיר חלקים שנוצרו. גם בסקירת קוד בעזרת AI, ההמלצה שעולה מהשיחה היא לבחון את ההערות ולהחליט אילו מהן רלוונטיות ?איך ייראה תפקיד הבודק בהמשך בדיון על עתיד המקצוע עולה האפשרות שתפקיד הבודק ינוע יותר לכיוון של תכנון, הכוונה ובקרה, כשהכלים מסייעים במימוש ובתיעוד. לדעת המשתתפים, הבנת המוצר, חשיבה ביקורתית ותשומת לב לאיכות ימשיכו להיות מרכיבים מרכזיים בעבודה לצד החשש מהשפעת AI על משרות, שניהם מספרים שבסביבת העבודה שלהם עדיין מתקיימים גיוסים. הם אינם מציגים תשובה חד־משמעית לגבי העתיד, אך מדגישים את הצורך להתנסות, ללמוד ולהסתגל לשינוי עצות מעשיות שלוקחים מהפרק הכירו את המוצר לעומק: עבדו איתו, קראו דרישות ושוחחו עם המפתחים לפני הקמת מערך בדיקות ואוטומציה חלקו את העבודה לשלבים: התחילו בהבנת הדרישה ובתוכנית, עברו על התוצרים ורק אז התקדמו למימוש בחרו את הכלי לפי המשימה: לפעמים סקריפט פשוט יפתור את הבעיה בלי צורך בפנייה נוספת למודל שפה שימו לב להקשר ולעלויות: בפרק עולה הצורך להבין כיצד היסטוריית השיחה והמידע שנשלח משפיעים על השימוש בטוקנים המשיכו ללמוד ולשאול: יוזמה והתנסות בכלים חדשים הן חלק מההתפתחות המקצועית המסר המרכזי AI יכול לקצר עבודה ולהרחיב את מה שאפשר להספיק. הערך של אנשי הבדיקות נמצא ביכולת להחליט מה לבדוק, לזהות מה חסר ולבחון אם התוצאה באמת מתאימה למוצר ולמשתמשים
3 Oct 2026
פרק מס 88 | בדיקות ביצועים ועומסים עם נחום דימר
פרק 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/ (https://www.linkedin.com/in/ndimer/) קישור לפרופיל חברת CloudBeat: https://cloudbeat.io (https://cloudbeat.io) קישור לפרופיל לינקאין של ניצן: https://www.linkedin.com/in/ngqa/ (https://www.linkedin.com/in/ngqa/) קישור לפרופיל לינקדאין של נתנאל: https://www.linkedin.com/in/netanel-harush/ (https://www.linkedin.com/in/netanel-harush/) קישור לקבוצת הוואצאפ השקטה של ITCB: https://bit.ly/TestIL_Whatsapp (https://bit.ly/TestIL_Whatsapp)
Who has been a guest on TestIL Podcast
Names identified in recent episode analyses. Showing up to five guests.
- James Bach
- Uriella Cohen
- Tsahi David
Reach and audience
Public platform figures. Ratings count people who left a rating, not total listeners.
- Spotify
- 4.9 / 5
- 10 ratings
Contact TestIL Podcast
- Guest appearances
- Books guests
Based on episode analysis; this does not confirm that the show is currently accepting guests.
Host of TestIL Podcast?
Claim your podcast to manage its listing and keep your show details accurate.
Pod Engine is an independent podcast discovery and analytics service and is not affiliated with or endorsed by this podcast. Artwork and show content belong to their owners. Full legal notice.
Explore this show
Podcast research with Pod Engine