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 testingThe podcasts are delivered in Hebrew

  1. פרק מס 81 | ראיון עם מוביל בדיקות - אלכס סטרוסברג

    4 days ago

    פרק מס 81 | ראיון עם מוביל בדיקות - אלכס סטרוסברג

    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

    59 min
  2. פרק #80: מאוטומציה לאינפרט: סיפור הצלחה של סטארט-אפ עם איתי ששון

    13 Jun

    פרק #80: מאוטומציה לאינפרט: סיפור הצלחה של סטארט-אפ עם איתי ששון

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

    35 min
  3. פרק #79 | תחרות האוטומציה של ישראל

    30 May

    פרק #79 | תחרות האוטומציה של ישראל

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

    50 min
  4. פרק#78 | מה באמת קורה מאחורי הקלעים של הבינה המלאכותית עם נתנאל הרוש ושי ששון

    16 May

    פרק#78 | מה באמת קורה מאחורי הקלעים של הבינה המלאכותית עם נתנאל הרוש ושי ששון

    סיכום מלא של הפרק בפרק הזה של פודקאסט טסט.איי.אל מבית אי.טי.סי.בי, נתנאל הרוש מארח את שי ששון לשיחה עמוקה ומרתקת על מה שבאמת קורה מאחורי הקלעים של עולם הבינה המלאכותית – מעבר לכלים שכולנו מכירים ולשימושים היומיומיים שהפכו לחלק מהחיים שלנו. שי, שעוסק בתחום כבר יותר מ־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   ```

    1hr 7min
  5. פרק #77 | ״אישה בחזית מהפיכה ושינוי ב-איי.טי.אנ.טי״ עם דקר שלום ויעל גולדברג

    3 May

    פרק #77 | ״אישה בחזית מהפיכה ושינוי ב-איי.טי.אנ.טי״ עם דקר שלום ויעל גולדברג

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

    1hr 9min
  6. פרק #76 | התפתחות מקצועית לבודקי תוכנה עם עמית ורטהיימר

    18 Apr

    פרק #76 | התפתחות מקצועית לבודקי תוכנה עם עמית ורטהיימר

    בואו הקשיבו לניצן גולדנברג מארח את עמית ורטהיימר אשר מדברים על התפתחות מקצועית לבודקי תוכנהתיאור הפרק: התפתחות מקצועית לבדוקי תוכנה :בפרק הזה של הפודקאסט מתארח עמית ורטהיימר, בודק תוכנה ותיק וראש צוות בדיקות, לשיחה עמוקה על השאלה שמעסיקה הרבה אנשי בדיקות תוכנה ?איך מתקדמים מקצועית – בלי לעזוב את עולם הבדיקותהרקע לפרק.הדיון מתחיל מתופעה מוכרת: אנשי בדיקות תוכנה מוכשרים עוזבים את התחום אחרי כמה שנים, לרוב לכיוון פיתוח או דבאופס .הסיבה המרכזית שחוזרת על עצמה: תחושת “תקרת זכוכית” – חוסר במסלול התקדמות ברור בתוך בדיקות תוכנה .עמית מנסה להתמודד עם הבעיה דרך מודל שמגדיר מסלולי התפתחות אמיתיים בתוך המקצוע רמות התפתחות ב-בדיקות תוכנהרמה בסיסיתביצוע משימות בדיקה עבודה לפי הנחיות יכולת לתפעל בדיקות (ידניות או אוטומטיות) זה השלב שבו  - עושים את העבודה  רמת – יצירת אימפקט:כאן מתחיל ההבדל האמיתי .בודק בכיר לא רק מבצע – אלא משפיע על הסביבה שלו :דוגמאות מנטורינג לצוות       מומחיות עמוקה במוצר      הובלת תחום טכנולוגי (כמו אוטומציה)      שיפור תהליכים הפוקוס עובר מ-“מה אני עושה” ל-איך אני משפיע רמות בכירות:בשלב הזה ההשפעה כבר חוצה צוותים טסט ארכיטקטמגדיר אסטרטגיית בדיקות ארגונית      מחבר בין בדיקות לבין מטרות עסקיות     בונה חזון    טסט ג׳אמפר (מושג של ג׳יימס באך)כוח חילוץ-  למצבים מורכבים     נכנס לבעיות קריטיות ומייצר פתרון מהיר    מהנדס פרודקטיביטימשפר תהליכי עבודה      בונה כלים שמייעלים את עבודת הצוות      מומחה טכני מתכנת חזק שמתמחה בכלי בדיקות      בונה תשתיות מתקדמות      רמת “משפיענים” בתעשייהאנשים עם מוניטין רחב     מפיצים רעיונות חדשים    מחברים בין קהילות וארגונים    בעיה מרכזית: טייטלים לא ברורים:אחת הביקורות החזקות בפרק היא על שוק העבודה בודק תוכנה, מהנדס בדיקות, מהנדס אוטומציה לא באמת מגדירים מה מצופה מהתפקיד :התוצאה מועמדים לא מתאימים מגישים מועמדות      פערים בין ציפיות למציאות      ?ומה עם בינה מלאכותית:הנושא עולה בסוף הפרק בינה מלאכותית הוא כלי חזק – אבל לא חובה (עדיין)       יש הרבה הייפ, אבל השוק עדיין לומד איך להשתמש בו נכון       שימוש לא נכון יכול אפילו לבזבז זמן (למשל: יצירת כמויות קוד שלא מספיקים לבדוק)     :המסקנה בינה מלאכותית חשוב – אבל הוא עוד כלי בארגז, לא תחליף לחשיבה מקצועית :קישורים שאוזכרו בפרק 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/  :קישור לפרופיל לינקדאין של עמית

    1hr 2min
  7. פרק #75 | האנציקלופדיה לבדיקות עם ניצן גולדנברג - אדפטיביליטי - היכולת להסתגל

    4 Apr

    פרק #75 | האנציקלופדיה לבדיקות עם ניצן גולדנברג - אדפטיביליטי - היכולת להסתגל

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

    10 min
  8. פרק #74 | בינה מלאכותית כשופטת עם יאיר כהן

    20 Mar

    פרק #74 | בינה מלאכותית כשופטת עם יאיר כהן

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

    51 min

Ratings & Reviews

5
out of 5
6 Ratings

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 testingThe podcasts are delivered in Hebrew

You Might Also Like