TestIL Podcast

:נושא הפרקחגיגת 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/ 

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

ראיון על כוס קפה עם מנהלת בדיקות - לימור יעקבבפרק זה , דקר שלום מראיינת את לימור יעקוב מנהלת הבדיקות של חברת לייטקס על דרכה המקצועית בעולם הבדיקות ועל נשים בעולם הבדיקות בישראל התחלה מקרית בעולם הבדיקותלימור הגיעה לעולם ה-במקרה, לאחר סיום הלימודים, כאשר עבדה בחברת נשיונל סמיקונדקטור. שם גילתה שהתחום מתאים מאוד לפרופיל האישי שלה – פרפקציוניסטית, יסודית, עם נטייה חזקה לבקרת איכותהתמחות בעולמות החומרה לימור עבדה בסטארטאפים ובחברות גלובליות, ביניהןSmartLinkWizzrBroadcomArmוכיום היא מנהלת בדיקות ב-לייטקס – חברת בטיחות לרכבים המפתחת מערכת מבוססת מצלמות ובינה מלאכותיתאתגרי במוצרי חומרה משולבי תוכנההשילוב בין מוצרי ענן למכשירי קצה יוצר מורכבות גבוההשוני בכלי הבדיקהבדיקות פונקציונליות מול בדיקות לא פונקציונליות (אמינות, עומסים ועוד)תקלות שמקורן ברכיבי חומרה כגון כבלים, סנסורים וחיבורים לרכבמגדר וקריירה בעולמות גברייםלימור משתפת שלמרות שתחום החומרה והאלקטרוניקה נשלט ברובו על ידי גברים, היא אינה חשה צורך להוכיח את עצמה מעבר לנדרש, הודות לאמונה פנימית חזקה ביכולותיה המקצועיותתהליכי בדיקה דומים בין תוכנה לחומרה – עם הבדלים קריטייםהבדל מרכזי טמון בזמן ובמשאבים הנדרשים לטיפול בבאגיםבחומרה – שינוי עלול להימשך חודשים ואף שנים (לדוגמה תיקון בשבב)בתוכנה – עדכון יכול להתבצע באופן מיידי באמצעות הענןניהול באגים ובדיקות מוקדמותשימוש בלוגים, דיבאגרים ושיטות עבודה שמטרתן איתור תקלות מוקדם ככל האפשרהתמודדות עם תנאי קצה כגון טמפרטורות קיצוניות, לכלוך ותקלות חיבורגיוס ובניית צוותי בדיקות תוכנההתאמה בין סוג המוצר לסוג הבודקבודקי חומרה – נדרשות מיומנויות שטח ויכולת פתרון תקלות פיזיותבודקי תוכנה – נדרשת הבנה עמוקה של ממשק תכנות אפליקציות, פורטלים ותשתיות ענןלכל תחום בדיקות נדרש ידע שונה ואופי מקצועי אחרניהול עומסים וניהול סיכוניםלמרות מגבלות תקציב וזמן, נדרשת הקפדה גבוהה על איכות, במיוחד במוצרים בטיחותיים כגון מצלמות לרכבשימוש נרחב בניהול סיכונים לצורך איזון בין איכות לבין זמן הגעה לשוקשקיפות מול בעלי העניין בנוגע לכיסוי הבדיקות ולפריטים שנדחותובנות עיקריותתחום הבדיקות תוכנה המשולב חומרה הוא תחום מורכב ומאתגר במיוחד, הדורש הבנה עמוקה של מערכות רב־תחומיותאמונה עצמית, סקרנות ויצירתיות הם מפתחות מרכזיים להצלחה בעולם בדיקות מתקדם זהניהול איכות אפקטיבי מבוסס על איתור מוקדם של סיכונים, תכנון רחב ותיאום הדוק בין צוותים ITCB קישור לקבוצת הוואצאפ של קהילתקישור לפרופיל לינקדאין של דקר שלום:https://www.linkedin.com/in/dakar-shalom-7b6a575/ קישור לפרופיל לינקדאין של לימור יעקב:https://www.linkedin.com/in/limor-yaakov-2a814b5/ אם גם אתם מעוניינים להשתתף בפודקאסטים, אנא צרו עימנו קשר במיילPodcasts@itcb.org.il        

פרק מס 66: כל מה שרציתם לדעת על בחינת ההסמכהארגון הבודקים הבינלאומי - אי.אס.טי.קיו.בי הוא ארגון בינלאומי, שנוסד ב-2002, שמספק סטנדרטים ללימוד ולהסמכה בבדיקות תוכנהמתחתיו קיימים כ-71 גופים מקומיים (בורדים) ברחבי העולם, האחראים על פעילות במדינות השונות אי.טי.סי.בי - עמותת הבודקים וההסמכות בישראלאי.טי.סי.בי  הוא הגוף הישראלי הרשמי לאי.אס.טי.קיו.בי, נוסד ב-2004.אחראי על תרגום חומרי הלימוד, קיום הבחינות, הכשרת קהילת הבודקים בישראל, הפקת כנסים, מגזינים, תחרויות ועוד למה בכלל צריך הסמכהבעבר לא הייתה הבחנה מקצועית ברורה לתחום בדיקות התוכנהכיום מדובר במקצוע בפני עצמו, עם שיטות עבודה, מתודולוגיות וכלים ייחודייםההסמכה נותנת כלים אמיתיים להבנת תהליכים, עבודה מול לקוחות ומפתחים, ומתן ערך גבוה לארגון דוגמאות מהשטחסיפורים אישיים של המנחים מחברות שפיתחו מוצרים שבדיקתם דרשה "לצאת לשטח" – כמו ריצה עם אוזניות חכמות או בדיקות בשטח עם גי.פי.אס דו-כיווני מה לומדים בקורסיםמתודולוגיות בדיקה, רמות בדיקה, סוגי בדיקות (פונקציונאלי ולא פונקציונאלי), טכניקות ניתוח, תכנון והבנה עמוקה של צרכי הלקוחנושאים כמו בדיקות בענן, בדיקות מובייל, אוטומציה ובינה מלאכותיתזיהוי דרישות שאינן ברורות ללקוח וסיוע בתרגום לצרכים מדויקים חשיבות עולמיתבמדינות כמו קנדה, ארה"ב ומדינות אירופה – לא ניתן להתחיל עבודה בבדיקות בלי הסמכה רשמיתגם בישראל – משרדי ממשלה, ביטחוניים, רפואיים וחברות פינטק דורשים את ההסמכה מבנה הבחינה (הבסיסית)40 שאלות ברירה מרובה (אמריקאיות)משך הבחינה: 60 דקותציון עובר: 26 תשובות נכונותרמות קושירמה 1 – זיכרון מושגיםרמה 2 – הבנת מושגיםרמה 3 – יישום (כמו טכניקות בדיקה)הבחינה אינה נותנת ציון מספרי – רק תעודת מעבר. איך ללמוד לקראת הבחינהלהוריד את הסילבוס מאתר של אי.טי.סי.בי (זמין בעברית ובאנגלית).לעבור על כל החומר – פרק 1 עד 6לבצע את ארבעת המבחנים לדוגמה הקיימים באתר לפחות 3 פעמיםלהתמקד בשיפור זמן המענה, להבין איפה טעיתם ולחזור לחומרלהכיר את מושגי היסוד לעומק – כדי שתהיו מוכנים לשאלות בראיונות עבודה ולא תצטרכו להיעזר בבינה מלאכותית טיפים חשוביםהשקיעו בחזרה מעשית – תרגול עם טיימר, סבבים של מבחניםעברו לפחות פעמיים על הסילבוס, כדי שהחומר יוטמע לעומקמומלץ להגיע ל-80% הצלחה לפחות לפני ההרשמה לבחינה הרשמה לבחינהנרשמים דרך האתרwww.itcb.org.ilבוחרים תאריך, שפה, סוג מבחןניתן להיבחן בעברית ובאנגליתניתן לקבל תוספת זמן (15 דק') אם זו לא שפת האםהבחינה נערכת בבני ברק, בקומות של חברת סלע/אלדיאן סיכוםההסמכה מעניקה יתרון תחרותי משמעותי – גם בארץ וגם בחו"ללא חובה לעבודה, אך פותחת דלתות רבותההכנה למבחן היא גם הכנה לקריירה – מעניקה ידע מקצועי עמוק ומעשי 

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

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

״קריטריון יציאה״ בעולם האג׳ייל עם איגור גודשמידט  🧠 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

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

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

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

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

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

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

מתודולוגיית בדיקות מהירות - גישת הבדיקות הקונטקסטואלית עם ג׳יימס באך חלק 2  החלק השני שבו ניצן ונתנאל ישבו לראיין את ג׳׳ימס באך, מפתח גישת הבדיקות הקונטקסטואלית - בדיקות מהירות    ** הראיון נעשה באנגלית  בפרק הזה, ג'יימס באך ממשיך לדבר על בדיקות תוכנה מהירות  שיטה שהוא פיתח המדגישה בדיקות אחראיות, מבוססות כישורים, ותלויות הקשר. הוא מבקר את הגישה של אג׳ייל שבה "כולם אחראים על הבדיקות", וטוען שצריך שיהיה אדם אחד אחראי ברור לבדיקה כדי להבטיח איכות ואחריותיות. באך טוען שבדיקה היא ביצוע, לא רשימת בדיקה. כמו שטייס צריך להגיב למצב משתנה בזמן אמת, גם בודק תוכנה חייב להשתמש בשיפוט, חשיבה ביקורתית ואינטואיציה. הוא משווה את עולם הבדיקות לעולם התעופה, וטוען שבדיקות אמיתיות דורשות מעורבות אנושית וגמישות, ולא ניתן להסתמך רק על אוטומציה או תסריטים מוכנים. בנוסף, הוא מדגיש את חשיבותן של בדיקות חקרניות (בדיקות חקרניות), שבהן הבודק מעצב ומבצע את הבדיקה תוך כדי תנועה. אפילו בבדיקות מתוסרטות יש מרכיב חקרני כי האדם מפרש תוצאות בזמן אמת. בסופו של דבר, באך טוען שהבדיקה הטובה ביותר נשענת יותר על שיפוטו של הבודק מאשר על ביצוע נהלים נוקשים. James Bach continues discussing Rapid Software Testing (RST) — a methodology he developed that emphasizes responsible, skilled, and context-driven testing. He contrasts this with standard best practices and Agile’s “everyone owns testing” mindset. Bach insists that one person must be clearly responsible for testing to ensure accountability and high quality. He emphasizes testing as a performance, not a checklist. Much like a pilot must respond to real-time changes, testers must make on-the-spot decisions based on judgment, critical thinking, and intuition. Bach draws parallels between software testing and flying airplanes, explaining that real testing requires human engagement, adaptation, and judgment — things automation or scripts alone can’t provide. He also highlights the importance of exploratory testing, where testers dynamically design and execute tests simultaneously. Even scripted testing contains exploratory elements because humans interpret outcomes in real-time. Ultimately, Bach argues that good testing depends more on the tester’s judgment than on following rigid procedures. קישור לפרופיל לינקדאין של ג׳יימס קישור לאתר של ג׳יימס קישור לפרופיל לינקדאין של ניצן קישור לפרופיל לינקדאין של נתנאל               לשמיעה ישירה: (97 דקות)        

Rapid Software Testing with James Bach – a pioneer of context-driven testing. 👤 About James Bach: Over 40 years of experience in the software world. Started as a teenage game programmer in 1983. High school dropout who chose self-education due to his aversion to authority. Author of Secrets of a Buccaneer Scholar, a book about learning independently and creatively. Emphasizes respecting the way your mind works and aligning with your natural thinking style.   🔍 Why Testing? Discovered he didn't love coding all day – but loved complaining and breaking things constructively. Testing gave him the perfect outlet: “Testers don’t break software. Testers break dreams.” His goal became to reveal unrealistic assumptions and bring clarity to developers' expectations.   📚 His Teaching Philosophy: No universal “best practices” – every situation is different (context-driven approach). Believes in teaching through experience, not obedience. Example: He advises to avoid GUI-level automation when possible – but encourages learners to try it themselves and reach their own conclusions. His goal is to accelerate learning by offering guidance, not by prescribing rigid rules.   🧠 Personal Insights: Describes his brain like a pet rhinoceros – stubborn, independent, and impossible to control directly. Burned out several times early in his career until he learned to "make peace" with his mind. Now sees teaching and liberating minds as his true calling – not just testing.   💬 Notable Quotes & Ideas: “A tester doesn’t break software – a tester breaks dreams.” “Best practices are a marketing term – not an engineering concept.” “Teaching should help people form good judgment, not just ask for obedience.” Promotes critical thinking and debate over blind agreement, even at the cost of being unpopular.  

ספר פתוח - בדיקות תוכנה מהזווית האישית   בואו הקשיבו לנתנאל הרוש מראיין את אוריאלה כהן, כותבת הספר ״לחפש באגים, המדריך המעשי לבודק תוכנה״  בפרק 54 של הפודקאסט, מארח נתנאל הרוש את אוריאלה כהן, דמות מוערכת בעולם בדיקות התוכנה, לשיחה מעוררת השראה על מסעה – ממפתחת ב”רפאל” בשנות ה-60 ועד להיותה מחברת אחד הספרים הראשונים בעברית על בדיקות תוכנה ?איך מגיעים לכתוב ספר בתחום שלא נכתב עליו כמעט דבר אוריאלה כהן, מהנשים הבולטות בתחום בדיקות התוכנה בישראל, משתפת את הדרך המרתקת שלה מעבודה מול מחשבים בשחר ההייטק, דרך הוראת בדיקות בגישה אינטראקטיבית ונטולת מצגות – ועד לכתיבת ספר מקיף שמדבר בגובה העיניים גם למי שלא מגיע מהתחום דיברנו על חשיבה ביקורתית, למידה עצמאית, חינוך בודקים לחשוב – ולא רק למלא טפסים, ולמה חשוב “לקרוא בין השורות” במסמך אפיון פרק חובה למי שבודק, מלמד או פשוט אוהב להבין דברים לעומק הפרק הפעם כולל חידה אשר מזכה את המאזין הראשון שיענה נכונה ספר מתנה החידה לפני שנים רבות, בכפר קטן, חי איכר חסר מזל שהיה חייב כסף רב למלווה בריבית באותו כפר המלווה, שהיה זקן ומכוער, רצה מאוד את בתו היפה של האיכר, אז הוא בא עם הצעה הוא יוותר על החוב אם בתו של האיכר תינשא לו האיכר ובתו היו מזועזעים מההצעה, ולכן המלווה הערמומי הציע ש"יד הגורל" תחליט בנושא, בדרך הבאה הוא ישים חלוק אבן לבן וחלוק אבן שחור בתוך שקית בד הבת תוציא אבן מבלי להסתכל בתוך השקית, ואז  אם היא תוציא אבן שחורה, היא תהייה לאשתו של המלווה, והחוב יימחק אם היא תוציא אבן לבנה, היא לא תיאלץ להינשא למלווה, אבל החוב יימחק אם היא תסרב להוציא אבן מהשקית, אביה יישלח לכלא שלושתם עמדו בשביל שהיה מרופד בחלוקי אבן, והמלווה הרים שני חלוקים בת האיכר שמה לב שהמלווה לקח שני חלוקי אבן שחורים ושם אותם בשקית, ואז ביקש ממנה להוציא אבן אחת תארו לעצמכם את המצב, ומה הייתם עושים במקומה היא יכולה לסרב, ואז אביה ילך לכלא היא יכולה לטעון שישנן שתי אבנים שחורות, ולהציג את המלווה כרמאי היא יכולה להוציא אבן שחורה ?אם הייתם במקומה של בת האיכר, באיזו דרך תנקטו לפתרון הבעיה את פתרון החידה יש לשלוח לאוריאלה למייל uriella@qa-online.software בנוסף, במיוחד למאזיני קהילת הבודקים, מחיר מיוחד לרכישת הספר ״לחפש באגים, המדריך המעשי לבודק תוכנה״ באמצעות הקוד קופוןBook2025-40רכישה דרךhttps://qa-online.software/ספר-לחפש-באגים/  קישור לפרופיל לינקדאין של אוריאלה קישור לפרופיל לינקדאין של ניצן קישור לפרופיל לינקדאין של נתנאל     אם גם אתם מעוניינים להשתתף בפודקאסטים, אנא צרו עימנו קשר במייל Podcasts@itcb.org.il         

בפרק 53 של הפודקאסט צחי דוידס משתף מניסיונו בבדיקות תוכנה בתחום הרפואי, ובמיוחד בסביבות קריטיות כמו חדרי ניתוח. הוא מדגיש את החשיבות הרבה של בדיקות תוכנה מדויקות ואמינות במערכות רפואיות, שבהן כל תקלה עלולה להשפיע ישירות על חיי אדם. .הפרק מציע הצצה לעולם הבדיקות הרפואיות, כולל האתגרים הייחודיים והסטנדרטים המחמירים הנדרשים בתחום זה https://www.facebook.com/groups/alltechdavidas קישור לקבוצת הפייסבוק של צחי לטכנולוגיות https://www.linkedin.com/in/tzachi-davidas-21714b70/ קישור לפרופיל לינקדאין של צחי https://www.linkedin.com/in/nitzan-goldenberg/ קישור לפרופיל לינקדאין של ניצן https://www.linkedin.com/in/netanel-harush/ קישור לפרופיל לינקדאין של נתנאל https://bit.ly/ITCB_Podcast קישור לעמוד הבית של הפודקאסט

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

בפרק 51 של הפודקאסט TestIL Podcast by ITCB, קובי יונסי בפינתו ״האנציקלופדיה לבדיקות״ מתמקד באתגרי בדיקות תוכנה בשפה העברית. הוא מדגיש כי בדיקות בעברית הן תחום ייחודי ומורכב, הדורש התייחסות מיוחדת בשל מאפיינים לשוניים וטכנולוגיים ספציפיים הפרק עוסק בנושאים כגון: מורכבות השפה העברית: הטיות, כיווניות הטקסט (ימין לשמאל), ושימוש באותיות סופיות יוצרים אתגרים בבדיקות ממשק משתמש ובדיקות פונקציונליות. בדיקות אוטומטיות: הצורך בהתאמת כלים וסקריפטים לתמיכה בעברית, כולל טיפול בקידוד תווים ובפלטים דו-לשוניים. חשיבות ההקשר התרבותי: הבנה של ניואנסים תרבותיים ושפתיים חיונית להבטחת חוויית משתמש איכותית לקהל דובר עברית. יונסי מדגיש כי התמודדות עם אתגרים אלו מחייבת מומחיות והבנה עמוקה של השפה והתרבות, מה שהופך את בדיקות התוכנה בעברית למקצוע בפני עצמו.

הפרק בהנחיית שירה דורון מארח את נתי צדוק, מפתחת תשתיות אוטומציה בחברת BMC Software, מרצה ל-QA ואוטומציה, ופעילה לקידום נשים בהייטק. רקע אישי ומקצועי: נתי מתארת את דרכה בעולם הטכנולוגיה, החל מלימודי תואר ראשון במדעי המחשב ומתמטיקה ועד לתפקידיה הנוכחיים. היא מתארת את תחילת דרכה בלימודים שבהם חוותה תגובות מפתיעות מצד גברים ("את יודעת שזה מדעי המחשב?"). חוויה זו הפכה עבורה למנוע מוטיבציה אדיר להצליח ולהוכיח את עצמה, במיוחד כאשר גילתה את היחס המגדרי הלא שוויוני בתחום (רק 4 נשים מתוך 67 סטודנטים). היא החלה את הקריירה שלה במלנוקס ובספירל סולושן, ובהמשך הגיעה לתפקידה הנוכחי ב-BMC Software, שם היא עובדת מזה 8 שנים. פעילות לקידום נשים בהייטק: נתי פעילה מאוד בארגונים לקידום נשים, כגון SheCodes שבו ניהלה סניף והתנדבה כמנטורית. בנוסף, התנדבה בארגון "מטובי" לקידום סטודנטיות חרדיות הלומדות מדעי המחשב באוניברסיטה הפתוחה. היא עצמה השתתפה כמנטית בתוכנית המנטורינג היוקרתית "Woman to Woman", בה עברה תהליך משמעותי ששינה את ראייתה המקצועית והאישית. נשים בהייטק - חשיבות הגיוון: נתי מדגישה את חשיבות הגיוון המגדרי בתעשיית ההייטק, וטוענת כי ארגונים מגוונים מובילים ליצירתיות, חדשנות והצלחה עסקית. היא מציינת כי כיום רק כ-33% מהעובדים בהייטק הן נשים, ואילו בהנהלות הבכירות המספר יורד ל-14.1%, ושהפער בשכר עדיין עומד על כ-15% פחות לנשים. יתרונות שנשים מביאות לתחום הבדיקות: נתי מצביעה על כמה יתרונות ייחודיים לנשים בתחום בדיקות התוכנה, ביניהם: ירידה לפרטים – לנשים יש יכולת טבעית להבחין בדקויות ובפרטים קטנים החשובים מאוד בבדיקות תוכנה. מולטי-טאסקינג – יכולתן של נשים להתמודד עם מספר רב של משימות במקביל מהווה יתרון עצום בתחום. יצירתיות – נשים נוטות לחשיבה יצירתית ולתקשורת חזקה, המאפשרת עבודה צוותית ושיתופי פעולה טובים. יכולת הסתכלות רחבה – נשים מביאות הסתכלות מערכתית ורחבה על התהליכים. נתי מדגישה כי יתרונות אלו אינם באים על חשבון הגברים, אלא משתלבים ליצירת סביבה מגוונת ופורייה יותר. חשיבות המנטורינג וההשפעה על המשתתפות: נתי מפרטת את חשיבות המנטורינג ככלי ללמידה והתפתחות אישית, הן כמשתתפת והן כמנטורית. היא משתפת דוגמאות אישיות מעבודתה כמנטורית בארגון SheCodes וכמנטית בתוכנית Woman to Woman: כמנטורית: ליוותה אישית משתתפת, עזרה לה להתגבר על חסמים וחששות בכניסה לעולם ההייטק, וסייעה לה להתקבל לעבודה. כמנטית: היא קיבלה ליווי ממנטורית בכירה שהשפיעה רבות על התפתחותה האישית והמקצועית, דחפה אותה ללמוד ולהתפתח באופן משמעותי. תוכנית המנטורינג Woman to Woman: נתי מדברת בהתלהבות רבה על תוכנית זו, בה היא השתתפה כמנטית. זו תוכנית ייחודית המיועדת בעיקר לנשים מתחום ההייטק והטכנולוגיה, עם מנטוריות בכירות בתעשייה, המלוות באופן אישי וקבוצתי. היא מתארת את השפעתה הגדולה של התוכנית על חייה המקצועיים ועל ראייתה האישית, וקוראת לנשים נוספות להשתתף בתוכניות מנטורינג ולהמשיך להתפתח.